llvm dev - Dec 2014 - [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

There is also an additional issue that needs to be handled,

The linker decides to convert .ctors/.dtors section to .init/.fini too 
in some circumstances.

There is also a case where we need to supported for static linking as well.

I looked into this a bit and there is a bug which illustrates 
ctors/dtors and init_array/fini_array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

Shankar Easwaran

On 12/8/2014 2:26 PM, Simon Atanasyan wrote:
> 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.
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Tue, Dec 9, 2014 at 12:06 AM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> There is also an additional issue that needs to be handled,
>
> The linker decides to convert .ctors/.dtors section to .init/.fini too in
> some circumstances.
>
> There is also a case where we need to supported for static linking as well.
>
> I looked into this a bit and there is a bug which illustrates ctors/dtors
> and init_array/fini_array
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
I'm sorry, but I do not see how -init/-fini command line option
handling relates to this bug. Now the -init/-fini might cause creation
of .init_array/.fini_array sections. But in GNU linker AFAIK these
options affects DT_INIT/DT_FINI tags only.

-- 
Simon Atanasyan

On Mon, Dec 08, 2014 at 03:06:39PM -0600, Shankar Easwaran
wrote:
> The linker decides to convert .ctors/.dtors section to .init/.fini
> too in some circumstances.
A platform either uses .init/.fini sections or .init_array/.fini_array.
.ctors/.dtors is converted to whichever is used. It is unrelated to
handling of DT_INIT/DT_FINI.

Joerg