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: Fri, 14 Jul 2000 12:44:29 -0700 From: Geoff Keating <geoffk@cygnus.com> > Tightly controlling the libgcc.so ABI is extremely important. The > SONAME of libgcc can *never* change (at least not without changing the > libc SONAME too) on Linux and the Hurd. On the bright side these > systems use the complete GNU toolchain which means that we have a lot > more tools to avoid this than other platforms. Yes, this is required. I think it's a good idea for other platforms too. Sure :-). It doesn't require any special tools---to be precise, special tools don't help. Well, we need the help from our tools on Linux to solve the the problem with the frame functions living in glibc (versioning and perhaps DT_AUXILIARY). For instance, symbol versioning is to solve the problem of how to have two functions named printf(), but this isn't needed for libgcc because if we (say) want to change the interface of _adddi3, then we can just call the new function _adddi3_2. Which is so simple that it probably works for all platforms (although you'd probably call it _adddi4 :-)). ... > And actually building a shared libgcc > *before* the GCC team is committed to mainting binary compatibility of > the stuff we're going to put into it is pointless. > Instead I'd like to start working with the GCC team on establishing an > ABI for that shared libgcc. I could sure use some assistence on that > from GCC developers interested in Linux. The GCC team is already committed to binary compatibility with older versions of gcc, like 2.95.2, so we could start with that. In fact, we have to start with that. I'm afraid gcc 2.8 and the various egcs releases will have to be taken into account, at least for various x86 targets, and at least for plain C. A lot of C++ devlopers still use egcs 1.1.2 since allegedly gcc 2.95.2 tends to produce too many ICE's. Linking with older object files and static libraries isn't essential, but interaction with shared libraries is. But I think that's doable, it just takes some time to do some field testing, the problem being that stuff on development machines tends to be recompiled too often, making it hard to find old libraries. Now, what else would we like? As a starting point, I think that if we're going to change the frame.o ABI, we should change it to something more future-proof. Or do we want to export the eh.o ABI? In that case we'd better wait for the new C++ ABI, too. The frame.o (now mostly frame-dwarf2.o I guess) and eh.o modules are coupled via __frame_state_for(). The problems that more or less started this thread suggest that __frame_state_for() was (accidently) regarded as an internal interface. In that case the frame.o and eh.o modules have to match, and the EH ABI would have to be fixed as well. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |