* GCC 971031 on OpenServer @ 1997-11-01 20:49 Robert Lipe 1997-11-02 12:48 ` disturbing g++ 971031 results. defer-pop to blame? Robert Lipe 0 siblings, 1 reply; 13+ messages in thread From: Robert Lipe @ 1997-11-01 20:49 UTC (permalink / raw) To: egcs Jeff's dwarf2out.c patch applied. Top level make bootstrap-lean to build it. --target=i586-pc-sco3.2v5.0.4 For GCC, Both ELF and COFF fail minimally and identically. FAIL: gcov failed: couldn't execute "./gcov": no such file or directory === gcc Summary === # of expected passes 4882 # of unexpected failures 1 # of expected failures 5 # of unsupported tests 7 ./negcs version egcs-2.90.15 971031 (gcc2-970802 experimental) ^ permalink raw reply [flat|nested] 13+ messages in thread
* disturbing g++ 971031 results. defer-pop to blame? 1997-11-01 20:49 GCC 971031 on OpenServer Robert Lipe @ 1997-11-02 12:48 ` Robert Lipe 1997-11-02 19:06 ` Jeffrey A Law 0 siblings, 1 reply; 13+ messages in thread From: Robert Lipe @ 1997-11-02 12:48 UTC (permalink / raw) To: egcs > Jeff's dwarf2out.c patch applied. Top level make bootstrap-lean > to build it. > > --target=i586-pc-sco3.2v5.0.4 > > For GCC, Both ELF and COFF fail minimally and identically. Something screwy is going on here... On the 1024 snapshot, g++ worked pretty well for both ELF and COFF. I can't swear that I rebuilt the libraries on 1024, but I will swear that I have this time. I will also swear that I've done a top-level make clean and make bootstrap-lean since applying Jeff's dwarf2out patch. I'm seeing different failures on g++ than I have before. ELF and COFF used to fail identically. Since it's sort of wierd, I should confess that ELF on this target uses dwarf2eh and COFF uses sjlj. Here are the failures. First ELF, then COFF. FAIL: g++.benjamin/warn01.C (test for excess errors) FAIL: g++.brendan/template9.C Execution test FAIL: g++.jason/2371.C Execution test XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38) FAIL: g++.jason/template31.C (test for excess errors) FAIL: g++.law/arg8.C Execution test FAIL: g++.law/code-gen5.C Execution test FAIL: g++.law/cvt2.C Execution test FAIL: g++.law/profile1.C (test for excess errors) XPASS: g++.mike/dyncast1.C Execution test XPASS: g++.mike/dyncast2.C Execution test FAIL: g++.mike/eh2.C Execution test FAIL: g++.mike/net34.C Execution test FAIL: g++.mike/net46.C Execution test FAIL: g++.mike/p658.C Execution test FAIL: g++.mike/p9732b.C Execution test === g++ Summary === # of expected passes 3367 # of unexpected failures 13 # of unexpected successes 3 # of expected failures 80 # of untested testcases 6 ./negcs version egcs-2.90.15 971031 (gcc2-970802 experimental) If I hand-compile and run, say, template.9.C, I see the "PASS" output followed by an 'illegal instruction. Core dumped'. Even if I modify the assembly output for that file to just make main return, I get the same. I tried a couple of tests manually and got similar results. $ ./negcs /tmp/net34.C -lstdc++ (robertl) rjlhome:/play/testgcc $ ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 Memory fault(coredump) I get this with or without -fno-exceptions and with any -O from 0 to 3. If I add '-defer-pop' to most of the cases I've tried by hand, it seems to work. In fact, I just wrote a script to loop through those cases and with -defer-pop. With -defer-pop, 8 of them pass. Without -defer-pop, none of them pass. Test Run By robertl on Sun Nov 2 13:11:08 1997 Native configuration is i586-pc-sco3.2v5.0.4 FAIL: g++.benjamin/warn01.C (test for excess errors) XPASS: g++.jason/destruct3.C - (test for bogus messages, line 38) FAIL: g++.jason/thunk2.C (test for excess errors) FAIL: g++.law/profile1.C (test for excess errors) XPASS: g++.mike/dyncast1.C Execution test XPASS: g++.mike/dyncast2.C Execution test FAIL: g++.mike/eh30.C (test for excess errors) FAIL: g++.mike/init1.C Execution test FAIL: g++.mike/p2736.C Execution test FAIL: g++.mike/p4750.C (test for excess errors) === g++ Summary === # of expected passes 3372 # of unexpected failures 7 # of unexpected successes 3 # of expected failures 81 # of untested testcases 6 ./negcs version egcs-2.90.15 971031 (gcc2-970802 experimental) The COFF test results are more consistent with what we've seen to date on this target. Any ideas what's going on? Thanx, RJL ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 12:48 ` disturbing g++ 971031 results. defer-pop to blame? Robert Lipe @ 1997-11-02 19:06 ` Jeffrey A Law 1997-11-02 20:47 ` Robert Lipe 0 siblings, 1 reply; 13+ messages in thread From: Jeffrey A Law @ 1997-11-02 19:06 UTC (permalink / raw) To: Robert Lipe; +Cc: egcs In message < 19971102142810.21992@dgii.com >you write: > I'm seeing different failures on g++ than I have before. ELF and COFF > used to fail identically. Since it's sort of wierd, I should confess > that ELF on this target uses dwarf2eh and COFF uses sjlj. Yup. But, aside from the tests that actually test EH, I would expect the run for ELF & COFF to be identical. Did we ever come to a resolution of the multilib testing problem? > If I hand-compile and run, say, template.9.C, I see the "PASS" output > followed by an 'illegal instruction. Core dumped'. Even if I modify > the assembly output for that file to just make main return, I get the > same. I tried a couple of tests manually and got similar results. Makes me wonder if something is goof-ing in the finalization code. Can you debug it? > > If I add '-defer-pop' to most of the cases I've tried by hand, it > seems to work. In fact, I just wrote a script to loop through those > cases and with -defer-pop. With -defer-pop, 8 of them pass. Without > -defer-pop, none of them pass. Don't you mean -fno-defer-pop? jeff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 19:06 ` Jeffrey A Law @ 1997-11-02 20:47 ` Robert Lipe 1997-11-02 22:44 ` Jeffrey A Law 0 siblings, 1 reply; 13+ messages in thread From: Robert Lipe @ 1997-11-02 20:47 UTC (permalink / raw) To: egcs [ re: new? failures on i586-pc-sco3.2v5.0.4 ] > > I'm seeing different failures on g++ than I have before. ELF and COFF > > used to fail identically. Since it's sort of wierd, I should confess > > that ELF on this target uses dwarf2eh and COFF uses sjlj. > Yup. But, aside from the tests that actually test EH, I would expect > the run for ELF & COFF to be identical. And a few short weeks ago, they did. > Did we ever come to a resolution of the multilib testing problem? Not really. I was so elated when I saw that runlib was running the tests twice that I completely failed to notice until some weeks later that it was running the elf compiler twice - once with the elf banner and once with the coff banner. I wasn't amused. I'm now just running runtest twice, each with different --tool_opts flags. > Makes me wonder if something is goof-ing in the finalization code. > Can you debug it? Now is when I notice that GDB is not playing nice with EGCS ELF output. When it rains... > > If I add '-defer-pop' to most of the cases I've tried by hand, it > > seems to work. In fact, I just wrote a script to loop through those > > cases and with -defer-pop. With -defer-pop, 8 of them pass. Without > > -defer-pop, none of them pass. > Don't you mean -fno-defer-pop? Boy, I was on a roll there, wasn't I? I meant "-fdefer-pop". -fno-defer-pop (the default) still shows the problem. $ ./negcs /tmp/net34.C -lstdc++ $ ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 Memory fault(coredump) $ ./negcs -fdefer-pop /tmp/net34.C -lstdc++ $ ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 $ This is actually ironic becuase when H.J. was having the problems that could only be cured by -fdefer-pop, I tried them on OpenServer and couldn't duplicate them at all. Apparently, our stacks are just different enough to be sensitive to whatever is going on here... RJL ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 20:47 ` Robert Lipe @ 1997-11-02 22:44 ` Jeffrey A Law 1997-11-02 23:32 ` Robert Lipe 1997-11-03 2:06 ` Robert Lipe 0 siblings, 2 replies; 13+ messages in thread From: Jeffrey A Law @ 1997-11-02 22:44 UTC (permalink / raw) To: Robert Lipe; +Cc: egcs In message < 19971102224718.19861@dgii.com >you write: > [ re: new? failures on i586-pc-sco3.2v5.0.4 ] > > > I'm seeing different failures on g++ than I have before. ELF and COF > F > > > used to fail identically. Since it's sort of wierd, I should confess > > > that ELF on this target uses dwarf2eh and COFF uses sjlj. > > Yup. But, aside from the tests that actually test EH, I would expect > > the run for ELF & COFF to be identical. > > And a few short weeks ago, they did. Hmmm. I guess the one thing I can think of which would play into some of these problems is the bogus flow control graphs we used to generate. > Not really. I was so elated when I saw that runlib was running the > tests twice that I completely failed to notice until some weeks later > that it was running the elf compiler twice - once with the elf banner > and once with the coff banner. I wasn't amused. Real strange since I've actually looked in the log files when I've done H8 testing and everything seems to be in order... Got to be something simple/stupid we're missing. > Now is when I notice that GDB is not playing nice with EGCS ELF output. > When it rains... Sigh. More likely it's not playing nice with dwarf2 more so than ELF. > > > > If I add '-defer-pop' to most of the cases I've tried by hand, it > > > seems to work. In fact, I just wrote a script to loop through thos > e > > > cases and with -defer-pop. With -defer-pop, 8 of them pass. Witho > ut > > > -defer-pop, none of them pass. > > Don't you mean -fno-defer-pop? > > Boy, I was on a roll there, wasn't I? > > I meant "-fdefer-pop". -fno-defer-pop (the default) still shows the > problem. Hmmm, -fdefer-pop is the default; the compiler will arrange for -fno-defer-pop to be on inside EH regions and such. Real strange. jeff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 22:44 ` Jeffrey A Law @ 1997-11-02 23:32 ` Robert Lipe 1997-11-03 2:06 ` Jeffrey A Law 1997-11-03 2:06 ` Robert Lipe 1 sibling, 1 reply; 13+ messages in thread From: Robert Lipe @ 1997-11-02 23:32 UTC (permalink / raw) To: law; +Cc: egcs > Real strange since I've actually looked in the log files when I've > done H8 testing and everything seems to be in order... Got to > be something simple/stupid we're missing. Probably. I'll investigate that next. > > Now is when I notice that GDB is not playing nice with EGCS ELF output. > > When it rains... > Sigh. More likely it's not playing nice with dwarf2 more so than > ELF. Yes, and '-gdwarf1' results in unresolved externals. Sigh. I'm investigating that right now. Let's focus on this problem right now: > > > > If I add '-defer-pop' to most of the cases I've tried by hand, it > > > > seems to work. In fact, I just wrote a script to loop through thos > > I meant "-fdefer-pop". -fno-defer-pop (the default) still shows the > > problem. > Hmmm, -fdefer-pop is the default; the compiler will arrange for > -fno-defer-pop to be on inside EH regions and such. Real strange. Actually, it's only the default if we're optimizing, right? That's what I'm led to believe from 'gcc -S' output. That's actually consistent with some more tests that I just ran. Perhaps we need to make the c++ tests run with varying -O levels as we do for the gcc tests. After all, what's another few hours during the build? :-) Here's what I'm seeing. negcs is just a script that calls the native egcs: G=/play/negcs L=${G}/libraries exec ${G}/gcc/xgcc -B${G}/gcc/ \ -I${L}/libio/ \ -I${L}/libstdc++/ \ "$@" $ ./negcs /tmp/net34.C -lstdc++ && ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 Memory fault(coredump) (robertl) rjlhome:/play/testgcc $ ./negcs -O0 /tmp/net34.C -lstdc++ && ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 Memory fault(coredump) (robertl) rjlhome:/play/testgcc $ ./negcs -O1 /tmp/net34.C -lstdc++ && ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 (robertl) rjlhome:/play/testgcc $ ./negcs -O2 /tmp/net34.C -lstdc++ && ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 (robertl) rjlhome:/play/testgcc $ ./negcs -O3 /tmp/net34.C -lstdc++ && ./a.out bar_1::k -> 1 bar_2::k -> 2 bar_1::get_k() -> 1 bar_2::get_k() -> 2 $ Perhaps something is doing something bad on the stack and defer-pop is just circumventing it. RJL ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 23:32 ` Robert Lipe @ 1997-11-03 2:06 ` Jeffrey A Law 0 siblings, 0 replies; 13+ messages in thread From: Jeffrey A Law @ 1997-11-03 2:06 UTC (permalink / raw) To: Robert Lipe; +Cc: egcs In message < 19971103000221.16739@dgii.com >you write: > > Hmmm, -fdefer-pop is the default; the compiler will arrange for > > -fno-defer-pop to be on inside EH regions and such. Real strange. > > Actually, it's only the default if we're optimizing, right? That's > what I'm led to believe from 'gcc -S' output. That's actually > consistent with some more tests that I just ran. Oh, yes. You're absolutely right. Sometimes I forget that you can build without -O :-) > Perhaps we need to make the c++ tests run with varying -O levels > as we do for the gcc tests. After all, what's another few hours > during the build? :-) I've always thought it should be an option. But never got up the nerve to sit down and implement it. Any chance of just discarding symbolic debugging and debugging the exit path at the assembly level? Or maybe just find out where exactly it's core dumping and try work towards a solution from there? Jeff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-02 22:44 ` Jeffrey A Law 1997-11-02 23:32 ` Robert Lipe @ 1997-11-03 2:06 ` Robert Lipe 1997-11-03 1:51 ` Jeffrey A Law ` (2 more replies) 1 sibling, 3 replies; 13+ messages in thread From: Robert Lipe @ 1997-11-03 2:06 UTC (permalink / raw) To: law; +Cc: egcs > > Now is when I notice that GDB is not playing nice with EGCS ELF output. > > When it rains... > Sigh. More likely it's not playing nice with dwarf2 more so than > ELF. GDB that I built from 4.14-95q4 (i486-unknown-sco3.2v5.0.0elf) handles the binaries in question just fine. GDB 4.16 built from virgin FSF sources isn't useful on my ELF binaries. I'll chase this later... I build the binary in question. ./negcs -O0 -g /tmp/net34.C -lstdc++ && ./a.out I then step through it: (gdb) 13 int get_k() {return k;} (gdb) bar_1::get_k() -> 1 bar_2::get_k() -> 2 Program received signal SIGSEGV, Segmentation fault. 0x8059187 in .fini () If I look at the tail end of the object, the reason for our crash is more apparent: Disassembly of section .fini: 0805917c <_fini>: 805917c: e8 c7 f9 fe ff call 8048b48 <__do_global_dtors_aux> 8059181: 90 nop 8059182: 90 nop 8059183: 90 nop 08059184 <.fini>: 8059184: 4c decl %esp 8059185: cd 04 int $0x4 8059187: 08 c2 orb %al,%dl 08059188 <.fini>: 8059188: c2 00 00 ret $0x0 805918b: 90 nop The entry in the middle looks like mush to me. Roaming through the objects that are linked, I can see that crtn.o gives us the return. crtbegin.o gives us the call to __do_global_dtors_aux(). Where does the strange sequence in th emiddle come from? If I take hte final link line: /play/negcs/gcc/ld -b elf -Ra,XPG4PLUS,ELF -YP,/usr/ccs/lib:/lib:/usr/lib \ -Qn /usr/ccs/lib/crt1.o /usr/ccs/lib/values-Xa.o \ /play/negcs/gcc/crtbegin.o -L/play/negcs/gcc -L/usr/ccs/bin \ -L/usr/ccs/lib -L/usr/local/lib net34.o -lstdc++ \ -lgcc -lcrypt -lgen -lc -lgcc /play/negcs/gcc/crtend.o \ /usr/ccs/lib/crtn.o and play with the order (add crtn.o before or after -lstdc++) I have reason to think that it's from something in libstdc++. If I just hoist -lstdc++ down to the very last (and stick another -lgcc after it) I get a functioning executable. Objdump --all-headers on libstdc++.a and all the .o's that go into it shows nothing in the .fini section. How can I find out what this is and where it's coming from? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-03 2:06 ` Robert Lipe @ 1997-11-03 1:51 ` Jeffrey A Law 1997-11-03 3:21 ` Andreas Schwab 1997-11-03 9:43 ` Robert Lipe [not found] ` <16810.878541954.cygnus.egcs@hurl.cygnus.com> 1997-11-03 9:43 ` disturbing g++ 971031 results. defer-pop not to blame Robert Lipe 2 siblings, 2 replies; 13+ messages in thread From: Jeffrey A Law @ 1997-11-03 1:51 UTC (permalink / raw) To: Robert Lipe; +Cc: egcs In message < 19971103011246.03918@dgii.com >you write: > GDB that I built from 4.14-95q4 (i486-unknown-sco3.2v5.0.0elf) handles > the binaries in question just fine. GDB 4.16 built from virgin FSF > sources isn't useful on my ELF binaries. I'll chase this later... Sounds wise :-) > Program received signal SIGSEGV, Segmentation fault. > 0x8059187 in .fini () Now we're getting somewhere... > If I look at the tail end of the object, the reason for our > crash is more apparent: > > Disassembly of section .fini: > > 0805917c <_fini>: > 805917c: e8 c7 f9 fe ff call 8048b48 <__do_global_dtors_aux> > 8059181: 90 nop > 8059182: 90 nop > 8059183: 90 nop > > 08059184 <.fini>: > 8059184: 4c decl %esp > 8059185: cd 04 int $0x4 > 8059187: 08 c2 orb %al,%dl > > 08059188 <.fini>: > 8059188: c2 00 00 ret $0x0 > 805918b: 90 nop Hmmmm. If you look at fini_dummy in crtstuff.c you'll see how this happened: static void fini_dummy () { asm (FINI_SECTION_ASM_OP); __do_global_dtors_aux (); #ifdef FORCE_FINI_SECTION_ALIGN FORCE_FINI_SECTION_ALIGN; #endif asm (TEXT_SECTION_ASM_OP); } We switch into the FINI section, emit the call, align the section, then switch out -- without ever emitting a return. So, when we return from do_global_dtors_aux, we just wander into a section, which I'm guessing is data, not code. Eventually something good or bad happens... The other possibility is the code at 0x8059184 is getting stomped on sometime during the program execution (would assume that it's r/w which might be true for the special initializer/finalizer sections. I guess the first thing I'd do is determine what kind of stuff is at 0x8059184 (code vs data) and move forward from there. Jeff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-03 1:51 ` Jeffrey A Law @ 1997-11-03 3:21 ` Andreas Schwab 1997-11-03 9:43 ` Robert Lipe 1 sibling, 0 replies; 13+ messages in thread From: Andreas Schwab @ 1997-11-03 3:21 UTC (permalink / raw) To: law; +Cc: Robert Lipe, egcs Jeffrey A Law <law@cygnus.com> writes: |> In message < 19971103011246.03918@dgii.com >you write: |> > GDB that I built from 4.14-95q4 (i486-unknown-sco3.2v5.0.0elf) handles |> > the binaries in question just fine. GDB 4.16 built from virgin FSF |> > sources isn't useful on my ELF binaries. I'll chase this later... |> Sounds wise :-) |> > Program received signal SIGSEGV, Segmentation fault. |> > 0x8059187 in .fini () |> Now we're getting somewhere... |> > If I look at the tail end of the object, the reason for our |> > crash is more apparent: |> > |> > Disassembly of section .fini: |> > |> > 0805917c <_fini>: |> > 805917c: e8 c7 f9 fe ff call 8048b48 <__do_global_dtors_aux> |> > 8059181: 90 nop |> > 8059182: 90 nop |> > 8059183: 90 nop |> > |> > 08059184 <.fini>: |> > 8059184: 4c decl %esp |> > 8059185: cd 04 int $0x4 |> > 8059187: 08 c2 orb %al,%dl |> > |> > 08059188 <.fini>: |> > 8059188: c2 00 00 ret $0x0 |> > 805918b: 90 nop |> Hmmmm. |> If you look at fini_dummy in crtstuff.c you'll see how this happened: |> static void |> fini_dummy () |> { |> asm (FINI_SECTION_ASM_OP); |> __do_global_dtors_aux (); |> #ifdef FORCE_FINI_SECTION_ALIGN |> FORCE_FINI_SECTION_ALIGN; |> #endif |> asm (TEXT_SECTION_ASM_OP); |> } |> We switch into the FINI section, emit the call, align the section, |> then switch out -- without ever emitting a return. This is ok, the final return is added by crtn.o which is linked in this example at 08059188. The invalid instructions between 08059184 and 08059188 are coming from a different object. -- Andreas Schwab "And now for something schwab@issan.informatik.uni-dortmund.de completely different" schwab@gnu.org ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop to blame? 1997-11-03 1:51 ` Jeffrey A Law 1997-11-03 3:21 ` Andreas Schwab @ 1997-11-03 9:43 ` Robert Lipe 1 sibling, 0 replies; 13+ messages in thread From: Robert Lipe @ 1997-11-03 9:43 UTC (permalink / raw) To: law; +Cc: egcs > > Program received signal SIGSEGV, Segmentation fault. > > 0x8059187 in .fini () > Now we're getting somewhere... > > > Disassembly of section .fini: > > > > 0805917c <_fini>: > > 805917c: e8 c7 f9 fe ff call 8048b48 <__do_global_dtors_aux> > > 8059181: 90 nop > > 8059182: 90 nop > > 8059183: 90 nop > > > > 08059184 <.fini>: > > 8059184: 4c decl %esp > > 8059185: cd 04 int $0x4 > > 8059187: 08 c2 orb %al,%dl > > > > 08059188 <.fini>: > > 8059188: c2 00 00 ret $0x0 > > 805918b: 90 nop > Hmmmm. > If you look at fini_dummy in crtstuff.c you'll see how this happened: > > static void > fini_dummy () > { > asm (FINI_SECTION_ASM_OP); > __do_global_dtors_aux (); > #ifdef FORCE_FINI_SECTION_ALIGN > FORCE_FINI_SECTION_ALIGN; > #endif > asm (TEXT_SECTION_ASM_OP); > } > > We switch into the FINI section, emit the call, align the section, > then switch out -- without ever emitting a return. Right. This code never emits a return. The code in the OS-provided crtn.o does. This is why it's linked last. > So, when we return from do_global_dtors_aux, we just wander into a section, > which I'm guessing is data, not code. Eventually something good or > bad happens... I don't think we wander anywhere. We return, execute a couple of nops then slam into some completely bogus-looking opcodes. Of course, if those bogus-looking opcodes were less bogus, we'd then execute that perfectly lovely ret that crtn.o gave us. > The other possibility is the code at 0x8059184 is getting stomped on > sometime during the program execution (would assume that it's r/w which > might be true for the special initializer/finalizer sections. It's definitely in the executable that way. The results I included are the output of an 'objdump --disassemble'. A 'dis' (approximate SCO equivalent of the same, only lamer) confirms this. So nobody got a chance to trounce those sections. objdump shows that .fini is read-only: 8 .fini 00000010 0805917c 0805917c 0001117c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE > I guess the first thing I'd do is determine what kind of stuff is > at 0x8059184 (code vs data) and move forward from there. It *should be* code, becuase this is what we're going to start executing at tear-down time . It looks like it *is* data or random trash). If nobody recognizes those bytes as something useful that just landed in the wrong section, I suppose I'll have to find where they're coming from. RJL ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <16810.878541954.cygnus.egcs@hurl.cygnus.com>]
* Re: disturbing g++ 971031 results. defer-pop to blame? [not found] ` <16810.878541954.cygnus.egcs@hurl.cygnus.com> @ 1997-11-03 2:28 ` Jason Merrill 0 siblings, 0 replies; 13+ messages in thread From: Jason Merrill @ 1997-11-03 2:28 UTC (permalink / raw) To: law, egcs >>>>> Jeffrey A Law <law@cygnus.com> writes: > We switch into the FINI section, emit the call, align the section, > then switch out -- without ever emitting a return. The assumption is that the OS crti.o and crtn.o provide the prologue and epilogue for _init and _fini. Jason ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: disturbing g++ 971031 results. defer-pop not to blame. 1997-11-03 2:06 ` Robert Lipe 1997-11-03 1:51 ` Jeffrey A Law [not found] ` <16810.878541954.cygnus.egcs@hurl.cygnus.com> @ 1997-11-03 9:43 ` Robert Lipe 2 siblings, 0 replies; 13+ messages in thread From: Robert Lipe @ 1997-11-03 9:43 UTC (permalink / raw) To: law; +Cc: egcs Found it. [ disassembly showing crap in .fini deleted ] > If I take hte final link line: > > /play/negcs/gcc/ld -b elf -Ra,XPG4PLUS,ELF -YP,/usr/ccs/lib:/lib:/usr/lib \ > -Qn /usr/ccs/lib/crt1.o /usr/ccs/lib/values-Xa.o \ > /play/negcs/gcc/crtbegin.o -L/play/negcs/gcc -L/usr/ccs/bin \ > -L/usr/ccs/lib -L/usr/local/lib net34.o -lstdc++ \ > -lgcc -lcrypt -lgen -lc -lgcc /play/negcs/gcc/crtend.o \ > /usr/ccs/lib/crtn.o > > and play with the order (add crtn.o before or after -lstdc++) I have > reason to think that it's from something in libstdc++. If I just > hoist -lstdc++ down to the very last (and stick another -lgcc after > it) I get a functioning executable. > > Objdump --all-headers on libstdc++.a and all the .o's that go into > it shows nothing in the .fini section. > > How can I find out what this is and where it's coming from? Ugh. I'm going to be ill. The stupid final link line listed above includes a '-L/usr/local/lib' but does not include a -L/play/negcs/libraries. This means that while I spent hours staring at a disassembly of /play/negcs/libraries/libstdc++/libstdc++.a that looked perfectly reasonable, the linker was using one from /usr/local/lib from June 2 that happens to contain crap in the .fini section. Of course, the obvious way to fix this is to add -L/play/libraries to the link line - but then '-mcoff' picks up the wrong libraries. Part of me wonders why this is dependent upon the level of optimization and the stack layout of the net34.o object when the problem is "clearly" in a linked-in library, and part of me just wants to rewire my tests to manually include the appropriate libes for ELF and COFF and get on with my life. RJL ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~1997-11-03 9:43 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-11-01 20:49 GCC 971031 on OpenServer Robert Lipe 1997-11-02 12:48 ` disturbing g++ 971031 results. defer-pop to blame? Robert Lipe 1997-11-02 19:06 ` Jeffrey A Law 1997-11-02 20:47 ` Robert Lipe 1997-11-02 22:44 ` Jeffrey A Law 1997-11-02 23:32 ` Robert Lipe 1997-11-03 2:06 ` Jeffrey A Law 1997-11-03 2:06 ` Robert Lipe 1997-11-03 1:51 ` Jeffrey A Law 1997-11-03 3:21 ` Andreas Schwab 1997-11-03 9:43 ` Robert Lipe [not found] ` <16810.878541954.cygnus.egcs@hurl.cygnus.com> 1997-11-03 2:28 ` Jason Merrill 1997-11-03 9:43 ` disturbing g++ 971031 results. defer-pop not to blame Robert Lipe
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).