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] |
Hi- I'm fairly new to this list, and not on the gcc list at all, but I've been doing a lot of "listening and learning", and thought that I would share my practical experience with compiler/library interaction and ABI specification. One of my primary responsibilities at IBM is best described as "binary compatibility police". I'm the person who gets called when any customer's application/device driver/kernel extension stops working. We have to support binaries produced years ago on previous *versions* of AIX, not just previous releases. Also, I have work ABI specification documents, to be usable by clones and OEMs, for AIX on PowerPC, and a UNIX for IA-64. While I am not yet technically competent to discuss the particulars of gcc/Cruntime interaction, I do feel that I might be able to add content in general with regard to shared libs and ABIs. AIX is also an OS (like GNU/Linx) that has separate "ownership" of C runtime and compiler (though this is not true for other language runtime/compilers offered on AIX). IBM's C compiler is offered on platforms besides AIX. We learned early along that the low-level function (found in libgcc in this case) is best maintained by the platform, since the platform is ultimately responsible for the ABI in the users' view -- not the compiler. This is even true for the C++/thread exception handling work; the compiler team came to us and we did the work to come up with a design that maintained source and binary compatibility in our runtime. Yes, the compiler determines a lot of things basic to the total ABI, but the platform loader/library is where the "rubber meets the road" and that what this code in libgcc truly covers. I see the same situation applies here -- even more so, since gcc operates in places without shared libs or glibc at all. What I see is that the platforms need to assume ownership of this, but gcc needs to document the things it needs to see from it, and only the things it needs to see, and leave the rest to the platform- specific version of libgcc. Maybe the gcc team will "pick up" ownership for platforms that cannot maintain it themselves, but trying to maintain all of them is something I would not recommend. This is just opinion based on similar practical experience; I am still learning to understand H. J. Lu's idea and so cannot comment on it. -- Mark S. Brown bmark@us.ibm.com IBM RS/6000 AIX System Architecture 512.838.3926 T/L678.3926 IBM Corporation, Austin, Texas
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |