Re: A completely different approach to EH runtime

["H . J . Lu" <hjl at valinux dot com>]

On Tue, Feb 20, 2001 at 10:04:05PM -0800, Zack Weinberg wrote:
> 
> This should just work on every platform which does not use GNU libc.
> On platforms which do, there is an additional complication: glibc
> presently contains its own copy of the eh routines, dragged in from
> libgcc.a.  For this scheme to work, those copies have to be made
> invisible at link time, and the executable's copies have to be used at
> load time if present, but if they aren't, then libc's copies have to
> be used.  I don't know if this is feasible.
> 
> Why does glibc contain the eh routines?  It was the best solution
> available at the time (late '98, IIRC) to the__register_frame and
> __register_frame_info fiasco.  Go look up the flame wars on gcc,
> gcc-patches, and libc-hacker.  There were about five of them.
> 

I believe the glibc people are capable to work around any libgcc
problems. The key is any libgcc solution on Linux in gcc 3.0 has
to be blessed by the glibc people:

1. The gcc people have to agree that a shared libgcc fiasco is waiting
to happen on Linux.
2. The gcc people have to ask for feedbacks/solutions from the glibc
people.

But given that none of the gcc people see a fiasco coming on Linux, I
don't how it can be resolved in gcc 3.0. The way I see it is

1. gcc 3.0 is released sometime this year.
2. All Linux vendors discourage gcc 3.0 on their distributions without
modifications.
3. Someone comes up with a Linux patch for gcc 3.0.
4. A gcc 3.x for Linux is released.

It seems gcc 2.7.2.3 all over again :-(.


-- 
H.J. Lu (hjl@valinux.com)