Re: We still need those old frame functions in libgcc.a

[Jason Merrill <jason at cygnus dot com>]

>>>>> H J Lu <hjl@lucon.org> writes:

> Let me try again to explain why we need to keep the
> old __register_frame in libgcc.a.

I disagree.

> A. __register_frame and shared libraries.

> 1. gcc builds shared libraries with crtbegin.o.
> 2. crtbegin.o calls __register_frame.
> 3. gcc builds shared libraries with -lgcc.
> 4. The shared libraries built by gcc have __register_frame
>    which is visible by linker because of 1, 2, 3.

Sure, fine.

> If we leave -lgcc out, linker will leave __register_frame
> undefined in shared libraries, we have to keep
> __register_frame in libgcc.a in new gcc. Otherwise, during
> the link time, ld will find undefined __register_frame
> referenced by shared libraries when new gcc is used.

So don't leave out -lgcc.

> B. We have to keep __register_frame in libgcc.a.

> 1. Say binary "foo" needs libbar.so, since __register_frame
> is in libbar.so, linker will leave __register_frame
> undefined in foo and the dynamic linker will find
> __register_frame in libbar.so at the runtime.

Why would the linker add undefined symbols that are not used by foo, but
rather shared libraries linked with foo?  I don't think any linker actually
works that way.  libbar.so can look out for its own undefined symbols.

> 2. If we remove __register_frame from libgcc.a in new
> gcc and we rebuild libbar.so with the new gcc, now
> libbar.so won't have __register_frame. Now the dynamic
> linker won't find __register_frame at the run time
> since it is no longer in libbar.so. We are in a big trouble.

No, we aren't, because now nobody wants __register_frame.

Jason