another dwarf2 EH problem in 971031

[scott snyder]

hi -

I ran into another problem with the dwarf2 exception stuff.
This is on a mips-sgi-irix5.3 platform, with the 971031 snapshot.

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.

===================================================================
RCS file: /d0sgi0/usr0/snyder/CVSROOT/egcs/gcc/dwarf2out.c,v
retrieving revision 1.2
diff -c -r1.2 dwarf2out.c
*** 1.2 1997/11/05 05:38:49
--- dwarf2out.c 1997/11/05 05:39:00
***************
*** 1510,1515 ****
--- 1510,1516 ----
        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...

thanks,
sss