This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A completely different approach to EH runtime


On Wed, Feb 21, 2001 at 09:20:45AM -0800, H . J . Lu wrote:
> 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:
[snip]

This is the same thing you've said already.  I'm not interested in
going round in circles about whose responsibility the problem is.  If
you don't have anything to say about my specific proposal, please
don't respond to my specific proposal.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]