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]

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)




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]