Re: Problems with exception handling in glibc and gcc.

["H . J . Lu" <hjl at lucon dot 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.


> 
> 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.

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".

>      
> 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.

A good idea, how about .../include/gcc/runtime.h?

> 
> 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.


H.J.