Re: [PATCH] Support SHF_GNU_MBIND and PT_GNU_MBIND_XXX

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Mar 19, 2017 at 4:38 AM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Mar 17, 2017 at 08:58:02AM -0700, H.J. Lu wrote:
>> On Thu, Mar 16, 2017 at 8:38 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Wed, Mar 15, 2017 at 03:46:17PM -0700, H.J. Lu wrote:
>> >> Any comments?
>> >
>> > Doesn't pass my sniff test.
>> >
>> > You say that management of special memory regions doesn't belong in
>> > the kernel or glibc, but will be handled by a vendor supplied
>> > library.  In that case, why must ld.so run your magic
>> > __gnu_mbind_setup function?  If ld.so doesn't need to run
>>
>>  __gnu_mbind_setup needs to called with memory type, address and
>> length in executable, DSOs and dlopened DSOs before constructors
>> are called.
>
> I presume if it is supposed to work with dlopen then you're saying
> __gnu_mbind_setup will be called for the executable and each DSO.
> ie. We're not talking about a case where __gnu_mbind_setup is called
> once after the executable and all DSOs have been loaded.  If that is
> the case, then yes, it is probably most convenient to have ld.so
> involved.

__gnu_mbind_setup is called once on each MBIND segment after
the executable and all DSOs have been loaded and relocated.

>> > __gnu_mbind_setup then there's no need to pass information to ld.so
>> > via special segment types and flags.
>> >
>> > Just have the application call __gnu_mbind_setup.  The function
>> > can take the address range(s) requested as a parameter rather than
>> > putting them into the executable headers.  It shouldn't be difficult
>> > for the linker to arrange such a call on application startup.
>> >
>>
>> The goal is to place data in special memory sections via attribute.
>> To place an uninitialized variable, foo, in a mbind bss section with
>> memory type 1:
>>
>> int foo __attribute__ ((mbind(0x1)));
>>
>> To place a variable, foo, in a mbind data section with memory type 2:
>>
>> int foo __attribute__ ((mbind(0x2))) = 1;
>>
>> To place a read-only variable, foo, in a mbind rodata section with
>> memory type 3:
>>
>> const int foo __attribute__ ((mbind(0x3))) = 1;
>
> I think the relocatable object support is fine.  It's just the new
> program header I'm questioning, and only because it seemed to me that
> ld.so didn't need to be involved.  If ld.so isn't involved then you
> can support the feature on older glibc.

ld.so is used to iterate all MBIND regions to call __gnu_mbind_setup
with their addresses and sizes.  Ii is hard to do without ld.so.

>> How can linker arrange calling __gnu_mbind_setup in executable,
>> DSOs and dlopened DSOs before constructors are called?
>
> By making that call the very first constructor.  I'm not sure whether
> you want to run before DT_PREINIT_ARRAY constructors (or should!).  It

A sperare MBIND initialization function needs to be called to initalize
data which is needed by __gnu_mbind_setup.  I am planning to
place it at the beginning of .preinit_array section.

> would be easier if not, because then you'd be able to hook into crti.o
> _init and pass parameters more easily, either using the same trick of
> a weak __gnu_mbind_setup call or have ld edit the _init code.
>


-- 
H.J.