Re: egcs 971008 on Linux/PPC - test results

[Jeffrey A Law <law@cygnus.com>]

  In message < Pine.LNX.3.95.971015233619.7848A-100000@helix.cs.cuc.edu >you write:
  > On Wed, 15 Oct 1997, Jeffrey A Law wrote:
  > OK, well, here's some further info...
  > 
  > If I compile it with egcs, and then use the old gcc to link it, it works
  > fine:
  > 	$ gcc -c -o t.o 920202-1.c
  > 	$ gcc-works -o t t.o
  > 	$ ./t && echo foo
  > 	foo
That would tend to indicate a problem in libgcc or the crt startup files.


  > That leads me to think that it is in one of the crt*.o files. It does
  > happen to use crtn.o, crt1.o, and crti.o from /usr/lib (which I think are
  > provided by glibc, although there are some [es]crt[i1n].o files in egcs'
  > gcc-lib dir), but the rest are the ones under the gcc-lib dir for this
  > snapshot.
Can you try linking with the crt files from the old gcc and a libgcc.a from
the new one?  That would point the finger either at the crt files or
libgcc.a.

  > Is there documentation somewhere that details the different purposes of
  > these crt* files, so I can narrow things down and find which one might be
  > at fault?
Probably not.  crt* files are usually highly system specific.


 > I tried breaking on _start in gdb and single-stepping into
  > things, but gdb merrily goes on by :( If I set a breakpoint in
  > __do_global_ctors_aux and then do 'nexti' repeatedly it SEGV's in that
  > function without descending into another one.
  > 
  > Dump of assembler code for function __do_global_ctors_aux:
  > 0x182ee28 <__do_global_ctors_aux>:      stwu    r1,-48(r1)
  > 0x182ee2c <__do_global_ctors_aux+4>:    mflr    r0
  > 0x182ee30 <__do_global_ctors_aux+8>:    stw     r29,36(r1)
  > 0x182ee34 <__do_global_ctors_aux+12>:   stw     r30,40(r1)
  > 0x182ee38 <__do_global_ctors_aux+16>:   stw     r31,44(r1)
  > 0x182ee3c <__do_global_ctors_aux+20>:   stw     r0,52(r1)
  > 0x182ee40 <__do_global_ctors_aux+24>:   mr      r31,r1
  > 0x182ee44 <__do_global_ctors_aux+28>:   nop
  > 0x182ee48 <__do_global_ctors_aux+32>:   lis     r9,391
  > 0x182ee4c <__do_global_ctors_aux+36>:   addi    r0,r9,15496
  > 0x182ee50 <__do_global_ctors_aux+40>:   stw     r0,8(r31)
  > 0x182ee54 <__do_global_ctors_aux+44>:   lwz     r9,8(r31)
  > 0x182ee58 <__do_global_ctors_aux+48>:   lwz     r0,0(r9)
  > 0x182ee5c <__do_global_ctors_aux+52>:   li      r9,-1
  > 0x182ee60 <__do_global_ctors_aux+56>:   cmpw    cr1,r0,r9
  > 0x182ee64 <__do_global_ctors_aux+60>:
  >     bne cr1,0x182ee6c <__do_global_ctors_aux+68>
  > 0x182ee68 <__do_global_ctors_aux+64>:
  >     b   0x182ee8c <__do_global_ctors_aux+100>
  > 0x182ee6c <__do_global_ctors_aux+68>:   lwz     r9,8(r31)
  > 0x182ee70 <__do_global_ctors_aux+72>:   lwz     r29,0(r9)
  > 0x182ee74 <__do_global_ctors_aux+76>:   mtlr    r29
  > 0x182ee78 <__do_global_ctors_aux+80>:   blrl
  > 
  > Segfault occurs on this instruction, which when executed jumps to pc=0x78
  > :-) There's more of the function that doesn't get executed. The C source
  > that generates this all is crtstuff.c:217
Well, I'm not much an a ppc/rs6000 assembler guru either...

the blrl is probably an indirect call/branch, I'm guessing to the value
in r29 (0x7b, assuming the low bits aren't interesting that's really 0x78).

In theory, you could compile your crtstuff* with -g so that you could try
and symbolicly debug this problem.

I guess the other possibility is the ctor/dtor list is bogus.

jeff