Debian Bug report logs - #43401
generates code which throws unaligned traps on Alpha

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: generates code which throws unaligned traps on Alpha

Date: Tue, 24 Aug 1999 00:19:23 +0200

Package: g++
Version: 1:2.95-3
Severity: normal
File: /usr/bin/c++

Even the most trivial "int main(){}" program generates a binary that
throws unaligned traps:

Aug 24 00:08:33 borkum kernel: a.out(4124): unaligned trap at 000002000000ebc8: 00000200002785c4 29 2 
Aug 24 00:08:33 borkum kernel: a.out(4124): unaligned trap at 000002000000ebd4: 00000200002785c4 2d 2 
Aug 24 00:08:33 borkum kernel: a.out(4124): unaligned trap at 000002000000ebc8: 000002000027b14c 29 2 
Aug 24 00:08:33 borkum kernel: a.out(4124): unaligned trap at 000002000000ebd4: 000002000027b14c 2d 2 

addr2line says it comes from

/src/gcc/gcc-2.95/gcc/config/alpha/crtend.asm:106

which is likely wrong, since addr2line says the same thing when giving
random adresses...

When inserting a sleep, one notices that the traps are thrown on
startup, not in the cleanup code.

	Falk


-- System Information
Debian Release: potato
Architecture: alpha
Kernel: Linux borkum 2.2.5 #2 Mon Apr 12 09:16:55 CEST 1999 alpha

Versions of packages g++ depends on:
ii  gcc                          1:2.95-3    The GNU C compiler.               
ii  libc6.1                      2.1.2-0pre6 GNU C Library: Shared libraries an
ii  libstdc++2.10-dev            1:2.95-3    The GNU stdc++ library (developmen

Message #10 received at 43401@bugs.debian.org (full text, mbox, reply):

From: "J.H.M. Dassen (Ray)" <jdassen@wi.LeidenUniv.nl>

To: 43401@bugs.debian.org

Subject: unaligned traps problem on alpha

Date: Wed, 13 Oct 1999 16:05:44 +0200

Hi Falk,

I tried to reproduce the unaligned traps problem with trivial source on an
Alpha I have access to, but couldn't. Can you try if you can find a trivial
source that still has this behaviour with the current potato gcc packages?

TIA,
Ray
-- 
Obsig: developing a new sig

Message #15 received at 43401@bugs.debian.org (full text, mbox, reply):

From: David Huggins-Daines <dhd@eradicator.org>

To: 43401@bugs.debian.org

Subject: (c++ unaligned traps) DWARF2 exception support in gcc is broken

Date: Sat, 19 Feb 2000 20:30:11 -0500

Hi,

I've been tracing this bug down today, and here is what I have found.
Sorry it's kind of long, but there's a lot of information involved...

First, a minimal testcase:

--- begin Makefile ---
topdir   := $(shell pwd)

all:: libtest.so test

# note, we use 'gcc' not 'g++' to link so that we don't see the
# unaligned access errors that are caused by the simple act of linking
# against libstdc++.

libtest.so: libtest.o
	gcc -shared -o $@ $<

test: test.o
	gcc -o $@ $< -L. -Wl,-rpath -Wl,$(topdir) -ltest

clean:
	rm -f libtest.so test *.o
--- end Makefile ---
--- begin libtest.cc ---
class Random_Lossage {};

void foo()
{
  throw Random_Lossage();
}
--- end libtest.cc ---
--- begin test.cc ---
#include <cstdio>
using namespace std;

/* from libtest.cc */
class Random_Lossage {};
extern void foo();

int main()
{
  try {
    foo();
  } catch(Random_Lossage) {
    printf("caught random lossage\n");
  };    
  return 0;
}
--- end test.cc ---

Running the 'test' program gives me these errors in syslog:

Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e954: 000002000022b534 29 1
Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e95c: 000002000022b534 2d 1
Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e954: 000002000022ba44 29 1
Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e95c: 000002000022ba44 2d 1
Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e954: 000002000022bdbc 29 1
Feb 19 20:05:21 blood-axp kernel: test(22028): unaligned trap at 000002000000e95c: 000002000022bdbc 2d 1

Now, when we trace down the address that faults, we find this code, in
glibc-2.1.3/elf/dl-reloc.c (but actually in
glibc-2.1.3/sysdeps/alpha/dl-machine.h):

  if (r_type == R_ALPHA_RELATIVE)
 46c:	a1 75 23 41 	cmpeq	s0,0x1b,t0
 470:	07 00 20 e4 	beq	t0,490 <_dl_relocate_object+0x470>
    {
#ifndef RTLD_BOOTSTRAP
      /* Already done in dynamic linker.  */
      if (map != &_dl_rtld_map)
 474:	a6 00 e0 f5 	bne	fp,710 <_dl_relocate_object+0x6f0>
#endif
	*reloc_addr += map->l_addr;
 478:	00 00 2a a4 	ldq	t0,0(s1) # 0x2000000e954 - trap #1
 47c:	01 04 27 40 	addq	t0,t6,t0
 480:	00 00 2a b4 	stq	t0,0(s1) # 0x2000000e95c - trap #1

    }

(annotations mine)

Basically we are seeing lots of unaligned R_ALPHA_RELATIVE relocations
being generated by either g++ or binutils when linking programs that
use exceptions.  Note that a C++ program that does not link with
libstdc++ and does not itself use any shared libraries with exceptions
will not see these errors.  So they must be in the exception handling
info.  And in fact, our friend objdump will tell us this:

dhd@blood-axp:~/work/g++-brokenness$ objdump -R libtest.so | grep '[4c] RELATIVE'
000000000010b534 RELATIVE          *ABS*
000000000010ba44 RELATIVE          *ABS*
000000000010bdbc RELATIVE          *ABS*

(note: RELATIVE relocations add the base address of the loaded object,
thus they are *obviously* 8 bytes wide, and on machines like the Alpha
that require data to be naturally aligned, must therefore be 8 byte
aligned)

You'll notice that those addresses match up exactly with the three
sets of unaligned traps we saw in syslog.

So hmm, where in the object file are those unaligned relocations?

dhd@blood-axp:~/work/g++-brokenness$ objdump -h libtest.so
<... snip ...>
 17 .eh_frame     00001150  000000000010b528  000000000010b528  0000b528  2**3
                  CONTENTS, ALLOC, LOAD, DATA

So let's look at the actual assembler output shall we...

dhd@blood-axp:~/work/g++-brokenness$ g++ -dA -S libtest.cc

(from resulting libtest.s)
.section	.eh_frame,"aw",@progbits
__FRAME_BEGIN__:
	.4byte	$LECIE1-$LSCIE1	 # Length of Common Information Entry
$LSCIE1:
	.4byte	0x0	 # CIE Identifier Tag
	.byte	0x1	 # CIE Version
	.ascii "eh\0"	 # CIE Augmentation
	.8byte	__EXCEPTION_TABLE__	 # pointer to exception region info

Now, do you see the problem? :-)

