Re: RFC: ABI support for special memory area

[Suprateeka R Hegde <hegdesmailbox@gmail.com>]

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