[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
------- Comment #81 from geoffk at geoffk dot org 2005-10-31 23:29 -------
Subject: Re: libstdc++ headers should have pop/push of the visibility around
the declarations
On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote:
> ------- Comment #80 from mueller at kde dot org 2005-10-31 22:45
> -------
> - not hiding a symbols is better than the resulting issues when
> hiding a symbol
> which should be exported. for example right now the function
> static pointer
> pointing to libstdc++'s memory allocator is hidden, which causes
> STL usages
> to just randomly crash when used across linking boundaries.
> crashing is worse
> than the performance penality by exported symbols
>
I wasn't thinking so much of the performance penalty, but rather of
the ABI impact. Suddenly, your dynamic library, which you thought
had carefully controlled exports (maybe it shouldn't export any C++
interfaces of its own at all), is exporting a global C++ type,
'std::vector<mytype>', which could conflict with any similarly-named-
but-different type anywhere in a program that uses the library.
Performance is also a concern, of course.
> - of course just exporting those classes that *should* be exported
> would be
> much more clever. I just thought if its so difficult to get a
> brain-dead
> simple patch that makes everything work not getting applied within
> 6 months
> then the stripped-down just-exporting-what-is-really needed (which
> requires
> a lot of in-depth knowledge and a lot of testing) would need more
> something
> like 6 years to get applied.
>
> Anyway, I volunteer to help reducing the amount of exported classes
> if thats
> what makes you apply the patch. The current brute-force export-all
> patch
> fixes everything and is dead simple compared to such a "only export
> what
> is needed patch".
>
Well (after re-reading what the bug was originally about):
- You'll notice that the bug is about things which are not defined in
this library, which can't possibly include the things I'm concerned
about above, since every part of std::vector<mytype> must be defined
in this library since nothing else knows about 'mytype'. So it's
certainly possible to fix it.
- But, I'm not sure that the front-end supports everything you'll
need to mark all the right pieces. For instance, ctype<mytype> has
to be hidden, but ctype<char> has to be not hidden. It would
probably be easier to teach the front-end that "if I'm instantiating
something, the resulting thing must have the most restrictive
visibility of any of its parameters" than it would be to go around
trying to put attributes on each little method.
- If that's too hard to do in time for 4.1, we could at least fix the
related problems for non-x86-64 systems, which have to do with the
classes thrown as exceptions; it's not useful to compile them with
hidden visibility, since they're passed between libraries. (They're
mostly in libsupc++.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: