This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC-3.0.1 can't compile Glibc-2.2.4


   Date: Tue, 25 Sep 2001 17:19:33 -0700
   From: "H . J . Lu" <hjl@lucon.org>
   Cc: jakub@redhat.com, libc-alpha@sources.redhat.com
   Content-Type: text/plain; charset=us-ascii
   Content-Disposition: inline
   User-Agent: Mutt/1.2.5i

   On Wed, Sep 26, 2001 at 01:57:54AM +0200, Mark Kettenis wrote:
   > 
   >    It seems to me that it will only happen in libc.so compiled by gcc 3.
   > 
   > What *exactly* will "only happen in libc.so compiled by gcc 3".

   You tell me *exactly* when dlopening libgcc_s.so.1 is useful. I am
   kind of slow on this. Pleae give some real examples.

With Jakub's patch every call to __frame_state_for will try to dlopen
libgcc_s.so.1.  But I assume you mean when it would be *necessary* to
dlopen libgcc_s.so.1.  This would be the case if the following
conditions are met:

1. C++ code compiled with GCC 2 throws an exception through a function
   foo() in a shared library, that is, the C++ code calls foo(), which
   in turns calls a (callback) function in the C++ code which throws
   an exception.

2. The shared library containing foo() is compiled with GCC 3.x which
   emits DWARF2 opcodes for foo() that are not handled by the unwinder
   that's integrated into glibc.

   >    Why can't we put a check in glibc such that only the compatible
   >    versions of gcc 3 can be used to compile glibc?
   > 
   > Define "compatible versions of GCC 3".  Assuming that you mean a
   > version of GCC 3 that doesn't emit DWARF2 opcodes that aren't handled
   > by the unwinder in libc.so: Adding the checks is possible (and in fact
   > I already posted a test that does these checks), but running them only
   > makes sense after you've built glibc.

   Or we ask gcc people to provide a way to tell if the new DWARF2 opcodes
   are added.

That could be useful.  Perhaps a better idea would be to ask the GCC
folks to implement an option that tells GCC to only use a well defined
subset of DWARF2.  We know that we can express the frame info for the
current code in glibc with such a subset.  I don't know whether it is
easy to implement this in GCC though.  This certainly would remove the
need to dlopen libgcc_s.so.

   >    That is __frame_state_for in glibc should be compatible with the
   >    gcc 3 used to build it.
   > 
   > That means that we'll have to upgrade the code in glibc every time GCC
   > is changed to emit new DWARF2 opcodes.  Several people have said
   > that's undesirable.

   Why? Otherwise, how can you give such precompiled libc.so to other
   people? How do you know they will have the compatible libgcc_s.so.1
   installed? That means glibc is no longer a self-contained library
   since it depends on a particular libgcc_s.so.1. If it is what we want,
   why do we even bother to add all those new libgcc functions in libc.so?
   We just add -lgcc to libc.so when we use gcc 3.x to build glibc. I
   thought the whole idea is we could run libc.so without a libgcc_s.so.1.

Of course we will upgrade the code in glibc every now and then.  It's
just that we must avoid being forced to do so just because GCC emits a
new DWARF2 opcode.  We must avoid the situation that we face now where
people fear to upgrade to GCC 3 because you cannot compile glibc with
it.

Giving such a precompiled libc.so to other people is very well
possible.  You just make sure that you'll also pass along a recent
libgcc_s.so, if you used a GCC version that's not supported by the
code in libc.so.  My understanding is that the modern packaging
systems are perfectly able to cope with this.

So the packaging system will make sure that a recent enough
libgcc_s.so.1 is installed.  And if you're compiling from source,
'make check' will fail if you don't have it.

Yes, in a sense this means that glibc is no longer a self-contained
library.  But only for legacy C++ applications, and even then, only
for those applications that throw exceptions through a small number of
glibc functions, and only if a version of GCC will actually emit the
new DWARF2 opcodes for these functions.  That's a very limited number
of applications, which will only decrease over time.  I don't expect
any of these applications to be "essential".  You'll always be able to
fix any problems by letting people install a new libgcc_s.so.

This is *very* different from the case where we would just link glibc
against libgcc_s.so, which would affect all programs.

   >    Is that too much to ask?
   > 
   > I don't know.  Why do you think dlopening libgcc_s.so.1 is not a good
   > idea?  Is it just that you fee that it needlessly adds a little
   > complexity, or do you have a possible scenario in mind where it will
   > fail?

   When we do that, we put the libgcc_s.so.1 dependency on glibc.
   Unfortunately, libgcc_s.so.1 is not the part of glibc. We have no
   control what is in installed libgcc_s.so.1 and if it is installed.

As I said above, the dependency is not very strict.  It only kicks in
in some corner cases.

As long as the compiler engineers keep their part of the deal, and
properly maintain the libgcc_s.so ABI, we don't have to know what's in
the installed libgcc_s.so.1.  Making sure whether a proper
libgcc_s.so.1 is installed is the job of the distribution makers.  Not
ours.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]