Simon Atanasyan
2014-Dec-08 19:22 UTC
[LLVMdev] [lld] Handling multiple -init/-fini command line options
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 easily > 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 the > 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
Simon Atanasyan
2014-Dec-08 19:35 UTC
[LLVMdev] [lld] Handling multiple -init/-fini command line options
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 > easily > > 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 > the > > 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141208/117360dc/attachment.html>
Shankar Easwaran
2014-Dec-08 19:57 UTC
[LLVMdev] [lld] Handling multiple -init/-fini command line options
On 12/8/2014 1:22 PM, Simon Atanasyan 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 easily >> 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 the >> 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.The dynamic loader handles only one entry for DT_INIT. If there is more than one init option, we could convert this as an .init_array instead ? If that doesnot work, we can come up with a .init_array option but I am not sure about how will you handle priority with init_array's ? Do you set linker defined init/fini symbols the last in priority ? Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
Simon Atanasyan
2014-Dec-08 20:26 UTC
[LLVMdev] [lld] Handling multiple -init/-fini command line options
On Mon, Dec 8, 2014 at 10:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> The dynamic loader handles only one entry for DT_INIT. If there is more than > one init option, we could convert this as an .init_array instead ? > > If that doesnot work, we can come up with a .init_array option but I am not > sure about how will you handle priority with init_array's ? Do you set > linker defined init/fini symbols the last in priority ?My idea: 1. -init/-fini options affects DT_INIT/DT_FINI tags only. If there is no any option, the linker searches _init/_finit symbols and configure DT_INIT/DT_FINI tags. This behaviour exactly corresponds to the GNU linker. By the way symbols specified in the -init/-fini options can be in any sections, not only .init/.fini. 2. -init-array/-fini-array options (I still not sure we need this functionality) affect .init_array/.fini_array and DT_INIT_ARRAY/DT_FINI_ARRAY tags. The order of these options define priority. The only problem is that we cannot setup priority of DT_INIT vs DT_INIT_ARRAY. -- Simon Atanasyan
Possibly Parallel Threads
- [LLVMdev] [lld] Handling multiple -init/-fini command line options
- [LLVMdev] [lld] Handling multiple -init/-fini command line options
- [LLVMdev] [lld] Handling multiple -init/-fini command line options
- [PATCH] com32: Include .init_array section in .ctors in linker script
- [PATCH 0/9] elflink fixes