Re: Problems with exception handling in glibc and gcc.

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

   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.

2. One of the reasons for this header is the fact that the glibc
   libc.so doesn't use the crtbegin.o/crtend.o that comes with GCC.
   Currently we have the following code in glibc:

   /* This must match what's in frame.h in gcc. How can one do that? */
   struct object
   {
     void *pc_begin;
     void *pc_end;
     void *fde_begin;
     void *fde_array;
     __SIZE_TYPE__ count;
     struct object *next;
   };
   extern void __register_frame_info (const void *, struct object *);
   extern void __deregister_frame_info (const void *);

   and we explicitly call __register_frame_info().  HJ's proposal
   answers the "How can we do that?" question, and solves the problems
   with IA64 which uses a `struct object' that differs from all the
   other architectures.

   However, wouldn't it be wiser to have a solution where we leave the
   frame registration procedure entirely in the hands of GCC?  Right
   now when the frame registration interfaces in GCC change, we'll
   have to adapt this bit of glibc before it will be possible to
   compile glibc with that new version of GCC.  Instead we could
   either have a set of generic macros in GCC's runtime.h:

   #define FRAME_INFO_STUFF \
     static char __EH_FRAME_BEGIN__[] \
       __attribute ((section (".eh_frame"))) = { };

   #define REGISTER_FRAME_INFO \
     {
       static struct object_buffer ob;
       __register_frame_info (__EH_FRAME_BEGIN__, &ob);
     }

   #define DEREGISTER_FRAME_INFO \
     __deregister_frame_info (__EH_FRAME_BEGIN__);
   
   and use those macro's in glibc, or have GCC install a little object
   module that contains the necessary stuff with a simplified
   interface that won't change:

   #include <runtime.h>

   static char __EH_FRAME_BEGIN__[]
     __attribute ((section (".eh_frame"))) = { };

   void
   __libc_register_frame_info (void)
   {
     static struct object_buffer ob;
     __register_frame_info (__EH_FRAME_BEGIN__, &ob);
   }

   void
   __libc_deregister_frame_info (void)
   {
     __deregister_frame_info (__EH_FRAME_BEGIN__);
   }

   and link it into libc.  It might be added to libgcc.a, but it
   cannot be part of a shared libgcc.  Of course this something on
   which the glibc maintainer has to agree as well.  And perhaps the
   *BSD people are interested in this stuff as well.
     
3. The `runtime.h' file should probably be installed in a special
   directory, not in the generic GCC include directory, to avoid
   header name clashes.

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.

Mark