[LLVMdev] [lld] Handling multiple -init/-fini command line options
simon at atanasyan.com
Mon Dec 8 11:35:43 PST 2014
If we want to be able to add functions to init_array using command line we
can introduce new options like -init-array / -fini-array
On Dec 8, 2014 10:22 PM, "Simon Atanasyan" <simon at atanasyan.com> wrote:
> On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran
> <shankare at codeaurora.org> wrote:
> > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote:
> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote:
> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as
> >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one
> >>> initalizer function/finalizer function respectively.
> >> This is not true. The difference is that the DT_INIT / DT_FINI function
> >> is responsible for calling into the .init / .fini block and for
> >> DT_INIT_ARRAY / DT_FINI_ARRAY, the block is explicitly defined as a
> >> list of pointers and it is the responsibility of either the CRT logic or
> >> the dynamic linker to call them.
> >> That said, I don't think more than one DT_INIT / DT_FINI entry should be
> >> allowed as the latter entry will overwrite the earlier ones.
> > Thanks Joerg, The snip of code that appears to run the init/fini was
> > browseable with musl.
> > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c (function:
> > do_init_fini).
> > That said, all of the code is essentially under NO_LEGACY_INITFINI, is
> > linker responsible to convert DT_INIT to DT_INITARRAY's ?
> > If so, I think more than one init/fini option should be converted to
> > DT_INIT_ARRAY (or) DT_FINI_ARRAY respectively ?
> By the way, gnu linker support both DT_INIT and DT_INIT_ARRAY tags at
> the same time. For example, if input objects contain .init_array
> section and _init symbol, gnu linker emits both DT_INIT and
> DT_INIT_ARRAY tags. And I still do not see any reason to assign more
> complicated semantic to the -init/-fini options and introduce
> incompatibility with gnu linker.
> Simon Atanasyan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev