This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Date: Mon, 10 Jul 2000 08:03:57 -0700 From: "H . J . Lu" <hjl@valinux.com> I haven't heard any feedbacks about my proposal for the libgcc runtime ABI: http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html But I think the current situation is quite broken. Indeed it is. And apparently people aren't very eager to do something about it. The fact that your "proposal" isn't really shocking might have something to do with it. Let me explain. The ABI you're proposing does already exist. Changing `sizeof (struct object)' or changing the calling convention of the functions mentioned in your runtime.h isn't possible anymore for supported targets with working exception support in gcc 2.95 or egcs 1.0.3 or so (and has indeed been impossible for quite a while now for some of those targets). So you're either just trying to formalize things, which is fine with me, or you're proposing something that cannot be done. Adding a new ABI without continued support for the old one isn't possible either unless you want to force people to recompile everything with the new gcc. On Linux (and the Hurd) the problem is even worse. Since the frame info registration functions are present in libc.so, you cannot simply add a new ABI without forcing everybody to patch and recompile libc. If we plan ahead it is certainly possible to ease the pain considerably, but this requires a lot of cooperation between the glibc and GCC teams, and depending on the solution that's chosen, probably quite a bit of time (in the order of months). If this isn't done, deploying GCC 3.0 on Linux will become a terrible nightmare. I'm having some problems with "libgcc runtime ABI". Right now libgcc is a pile of junk that contains some basic support functions (e.g. for long long and floating point arithmetic), the exception handling stuff (both registration of EH frame info, and the language independent EH runtime stuff), and some sort of C++ runtime (operator new, rtti, etc.). Your proposal is at best a specification of the "libgcc EH frame info registration ABI". In that respect, the name "runtime.h" seems not very appropriate to me. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |