This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support SHF_GNU_MBIND and PT_GNU_MBIND_XXX
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 17 Mar 2017 08:58:02 -0700
- Subject: Re: [PATCH] Support SHF_GNU_MBIND and PT_GNU_MBIND_XXX
- Authentication-results: sourceware.org; auth=none
- References: <20170315224617.GA23626@intel.com> <20170317033836.GQ4983@bubble.grove.modra.org>
On Thu, Mar 16, 2017 at 8:38 PM, Alan Modra <email@example.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
> __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;
How can linker arrange calling __gnu_mbind_setup in executable,
DSOs and dlopened DSOs before constructors are called?