This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support SHF_GNU_MBIND and PT_GNU_MBIND_XXX
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 <firstname.lastname@example.org> 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
> > __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.
> 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
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.
Australia Development Lab, IBM