* 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-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
* 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
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).