[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: ABI support for special memory area
On 03/27/17 21:45, H.J. Lu wrote:
>
> There is a way to support GNU_MBIND segments without the glibc changes.
> Instead, dl_iterate_phdr
>
> int dl_iterate_phdr (int (*callback) (struct dl_phdr_info *info,
> size_t size, void *data),
> void *data);
>
> is called via the .init_array section to process GNU_MBIND segments in
> executable and shared objects:
>
> static int
> callback (struct dl_phdr_info *info, size_t size, void *data)
> {
> Compute the load address of the current module.
> if info->dlpi_addr == the load address of the current module
> {
> check ELF program headers and process GNU_MBIND segments
> return 1;
> }
>
> return 0;
> }
>
> static void
> call_gnu_mbind_setup (void)
> {
> dl_iterate_phdr (callback, NULL);
> }
>
> static void (*init_array) (void)
> __attribute__ ((section (".init_array"), used))
> = &call_gnu_mbind_setup;
This looks very ideal and perfect and matches my requirement too. Are
you suggesting this dl_iterate_phdr(3) as the way in your proposal
instead of the __gnu_mbind_setup?
Or are you suggesting that for all the implementations that need
different arguments (like that of my NVM) compared to
__gnu_mbind_setup_v1, we go with this dl_iterate_phdr(3) way?
I am OK either way.
However, I am just thinking that your earlier approach --
__gnu_mbind_setup -- is better when shared libraries with GNU_MBIND
segments are dlopen'ed. They dont have to iterate all over again to
reach their PHDR. Or what is the recommendation for such dlopen'ed
libraries?
And this dl_iterate_phdr(3) not being part of any standards, may change
in a totally incompatible way in the future.
--
Supra