Re: disturbing g++ 971031 results. defer-pop to blame?

[Robert Lipe <robertl at dgii dot com>]

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