This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
solaris27 + libstdc++-v3 + -static == core in ctype_char_members.c
- To: bkoz at cygnus dot com, libstdc++ at sourceware dot cygnus dot com
- Subject: solaris27 + libstdc++-v3 + -static == core in ctype_char_members.c
- From: Benjamin Kosnik <bkoz at cygnus dot com>
- Date: Wed, 1 Mar 2000 14:50:28 -0800
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