Re: A new libgcc symbol patch

[hjl at lucon dot org (H.J. Lu)]

> 
> 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)