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

[Jakub Jelinek <jakub at redhat dot com>]

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.

> 2001-07-02  H.J. Lu  (hjl@gnu.org)
> 
> 	* config/t-linux (TARGET_LIBGCC2_CFLAGS): Add
> 	-DNEED__frame_state_for.
> 
> 	* unwind-dw2.c (_Unwind_FrameState): Add eh_ptr for g++ v2.
> 	(extract_cie_info): Extract eh_ptr for g++ v2.
> 	(__frame_state_for): New. Define if NEED__frame_state_for is
> 	defined.

	Jakub