Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Jul 12, 2000 at 01:30:47PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 12 Jul 2000, Martin v. Loewis wrote:
> >
> > > Wouldn't it be better to _not_ consider this to be part of libgcc, and
> > > instead have a well-defined EH record format and just tell people to use
> > > it in their system libraries.
> > 
> > There is a well-defined format. The problem is that you need a
> > process-wide list of such structures, to find the entry points into
> > the structures when an exception is thrown in one library and caught
> > in another.
> 
> But what has this got to do with gcc?
> 
> Nothing. It's a systems issue. Gcc just needs to honor the format, the
> same way gcc needs to generate a lot of other "helper" information (which
> is, of course, mainly for debugging, but things like global namescape
> information is a similar thing where gcc emits certain records to tell the
> assembler which symbols are global etc).
> 
> If the format is well-defined, then you should consider this to be a
> loader and systems thing, not a gcc thing. Why are the routines in libgcc
> at all? Why aren't they in the loaders, or the libraries?
> 
> I think it was Kenner who said that libgcc should only contain code that
> is actually called by gcc-generated code. That's a good definition of what
> libgcc used to be. Why not go back to that, and leave the whole EH thing
> into the hands of the glibc and other people working on libraries and
> systems issues.

This makes sense to me.  Note, however GCC does call the EH functions, and it
needs to know how to lay out the tables, so there are definite ABI issues
involved.  Note, you can't use include file magic if glibc ever wanted to
change the format, since the compiler will be generating the information as
part of code generation.  GCC does have to provide the complete EH setup for
systems that don't provide EH (including glibc 2.1), and will continue to have
to provide it, which means the core of EH functions will be implemented twice,
once in GCC to support systems whose libraries don't support EH (including
embedded processors), and once in glibc.  I would say, that whatever new
version of __register_frame_info include a version # so that we don't have the
same problem come bite us 2 years hence.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482