This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Problems with exception handling in glibc and gcc.
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.