This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

solaris27 + libstdc++-v3 + -static == core in ctype_char_members.c



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]