[PATCH] D28791: [compiler-rt][crt] Simple crtbegin and crtend implementation

Roland McGrath via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 8 15:08:25 PST 2017


mcgrathr added a comment.

The comments about this being part of libc implementation are exactly
wrong.  There is little or nothing in crtbegin/crtend that has anything
to do with libc.  It's entirely to do with what the compiler emits, what
the linker does, and what other runtime code (not libc) you are using:

(1) Should EH frame registration be attemped?

This has entirely to do with the ABI contract between the
compiler-generated unwind info and the unwinder runtime library.
The unwinder runtime is not part of libc.

In GCC, the unwinder is provided as part of libgcc.
Elsewhere, you have an implementation like libunwind or whatever.

If the compiler driver tells the linker to generate PT_GNU_EH_FRAME
(--eh-frame-hdr switch) and the unwinder runtime knows how to find all
the modules and their PT_GNU_EH_FRAME segments, then that's all you
need.  If the unwinder runtime needs some explicit registration calls at
startup, that's part of the unwinder library ABI.  libc is not involved.

On Linux systems, usually the unwinder runtime being used is like the
libgcc one, so it works via PT_GNU_EH_FRAME for dynamic linking but
requires calls to its registration API functions for static linking.
The details of that depend on the unwinder runtime alone.

(In some configurations, glibc does export an unwinder ABI.  That is
solely for backward compatibility with old binaries that were linked
against much older GCC versions of crtbegin/crtend/libgcc.  Since things
linked today aren't linked with those old GCC artifacts, no binary you
produce today will or should ever use glibc's unwinder ABI.)

(2) Who is responsible for iterating .ctor/.dtor?

This has entirely to do with what the compiler emits and what the linker
does.  If the compiler emits .init_array/.fini_array directly, there is
no need for anything else.  If the compiler emits .ctors/.dtors and the
linker folds those into .init_array/.fini_array, there is no need for
anything else.  If the compiler emits .ctors/.dtors and the linker emits
them unchanged, then some code to iterate them is required.  In none of
these cases is libc relevant.

(3) Is __cxa_atexit supported by the platform?

The C++ front-end emits calls to __cxa_atexit and references to
&__dso_handle.  If the C++ front-end is going to do that, then there
needs to be a definition of __dso_handle somewhere.  The name
__dso_handle is not part of the ABI contract with the C library or
anything else.  It's entirely a name chosen by the C++ front-end.

On modularity principles, __dso_handle really belongs in libc++abi.
However, for implementation reasons it needs to be included statically
into each final link (whether executable or shared library), even when
libc++abi is found entirely in a shared library.  So libc++abi, and the
compiler driver rules to link it in, would need to provide a static
library (or .o file) to the link in addition to the shared library,
which they don't do today.  So it's simpler on the implementation side
to put this into some existing .a or .o file that is always statically
linked.  crtbegin.o is where GCC defines it, but there's no principled
reason for it to be there.  It might as well be in an archive library
instead, so it's omitted from links that don't actually use it (such as
ones with no C++ or no destructors).  Any existing archive library that
is always statically linked in every link would do, e.g. clang_rt-builtins.

(4) Are Java types supported?

This has to do with things that the old GCC Java front-end (GCJ) emits.
If you don't use that Java front-end, you don't need them.  In no case
does anything about your Java support choices have anything to do with
the C library.


Repository:
  rL LLVM

https://reviews.llvm.org/D28791





More information about the llvm-commits mailing list