Sparc toolchain weirdness
I've successfully built gcc 3.2 and the latest binutils package without
too much trouble (Joel, the netbsd-i386 stuff in the rules files ought
to be extended to cover -sparc and -alpha - is there a neater way of
doing this than just adding every netbsd architecture?). However, I get
bus errors with any application that links to my new libstdc++, no
matter whether it's c or c++.
Further investigation (hacking the runtime linker...) revealed that it
was because a symbol had an unaligned offset. Running readelf on
libstdc++.so.5 gives me the following interesting things:
0009d5d1 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
0009d702 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
0009d7c5 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
0009dd8e 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
0009def9 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
0009df2e 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4519 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a47ee 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4841 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4892 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4a19 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4a86 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4af5 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
000a4f6e 41117 R_SPARC_UA32 0007a3c0 __gxx_personality_v0 + 0
which are the cause of the problem. If I hack the dynamic linker to skip
symbols of type UA32, c programs linked with libstdc++ work - however,
c++ programs now sit in "calling _init functions" forever.
I'm guessing that the UA specifies that it's unaligned, so it's
unsurprising that this is breaking stuff. The libstdc++.so.5 in the
Linux sparc deb just has
000ae288 51703 R_SPARC_32 00090644 __gxx_personality_v0 + 0
which is presumably roughly what my copy should look like. I'm guessing
that my toolchain is at least semi-broken - what's the best way of
finding out what's generating these UA32 entries and fixing it?
--
Matthew Garrett | mjg59@srcf.ucam.org
Reply to: