Problems with exception handling in glibc and gcc.
Mark Kettenis
kettenis@wins.uva.nl
Mon Jul 31 07:43:00 GMT 2000
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
More information about the Libc-alpha
mailing list