std::string crasher - _S_empty_rep_storage hidden visibility bites my backside

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi everyone,

I¹m running into a problem with empty std::string objects.

My packages are build with -fvisibility-ms-compat.  They really, really have
to be built that way.  Take it as a given.  I am aware of the dangers.

The empty std::string optimization is causing each package to have its own:

std::basic_string<C,T,A>::_Rep::_S_empty_rep_storage

When an empty std::string is passed from one "package" (DLL) into the space
of another package, and destructed in the scope of the other package, the
std::string BSS (or DATA?) _S_empty_rep_storage gets heap deallocated.

That can't be good.

NOTE: _GLIBCXX_FULLY_DYNAMIC_STRING is not defined.

What would be the best way to either:

Set _GLIBCXX_FULLY_DYNAMIC_STRING to be defined?  (I presume I shouldn't
just do -D_GLIBCXX_FULLY_DYNAMIC_STRING ... that seems wrong.)

Build with std::basic_string<C,T,A>::_Rep::_S_empty_rep_storage have default
(instead of hidden) visibility?

NOTE: Hand editing the basic_string.h file to annotate the
_S_empty_rep_storage with __attribute__((visibility("default"))) being "not
an option".

Is there a way to twiddle the visibility of _S_empty_rep_storage? Perhaps
with a linker script?  (Does the Mach object file link editor support that
kind linker scripts?)

Thanks,
--Eljay

: gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux