H

[H.J. Lu]

On Mon, Mar 20, 2017 at 9:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>

Here is the updated proposal which works with existing glibc:

https://sourceware.org/ml/gnu-gabi/2017-q1/msg00032.html

I am enclosing the updated patch.


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-ELF-SHF_GNU_MBIND-and-PT_GNU_MBIND_XXX.patch
Type: text/x-patch
Size: 44963 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170403/6f2c356a/attachment.bin>