This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
(I've posted this on the libstdc++ mailing list, but this is probably better suited for this list.) I'm trying to clean up the solaris2.7 failures for v-3. The first on the list are a class of failures demonstrated by file 22_locale/ctype_char_members.cc, line 101. What's weird is that it only fails for -static. Linking with the shared libstdc++.so.3.0.0 gives the correct output... Is there something funky with solaris and static data members that I don't realize? It seems like the final linux static object puts the data members in question in .data, and the solaris linker puts the same members in .bss. I'm using the 2.9.1 binutils release with the gcc-2.95.2 sources. I've updated libtool to be 1.3.4 but that doesn't seem to make a difference. Here's a set-by-step Program received signal SIGSEGV, Segmentation fault. 0x16004 in ctype<char>::ctype (this=0xc8540, __table=0x0, __del=false, __refs=0) at ../../src.libstdc++/bits/locale_facets.h:321 (gdbp The history is empty. (gdb) p __table $1 = (unsigned int *) 0x0 (gdb) p __del $2 = false (gdb) p __refs $3 = 0 (gdb) p _S_table $4 = (unsigned int *&) @0x0: Cannot access memory at address 0x0. (gdb) bits/locale_facets.h: 321 explicit ctype(const mask* __table = 0, bool __del = false, size_t __refs = 0) throw() => : _Ctype_nois<char>(__refs), _M_table(__table == 0 ? _S_table: __table), _M_del(__table != 0 && __del) { } Where the static "_S_table" is linked in via the libstdc++.a from a code sample similar to this: -----sol27.h #include <ctype.h> #include <stddef.h> struct ctype_base { // solaris27 // typedef unsigned int mask; // linux typedef unsigned short mask; // Non-standard typedefs. typedef int* __to_type; }; template<typename _CharT> class ctype : public ctype_base { }; template<> class ctype<char> : public ctype_base { // Types: typedef char char_type; private: // Data Members: const mask* _M_table; bool _M_del; static const mask* const& _S_table; public: explicit ctype(const mask* __table = 0, bool __del = false, size_t __refs = 0) throw() : _M_table(__table == 0 ? _S_table: __table), _M_del(__table != 0 && __del) { } }; --------sol27.cc #include "sol27.h" int main() { ctype<char> obj1; return 0; } --------sol27-data.cc #include "sol27.h" // these bits are linked in from libc // solaris2.7 // const ctype_base::mask* const& ctype<char>::_S_table = __ctype_mask; // linux const ctype_base::mask* const& ctype<char>::_S_table = __ctype_b; Anyway, using a link map it looks like this static data is in two different sections: (ie gcc -g -Wl,-Mmap sol27.cc >& link-map.out) // on x86-linux // in .data // this works .data 0x080c7bcc 0x18 /mnt/hd/bliss/H-x86-libstdc++/lib/libstdc++.a(locale.o) 0x080c7bd0 ctype<char>::_S_tolower 0x080c7be0 ctype<wchar_t>::_S_table 0x080c7bcc ctype<char>::_S_toupper 0x080c7bdc ctype<wchar_t>::_S_tolower 0x080c7bd8 ctype<wchar_t>::_S_toupper 0x080c7bd4 ctype<char>::_S_table // on solaris27 // in .bss // this crashes .bss 0x000c3900 0x1a10 *(.dynbss) *(.bss) .bss 0x000c3900 0x18 /horton/bkoz/H-solaris27-gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtbegin.o *fill* 0x000c3918 0x8 .bss 0x000c3920 0x24 /horton/bkoz/H-solaris27-libstdc++/lib/libstdc++.a(locale.o) 0x000c3928 ctype<wchar_t>::_S_table 0x000c392c ctype<char>::id 0x000c3938 ctype<wchar_t>::id 0x000c3934 collate<char>::id 0x000c3930 codecvt<char, char, __mbstate_t>::id 0x000c3924 ctype<char>::_S_table Does anybody know what's up? Is this a problem with the solaris gnu linker, or what? More importantly is there a way to work around it? -benjamin
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |