alignment problem with dwarf2out

[scott snyder <snyder at d0sgif dot fnal dot gov>]

hi -

I reported this a couple weeks ago, but it is still present in the
971122 snapshot.  This is on a mips-sgi-irix5.3 platform.

A program using exceptions was dying with a bus error on the __throw.
(I apologize for not including the example here; i was using a couple
large libraries, and i wasn't able, in the few minutes i worked on it,
to reproduce the problem with a small example.)

Here's the backtrace i was getting:

#0  0x42a954 in count_fdes (this_fde=0x10000a81) at ../../../egcs/gcc/frame.c:1
#1  0x42ab4c in frame_init (ob=0x1000fd00) at ../../../egcs/gcc/frame.c:1
#2  0x42ad0c in find_fde (pc=0x42794c) at ../../../egcs/gcc/frame.c:1
#3  0x42b694 in __frame_state_for (pc_target=0x42794c, state_in=0x7fffa568)
    at ../../../egcs/gcc/frame.c:1
#4  0x42796c in __throw () at ../../../egcs/gcc/libgcc2.c:1
...

The problem seems to be that the fde is not longword-aligned.
I looked at the fde list in the debugger; it looked ok save for the
alignment of the first element.

The module associated with this fde list contained essentially this:


extern  struct pthread            * pthread_initial;

class __pthread_init_t {
/* struct __pthread_init_t { */
        public:
        __pthread_init_t() {
                if (pthread_initial == NULL) {
                        pthread_init();
                }
        }
};

static __pthread_init_t __pthread_init_this_file;


char __pthread_init_hack = 42;


Here is an excerpt from the generated assembly code.
Apparently, the single `char' initialized data item is causing the
first fde to be misaligned; if i change the `char' above to an `int',
the error goes away.  I think dwarf2out needs to emit another alignment
directive before the first fde.


<omitted>
	.data
__pthread_init_hack:
	.byte	42
	.text

	.lcomm	__pthread_init_this_file,1
<omitted>
	.data
	.globl	_GLOBAL_$F$__pthread_init_hack
_GLOBAL_$F$__pthread_init_hack:
__FRAME_BEGIN__:
	.4byte	$LECIE1-$LSCIE1
$LSCIE1:
	.4byte	0x0
	.byte	0x1
	.byte	0x0
	.byte	0x1
	.byte	0x7c
	.byte	0x40
	.byte	0xc
	.byte	0x1d
	.byte	0x0
	.byte	0x9
	.byte	0x40
	.byte	0x1f
	.align	2
$LECIE1:
	.4byte	$LEFDE1-$LSFDE1
$LSFDE1:
	.4byte	$LSFDE1-__FRAME_BEGIN__
	.4byte	$LFB1
<omitted>


Here's a patch to add that alignment (at least for the case where
EH_FRAME_SECTION is not defined).  This seems to fix the problem for me.

Tue Nov 18 01:33:39 1997  scott snyder  <snyder@d0sgif.fnal.gov>

	* dwarf2out.c (outout_call_frame_info): Ensure that the info has
	proper alignment.

===================================================================
RCS file: /d0sgi0/usr0/snyder/CVSROOT/egcs/gcc/dwarf2out.c,v
retrieving revision 1.1.1.5
retrieving revision 1.4
diff -u -r1.1.1.5 -r1.4
--- 1.1.1.5     1997/11/15 23:40:21
+++ 1.4 1997/11/16 06:19:10
@@ -1528,6 +1528,7 @@
       tree label = get_file_function_name ('F');
 
       data_section ();
+      ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (PTR_SIZE));
       ASM_GLOBALIZE_LABEL (asm_out_file, IDENTIFIER_POINTER (label));
       ASM_OUTPUT_LABEL (asm_out_file, IDENTIFIER_POINTER (label));
 #endif


BTW, one other nit which i stumbled across.
In __throw in libgcc2.c, there's a loop searching for a handler,
at the end of which handler is tested.  However, it is possible for the
loop to exit without setting handler to anything.  This leads to a crash
with a segv rather than a call to __terminate is was apparently intended.
handler should probably be set to zero before the loop starts...

Here's a patch.

Tue Nov 18 01:33:39 1997  scott snyder  <snyder@d0sgif.fnal.gov>

	* libgcc2.c (__throw): Initialize HANDLER.

===================================================================
RCS file: /d0sgi0/usr0/snyder/CVSROOT/egcs/gcc/libgcc2.c,v
retrieving revision 1.4
diff -u -r1.4 libgcc2.c
--- 1.4 1997/11/11 05:56:17
+++ libgcc2.c   1997/11/18 07:38:41
@@ -3883,6 +3883,7 @@
   /* Now reset pc to the right throw point.  */
   pc = eh->__eh_pc;
 
+  handler = 0;
   for (;;)
     { 
       frame_state *p = udata;


thanks,
sss