std::string crasher - _S_empty_rep_storage hidden visibility bites my backside
John Love-Jensen
eljay@adobe.com
Mon Jun 16 16:14:00 GMT 2008
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)
More information about the Gcc-help
mailing list