egcs 971008 on Linux/PPC - test results

egcs 971008 on Linux/PPC - test results

[Elliot Lee]

On a Linux/PowerPC 2.1.24 machine.

http://www.cs.cuc.edu/~sopwith/egcs-971008-check.txt

(I'm not sure whether spamming the list with a 46K attachment is
appropriate...)

grep -c '^FAIL:' egcs-971008-check.txt
563

This was compiled with the gcc 2.7.2.1-ppclinux currently on
ftp.linuxppc.org, and binutils 2.8.1.0.11.

Anything I can do to help reduce this number drastically? :-)
-- Elliot					http://www.redhat.com/
"They don't let my code go into shipping products," Gates said. "They
 haven't done that for eight years." (at the 1997 PDC)

Re: egcs 971008 on Linux/PPC - test results

[Jeffrey A Law]

  In message < Pine.LNX.3.95.971014000722.849B-100000@helix.cs.cuc.edu >you write:
  > grep -c '^FAIL:' egcs-971008-check.txt
  > 563
  > 
  > This was compiled with the gcc 2.7.2.1-ppclinux currently on
  > ftp.linuxppc.org, and binutils 2.8.1.0.11.
  > 
  > Anything I can do to help reduce this number drastically? :-)
Something is definitely wrong.

I'd suggest trying to debug the execute/920202-1.c test -- it's pretty
simple and according to your log fails without optimization:

FAIL: gcc.c-torture/execute/920202-1.c execution,  -O0 

I suspect whatever is causing that test to fail is probably causing most
of the other failures.

jeff

Re: egcs 971008 on Linux/PPC - test results

[Elliot Lee]

On Wed, 15 Oct 1997, Jeffrey A Law wrote:

> Something is definitely wrong.
> 
> I'd suggest trying to debug the execute/920202-1.c test -- it's pretty
> simple and according to your log fails without optimization:
> 
> FAIL: gcc.c-torture/execute/920202-1.c execution,  -O0 
> 
> I suspect whatever is causing that test to fail is probably causing most
> of the other failures.

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

But if I let egcs link it, it gets "Illegal instruction" (if linked
dynamically) or "Segmentation fault" (if linked statically). In addition,
if I get the assembly output from egcs & gcc-works, it is the same except
for some comments and .ident.

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.

[root@crimson execute]# cc -v -static -o t t.o
Reading specs from /usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/specs
gcc version egcs-2.90.12 971008 (gcc2-970802 experimental)
 /usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/ld -m elf32ppc -static -o t
/usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/crtbegin.o
-L/usr/lib/gcc-lib/ppc-linux/egcs-2.90.12 t.o
/usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/libgcc.a -lc
/usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/libgcc.a
/usr/lib/gcc-lib/ppc-linux/egcs-2.90.12/crtend.o /usr/lib/crtn.o

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? 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

Register dump just before blrl is executed is:
r0             0x7b     123
r1             0x7ffffd30       2147482928
r2             0xdeadbeef       -559038737
r3             0x1      1
r4             0x7ffffdb4       2147483060
r5             0x7ffffdbc       2147483068
r6             0x198    408
r7             0x3d     61
r8             0xc      12
r9             0x1873c88        25640072
r10            0x1870000        25624576
r11            0x7ffffdb0       2147483056
r12            0x3004e938       805628216
r13            0x187bb68        25672552
r14            0x2a4fc0 2772928
r15            0x2a4c28 2772008
r16            0x7ffffa60       2147482208
r17            0x0      0
r18            0x0      0
r19            0xffffffff       -1
r20            0xffffffff       -1
r21            0x0      0
r22            0x0      0
r23            0x1      1
r24            0x7ffffdb4       2147483060
r25            0x7ffffdbc       2147483068
r26            0x2a3fc0 2768832
r27            0x40     64
r28            0x2a5448 2774088
r29            0x7b     123
r30            0x2a5438 2774072
r31            0x7ffffd30       2147482928
pc             0x182ee78        25357944
ps             0x4000d932       1073797426
cnd            0x45353e95       1161117333
lr             0x7b     123
cnt            0x30100c70       806358128
xer            0xc000be6f       -1073693073
mq             0x0      0


I don't know PowerPC assembly, sorry, so I can't get any farther than
this... (If someone knows of a good online reference for PPC asm, I'm game
:-) 

Hope this helps,
-- Elliot					http://www.redhat.com/
"They don't let my code go into shipping products," Gates said. "They
 haven't done that for eight years." (at the 1997 PDC)

Re: egcs 971008 on Linux/PPC - test results

[Richard Henderson]

On Wed, Oct 15, 1997 at 11:55:21PM -0400, Elliot Lee wrote:
> 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?

crti/n creates the .init & .fini sections that are invoked by ld.so on
startup/shutdown.  crtbegin/end interfaces between the section-is-a-
function mechanism used by crti/n to the table-of-function-pointers
initialization preferred by g++ for running its constructors.

So .init invokes __do_global_ctors_aux, which calls the c++ constructors.

> I tried breaking on _start in gdb and single-stepping into
> things, but gdb merrily goes on by :(

Try "b *_start+4".  I've had more luck with the second insn in the past,
for whatever reasons.

> 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

This is "r29 = *r9; (*r29)();".  So either the table of constructors is
garbage, or you managed to get a pointer to something else.  Find out what
symbol lives near r9.

Unlike the Alpha, which has constraints the hackery in crtstuff completely
breaks, I wasn't aware of anything that ppc would care about in there. 
But obviously something has gone wrong.  What differences do you see with
objdump -dr between the two versions of crtbegin/end?


r~

Re: egcs 971008 on Linux/PPC - test results

[Michael Meissner]

Richard Henderson writes:
| On Wed, Oct 15, 1997 at 11:55:21PM -0400, Elliot Lee wrote:
| > 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?
| 
| crti/n creates the .init & .fini sections that are invoked by ld.so on
| startup/shutdown.  crtbegin/end interfaces between the section-is-a-
| function mechanism used by crti/n to the table-of-function-pointers
| initialization preferred by g++ for running its constructors.
| 
| So .init invokes __do_global_ctors_aux, which calls the c++ constructors.
| 
| > I tried breaking on _start in gdb and single-stepping into
| > things, but gdb merrily goes on by :(
| 
| Try "b *_start+4".  I've had more luck with the second insn in the past,
| for whatever reasons.
| 
| > 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
| 
| This is "r29 = *r9; (*r29)();".  So either the table of constructors is
| garbage, or you managed to get a pointer to something else.  Find out what
| symbol lives near r9.
| 
| Unlike the Alpha, which has constraints the hackery in crtstuff completely
| breaks, I wasn't aware of anything that ppc would care about in there. 
| But obviously something has gone wrong.  What differences do you see with
| objdump -dr between the two versions of crtbegin/end?

Now that I think about it, I think I know what the problem is, and its
been something I meant to fix but it kind of fell off my plate.
Basically the Linux PowerPC stuff creates crt{begin,end}.o from the
System V configs and crt{i,o}.o from the eabi configs.  My hunch is to
do Linux the same way I did eabi, and eliminate crt{begin,end}.

-- 
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: egcs 971008 on Linux/PPC - test results

[Jeffrey A Law]

  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