This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A new libgcc symbol patch
- To: zack at rabi dot columbia dot edu (Zack Weinberg)
- Subject: Re: A new libgcc symbol patch
- From: hjl at lucon dot org (H.J. Lu)
- Date: Sun, 13 Dec 1998 11:25:33 -0800 (PST)
- Cc: egcs-patches at cygnus dot com
>
> On Sun, 13 Dec 1998 09:22:01 -0800 (PST), H.J. Lu wrote:
> >Hi,
> >
> >Here is my second libgcc symbol patch. My first one made too many
> >libgcc functions local to the shared library. In this patch, I created
> >the list of functions by hand. I hope I did it right this time.
> [...]
> >+LIBGCC_MAP_LIST=__ashldi3 __ashrdi3 __builtin_saveregs __clear_cache \
> >+ __cmpdi2 __divdi3 __dummy __eprintf __ffsdi2 __fixdfdi __fixsfdi \
> >+ __fixunsdfdi __fixunsdfsi __fixunssfdi __fixunssfsi __fixunsxfdi \
> >+ __fixunsxfsi __fixxfdi __floatdidf __floatdisf __floatdixf \
> >+ __gcc_bcmp __lshrdi3 __moddi3 __muldi3 __negdi2 __pure_virtual \
> >+ __ucmpdi2 __udiv_w_sdiv __udivdi3 __udivmoddi4 __umoddi3
>
> You left out the functions that were causing the problem in the first
> place:
>
> __deregister_frame
> __deregister_frame_info
> __frame_state_for
> __register_frame
> __register_frame_info
> __register_frame_info_table
> __register_frame_table
I left out them on purpose since there should be the exactly the one
copy of them in the executable and in the shared liibraries. Think if
we have
__frame_state_for ()
{
static int init = 0;
if (init)
return;
init = 1;
.....
}
It won't work if we have more than one copies. I only make those libgcc
functions which I know can be safely made local in the shared library.
BTW, glibc 2.1 doesn't have any problem with it. Neither does the
current glibc 2.0 in CVS.
>
> But I think the approach here is wrong. You should have a list of
> exceptions and localize all symbols but those. The exception list
> looks something like this:
>
> __nw_FUiPv
> __vn_FUiPv
> terminate__Fv
> uncaught_exception__Fv
> unexpected__Fv
>
> since these are the only ones that the user may override.
I tried that. We may not make any functions which have local static
variable local to the shared library. I want to play it safe. It is
also possible that we may add more functions to libgcc. They should
only be made local manually after they are examed.
>
> It might be better to move *all* C++ specific support functions out of
> libgcc into libstdc++, which is a shared library when possible. I
> think it's more likely that the semantics will be correct then.
That is essentially the end result of my patch. I left out ALL
C++ specific support functions from libgcc.map.
>
> Incidentally, we should localize libgcc symbols everywhere we can.
Be careful about the symbols in libgcc. You have to examine them
one by one. Don't assume anything.
> Solaris >2.6 supports version maps, other ELF systems should follow
> shortly. Maybe GNU ld has a way to do this even when not ELF?
>
FYI, my patch should work on ALL ELF systems with the GNU linker since
it doesn't really use symbol versioning.
--
H.J. Lu (hjl@gnu.org)