So, some work with grep -r on the gcc source reveals the culprit
... dwarf2out.c (lines 1765 to 1808, in output_call_frame_info()):

  if (flag_debug_asm)
    fprintf (asm_out_file, "\t%s CIE Identifier Tag", ASM_COMMENT_START);

  fputc ('\n', asm_out_file);
  if (! for_eh && DWARF_OFFSET_SIZE == 8)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    {
      ASM_OUTPUT_DWARF_DATA4 (asm_out_file, DW_CIE_ID);
      fputc ('\n', asm_out_file);
    }

  ASM_OUTPUT_DWARF_DATA1 (asm_out_file, DW_CIE_VERSION);
  if (flag_debug_asm)
    fprintf (asm_out_file, "\t%s CIE Version", ASM_COMMENT_START);

  fputc ('\n', asm_out_file);
  if (eh_ptr)
    {
      /* The CIE contains a pointer to the exception region info for the
         frame.  Make the augmentation string three bytes (including the
         trailing null) so the pointer is 4-byte aligned.  The Solaris ld
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         can't handle unaligned relocs.  */
      if (flag_debug_asm)
	{
	  ASM_OUTPUT_DWARF_STRING (asm_out_file, "eh");
	  fprintf (asm_out_file, "\t%s CIE Augmentation", ASM_COMMENT_START);
	}
      else
	{
	  ASM_OUTPUT_ASCII (asm_out_file, "eh", 3);
	}
      fputc ('\n', asm_out_file);

      ASM_OUTPUT_DWARF_ADDR (asm_out_file, "__EXCEPTION_TABLE__");
      if (flag_debug_asm)
	fprintf (asm_out_file, "\t%s pointer to exception region info",
		 ASM_COMMENT_START);
    }
  else
    {
      ASM_OUTPUT_DWARF_DATA1 (asm_out_file, 0);
      if (flag_debug_asm)
	fprintf (asm_out_file, "\t%s CIE Augmentation (none)",
		 ASM_COMMENT_START);
    }

Also see the comment in the top of dwarf2out.c:

/* The size in bytes of a DWARF field indicating an offset or length
   relative to a debug info section, specified to be 4 bytes in the DWARF-2
   specification.  The SGI/MIPS ABI defines it to be the same as PTR_SIZE.  */

#ifndef DWARF_OFFSET_SIZE
#define DWARF_OFFSET_SIZE 4
#endif

However, on Alpha, DWARF_OFFSET_SIZE is not defined to PTR_SIZE.  I
think this is an oversight on the part of the gcc maintainers.  Since
it appears that this DWARF2 stuff is mostly used for debugging it
should hopefully be safe to change it so long as BFD is updated to
know about this.  One strange thing I noticed is that while comments
in the sparc64 code suggest that this is the right thing to do, the
relevant line of code is actually commented out (from
gcc/config/sparc/linux64.h):

/* DWARF bits.  */

/* Follow Irix 6 and not the Dwarf2 draft in using 64-bit offsets. 
   Obviously the Dwarf2 folks havn't tried to actually build systems
   with their spec.  On a 64-bit system, only 64-bit relocs become
   RELATIVE relocations.  */

/* #define DWARF_OFFSET_SIZE PTR_SIZE */

Since the 64-bit ELF ABI for Alpha is not standardized, I suggest that
we fix this by doing the same thing as MIPS and defining
DWARF_OFFSET_SIZE to be the same as PTR_SIZE.  Note that since gas
tries to "optimize" DWARF CIE exception info in some rather evil ways
(see gas/ehopt.c in the binutils source), we probably need to fix
binutils too.  I haven't tried this yet, but I will tonight or
tomorrow.

GCC maintainers: can you forward this report upstream?

Message #22 received at 43401@bugs.debian.org (full text, mbox, reply):

From: David Huggins-Daines <dhd@eradicator.org>

To: 43401@bugs.debian.org

Subject: One more thing... (suggestion on how to fix)

Date: 21 Feb 2000 09:31:00 -0500

It turns out that, while defining DWARF_OFFSET_SIZE to PTR_SIZE might
be the right thing for other reasons (although the offsets are
typically very small and thus gas will optimize them down to single
bytes - this is the aforementioned "evil thing" that gas does :), it
does not solve this problem.

I suggest instead following the way it's done on Sparc (as detailed in
the comments) and padding the augmentation out to 7 bytes on 64-bit
architectures:

--- gcc/dwarf2out.c~	Tue Aug  3 03:04:37 1999
+++ gcc/dwarf2out.c	Mon Feb 21 09:18:41 2000
@@ -1783,14 +1783,23 @@
          frame.  Make the augmentation string three bytes (including the
          trailing null) so the pointer is 4-byte aligned.  The Solaris ld
          can't handle unaligned relocs.  */
