A new libgcc symbol patch

[Zack Weinberg]

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

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.

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.

Incidentally, we should localize libgcc symbols everywhere we can.
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?

zw