Re: PATCH: Re: GCC vs GLIBC: why this stance, Drepper ?!?

["H . J . Lu" <hjl at lucon dot org>]

On Mon, Jul 02, 2001 at 03:48:50PM -0400, Jakub Jelinek wrote:
> On Mon, Jul 02, 2001 at 12:45:38PM -0700, H . J . Lu wrote:
> > On Sun, Jul 01, 2001 at 12:02:18PM +0200, Jakub Jelinek wrote:
> > > 
> > > You can surely recompile it, but it won't be binary compatible.
> > > __frame_state_for will be missing, plus glibc won't export the needed new
> > > __register_frame_info_bases etc. symbols, so if you mixed such glibc and
> > > some G++ 3.0 compiled library, you'd use two different registration points
> > > for shared libraries, one in glibc, one in probably libstdc++. So things
> > > would or would not work properly depending on the particular library order
> > > (e.g. try dlopening a library written in C++ from a C only main program and
> > > throw exceptions through sort).
> > > 
> > > GLIBC definitely needs a __frame_state_for implementation, plus its
> > > interaction with libgcc_s.so needs to be decided (see
> > > http://sources.redhat.com/ml/libc-hacker/2001-06/msg00020.html).
> > > 
> > 
> > Here is an UNTESTED patch. I don't believe it is even correct. It
> > only compiles. I think unwind-dw2.c is the best place to add
> > __frame_state_for. Any comments?
> 
> Richard explicitely said he does not want to put this old cruft into
> libgcc_s, so we need to hack this in glibc for platforms which need that.

Same here. See

/* This provides the backward compatibility for existing binaries
   compiled against g++ v2 dwarf 2 frame based exception.
   
   FIXME: We really need this in libgcc.a only.  */

It should be in libgcc.a only, not in libgcc_s.so. I will found a way
to do it after we get it to work first.


H.J.