This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libstdc++ libtool lossage


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:

Program Headers:
  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.


r~


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