egcs 971008 on Linux/PPC - test results

Elliot Lee sopwith@cuc.edu
Wed Oct 15 21:43:00 GMT 1997


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)





More information about the Gcc mailing list