* egcs 971008 on Linux/PPC - test results
@ 1997-10-13 23:30 Elliot Lee
1997-10-15 16:57 ` Jeffrey A Law
0 siblings, 1 reply; 6+ messages in thread
From: Elliot Lee @ 1997-10-13 23:30 UTC (permalink / raw)
To: egcs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs 971008 on Linux/PPC - test results
1997-10-13 23:30 egcs 971008 on Linux/PPC - test results Elliot Lee
@ 1997-10-15 16:57 ` Jeffrey A Law
1997-10-15 21:43 ` Elliot Lee
0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1997-10-15 16:57 UTC (permalink / raw)
To: Elliot Lee; +Cc: egcs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs 971008 on Linux/PPC - test results
1997-10-15 16:57 ` Jeffrey A Law
@ 1997-10-15 21:43 ` Elliot Lee
1997-10-16 2:35 ` Richard Henderson
1997-10-16 15:19 ` Jeffrey A Law
0 siblings, 2 replies; 6+ messages in thread
From: Elliot Lee @ 1997-10-15 21:43 UTC (permalink / raw)
To: egcs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs 971008 on Linux/PPC - test results
1997-10-15 21:43 ` Elliot Lee
@ 1997-10-16 2:35 ` Richard Henderson
1997-10-17 12:44 ` Michael Meissner
1997-10-16 15:19 ` Jeffrey A Law
1 sibling, 1 reply; 6+ messages in thread
From: Richard Henderson @ 1997-10-16 2:35 UTC (permalink / raw)
To: Elliot Lee; +Cc: egcs
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~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs 971008 on Linux/PPC - test results
1997-10-15 21:43 ` Elliot Lee
1997-10-16 2:35 ` Richard Henderson
@ 1997-10-16 15:19 ` Jeffrey A Law
1 sibling, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1997-10-16 15:19 UTC (permalink / raw)
To: Elliot Lee; +Cc: egcs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs 971008 on Linux/PPC - test results
1997-10-16 2:35 ` Richard Henderson
@ 1997-10-17 12:44 ` Michael Meissner
0 siblings, 0 replies; 6+ messages in thread
From: Michael Meissner @ 1997-10-17 12:44 UTC (permalink / raw)
To: rth; +Cc: sopwith, egcs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-10-17 12:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-13 23:30 egcs 971008 on Linux/PPC - test results Elliot Lee
1997-10-15 16:57 ` Jeffrey A Law
1997-10-15 21:43 ` Elliot Lee
1997-10-16 2:35 ` Richard Henderson
1997-10-17 12:44 ` Michael Meissner
1997-10-16 15:19 ` Jeffrey A Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).