This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ libtool lossage
- From: Richard Henderson <rth at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "java-patches at gcc dot gnu dot org" <java-patches at gcc dot gnu dot org>
- Date: Sat, 23 Feb 2002 17:01:59 -0800
- Subject: Re: libstdc++ libtool lossage
- References: <firstname.lastname@example.org> <email@example.com>
On Sat, Feb 23, 2002 at 04:50:25PM -0800, Mark Mitchell wrote:
> (Parenthetically, that suggests that my memory was probably of the
> executable creation behavior; when linking a final executable "gcc"
> linked in the static libgcc but "g++" linked in the shared libgcc?
> (And also the static one, or not?) Is this right?)
Correct. Your memory is of executables, not shared libraries.
> And you're saying that now some bit of binutils wizardy means that
> on sufficiently modern GNU/Linux machines we could created C shared
> libraries without linking with any libgcc at all?
Yes. Previously, every shared library refered to at least two
EH functions: __register_frame_info and __deregister_frame_info.
New binutils produces an ELF Phdr PT_GNU_EH_FRAME like so:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000000085c8 0x00000000000085c8 R E 10000
LOAD 0x00000000000085c8 0x00000000000185c8 0x00000000000185c8
0x0000000000001028 0x0000000000001088 RWE 10000
DYNAMIC 0x0000000000009100 0x0000000000019100 0x0000000000019100
0x00000000000001b0 0x00000000000001b0 RW 8
GNU_EH_FRAME 0x0000000000008414 0x0000000000008414 0x0000000000008414
0x00000000000001b4 0x00000000000001b4 R 4
This header, among other things, allows us to locate the unwind
info of an executable or shared library without it having to be
registered. When we handle an exception, we simply iterate over
all of the loaded libraries (via glibc magic), and look at each
set of unwind info in turn.
Thus for a normal C shared library, there are no longer *any*
calls into the EH functions, which means that we don't need them,
which means that we don't need libgcc_s.so, which means that we
should be able to speed up program load times by not pulling it in.