+      /* Make that 7 bytes on 64-bit targets - otherwise C++ shared
+         libraries will cause myriad unaligned traps when they're
+         loaded */
       if (flag_debug_asm)
 	{
-	  ASM_OUTPUT_DWARF_STRING (asm_out_file, "eh");
+	  if (PTR_SIZE == 8)
+	    ASM_OUTPUT_DWARF_STRING (asm_out_file, "eh_frm");
+	  else
+	    ASM_OUTPUT_DWARF_STRING (asm_out_file, "eh");
 	  fprintf (asm_out_file, "\t%s CIE Augmentation", ASM_COMMENT_START);
 	}
       else
 	{
-	  ASM_OUTPUT_ASCII (asm_out_file, "eh", 3);
+	  if (PTR_SIZE == 8)
+	    ASM_OUTPUT_ASCII (asm_out_file, "eh_frm", 7);
+	  else
+	    ASM_OUTPUT_ASCII (asm_out_file, "eh", 3);
 	}
       fputc ('\n', asm_out_file);
 


This requires a corresponding patch to binutils:

--- gas/ehopt.c~	Thu Jun  3 14:01:58 1999
+++ gas/ehopt.c	Mon Feb 21 09:25:47 2000
@@ -202,7 +202,7 @@
     {
       /* No augmentation.  */
     }
-  else if (strcmp (augmentation, "eh") == 0)
+  else if (strncmp (augmentation, "eh", 2) == 0)
     {
       /* We have to skip a pointer.  Unfortunately, we don't know how
 	 large it is.  We find out by looking for a matching fixup.  */


Note: I haven't tested this yet - I'll do so today.  As far as I can
tell, the augmentation is just a null-terminated string that we are
free to interpret however we want (since it appears that it was
originally completely empty - see comments in gas/ehopt.c).  But I
haven't read the DWARF2 spec so I might be wrong.

Message #27 received at 43401@bugs.debian.org (full text, mbox, reply):

From: David Huggins-Daines <dhd@eradicator.org>

To: David Huggins-Daines <dhd@eradicator.org>, 43401@bugs.debian.org

Subject: Re: Bug#43401: One more thing... (suggestion on how to fix)

Date: 21 Feb 2000 11:28:04 -0500

dhd@eradicator.org (David Huggins-Daines) writes:

> Note: I haven't tested this yet - I'll do so today.  As far as I can
> tell, the augmentation is just a null-terminated string that we are
> free to interpret however we want (since it appears that it was
> originally completely empty - see comments in gas/ehopt.c).  But I
> haven't read the DWARF2 spec so I might be wrong.

Sorry, I am wrong.  Please do not apply this patch, it's really broken
- the frame info has to be readable by the actual exception handling
code :)

Doh!

Message #32 received at 43401@bugs.debian.org (full text, mbox, reply):

From: David Huggins-Daines <dhd@eradicator.org>

To: David Huggins-Daines <dhd@eradicator.org>, 43401@bugs.debian.org

Subject: Re: Bug#43401: One more thing... (suggestion on how to fix)

Date: 21 Feb 2000 11:56:04 -0500

dhd@eradicator.org (David Huggins-Daines) writes:

> Sorry, I am wrong.  Please do not apply this patch, it's really broken
> - the frame info has to be readable by the actual exception handling
> code :)

I should add that the exception handling code in the runtime
environment (see gcc/frame.c in the gcc source code) *expects* that
the pointer to the exception table will potentially be unaligned.

So perhaps DWARF2 is broken by design, and we should just add some
code to ld.so to cope with unaligned relocations gracefully :P

Message #37 received at 43401-done@bugs.debian.org (full text, mbox, reply):

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>

To: 43401-done@bugs.debian.org

Subject: g++: generates code which throws unaligned traps on Alpha

Date: 09 May 2001 20:07:18 +0200

I have not been able to reproduce this for a long time, so I close it.

	Falk

Send a report that this bug log contains spam.