Re: Problems with exception handling in glibc and gcc.

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Mon, 31 Jul 2000 09:16:16 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Mon, Jul 31, 2000 at 04:43:10PM +0200, Mark Kettenis wrote:
   >    From: Jason Merrill <jason@redhat.com>
   >    Date: 28 Jul 2000 22:16:09 -0700
   > 
   >    Looks pretty good.  But there's no reason to declare the foo_frame
   >    interfaces in the runtime.h header, since new code shouldn't call
   >    them.  And I'd prefer a name like "object_buffer" rather than
   >    "frame_object", to clarify that it isn't a real object.
   > 
   > HJ's "discussion patch" has a couple of problems.  Here's a list, the
   > most important ones listed first:
   > 
   > 1. The `struct frame_object/object_buffer' is declared as:
   > 
   >    struct frame_object
   >    {
   >      /* It should be large enough for future expansion. */
   >      void * dummy [16];
   >    }; 
   > 
   >    At least the comment is pretty misleading.  Future expansion is
   >    pretty much impossible, at least if you want to retain binary
   >    compatibility with code compiled with GCC 2.95.  In that view it
   >    would be sensible to make sure that `sizeof (struct object_buffer)'
   >    is exactly right, and add a comment that it cannot be changed.

   I don't see how it can be a problem if you pass a pointer to a memory
   which is larger than needed. We didn't know IA64 wants more fields
   when we first defined it, how can you know everything in the future
   now? I don't even know 16 is enough.

Sure, you can do that, but it's not clear from the comment that the
extra space is only there for use by *new* targets.  A GCC developer
might look at the structure and come to the conclusion that there's
plenty of room to add stuff to `struct object' in frame.h.  That must
be avoided.  The most reliable way to accomplish that is to make sure
that the public definition of the object buffer structure has exactly
the right size, add a comment on it that its size should not be
changed, and change the assertion you added to __register_frame_info
to check if the size matches *exactly*.

If IA64 wants more fields, and hence a differently sized structure GCC
could just install a different version of the header, or you could
add some #ifdef's to accomplish this.

   >    However, wouldn't it be wiser to have a solution where we leave the
   >    frame registration procedure entirely in the hands of GCC?

   I don't see how useful it is. When we define "runtime.h", we are
   basically saying nothing will be changed in "runtime.h" unless everyone
   agrees. I don't see anything wrong for glibc to use things
   defined/declared in "runtime.h".

Well, if that's what you want, please spell it out in a comment in the
header.  However I'd advice the GCC developers to reject that
proposal.  It needlessly restricts the ability of the GCC developers
to add new interfaces.

What's the problem with the GCC people changing the interfaces as long
as they maintain backwards compatibility?

   > 
   > 4. The name `runtime.h' seems to be rather poorly chosen.  Depending on
   >    what stuff might be added in the future something like `eh.h',
   >    `eh-frame.h' or `frame-info.h' would be more appropriate.

   If that is all in "runtime.h" and we have no plan to add new stuff
   into it, it is a not bad idea. However, I'd like to leave the option
   open.

If the stuff is related to the frame info or EH stuff it can go in the
same header.  If it's unrelated it should go in a different header.
We shouldn't create a maze of header files, but a little structure
wouldn't hurt IMHO.

Mark