This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
On Fri, Feb 23, 2001 at 01:00:07AM -0800, Richard Henderson wrote:
> On Fri, Feb 23, 2001 at 12:43:35AM -0800, Zack Weinberg wrote:
> > I know there's a way to get exactly one copy of a data symbol
> > in ELF no matter how many shared libraries define it.
>
> No there isn't. Not really.
>
> > The new C++ ABI uses it for RTTI.
>
> The new C++ ABI attempts to use linkonce symbols for RTTI,
> but is broken in corner cases. I've mentioned this before
> on the lists, btw.
>
> Let me 'splain again a failing scenario.
>
> libfoo and libbar are compiled and linked separately. Let's say
> that they're intended to be dynamicly loaded, and as such both
> export the same set of symbols. The application, expecting this,
> dlopens them without RTLD_GLOBAL.
>
> In this situation, libfoo sees _none_ of libbar's symbols. There
> is no cross-resolution of any kind. Any scheme which relies on
> same has just fallen over.
>
> There are other similar scenarios involving -Bsymbolic.
The last time you tried to explain this I didn't understand it, but
this time I do. I'm now wondering how lethal this is to the RTTI
scheme and whether we can do anything about _that_ before 3.0.
Anyhow, it seems the "just make it a global" idea doesn't work. But
how about this modification: Put a global symbol _in the executable_
(via crtbegin.o, since we don't control crt1.o) which the libgcc
routines look for. Since it's just one pointer, no harm is done by
including it in every executable, whether we know we need it or not.
Hm, actually, we might need that and a mutex. I don't know how we
make register_frame_info be thread safe. Still, it's not a huge
amount of memory; 16 bytes or so.
Except that there are funnies with whether or not symbols in the
executable are visible to dynamically loaded objects. Drat.
zw