Re: RFC: ABI support for special memory area

["H.J. Lu" <hjl.tools@gmail.com>]

On Fri, Mar 17, 2017 at 11:12 AM, Suprateeka R Hegde
<hegdesmailbox@gmail.com> wrote:
> On Friday 17 March 2017 02:55 AM, H.J. Lu wrote:
>>> Since ld.so is not meant only for programs with C style linkage, what if
>>> the real implementation library is written in C++ and wants to export
>>> only mangled names (interfaces) without any "extern C" kludge? Or is
>>> this considered to be a standard C library call just like mmap etc.?
>>
>> Only the __gnu_mbind_setup symbol is used.  We can change the
>> second argument to "void *data" and make it dependent on memory
>> type.  But to support a new memory type, we have to update ld.so.  I'd
>> like to use the same ld.so binary to support any memory types even if
>> it means that we need to pass info to __gnu_mbind_setup which isn't
>> used by all memory types.
>
> Ah! Now I understand the design completely (I think). Looks like Carlos
> understood this quite earlier in the discussion.
>
> You are saying that the interface -
>
> int __gnu_mbind_setup (unsigned int type, void *addr, size_t length);
>
> - is fixed in ld.so and also in the real implementation library. And,
> the real implementation in turn calls the actual-real-implementation, as
> shown in your libmbind code:
>
> int
> __gnu_mbind_setup (unsigned int type, void *addr, size_t length)
> {
>   // in turn calls actual implementation
>   return vendor_specific_mbind_setup (vendor specific types);
> }
>
>
> All these while, based on the current description, I was of the
> impression that your design allows __gnu_mbind_setup interface itself to
> be overridden in the real implementation, something like:
>
> int
> __gnu_mbind_setup (__nvm_kmem_t *nvm_obj, void *nvm_handle)
> {
>   // actual implementation directly here in the body
> }
>
> So I was wondering how and hence most of my points were out-of-phase.
>
>>  The question is what the possible info needed
>> for all memory types is.
>
> Thats too much to predict right now. And the current interface you
> defined also does not seem to be generic. For instance, my NVM
> implementation, though not complete, needs a totally different set of
> arguments. So going by the current design, I will have to use
> __gnu_mbind_setup (unsigned int type, void *addr, size_t length) just to
> call my real setup, without using any of the arguments passed by ld.so.
>
> Assuming I am in sync with you now, I would say that the pseudo code I
> showed earlier works for you as well as for me as well as for anybody
> else. In other words it is more generic.
>
> With that approach, there is
>
> 1. No need to update ld.so every time for every new mem type
> 2. No need to know all possible info needed for all mem types
> 3. No need to encode all types in the API (as Carlos said)
>
> We just use pointer to implementation interface - struct
> __gnu_mbind_context that I showed. And we can have a default struct
> instantiated in ld.so and a global pointer pointing to that. And later
> the global pointer can be made to point to the vendor specific struct,
> before ld.so actually calls __gnu_mbind_setup, thereby completing a
> successful override (if necessary, that is when special memory types are
> in use).
>
> Or similar mechanisms to override default struct instantiated in ld.so.
> There are many well known ways to override the default struct as we all
> know.
>
> Personally I think this would be a better way to provide the ABI support
> in a generic way.

ld.so needs to call the real __gnu_mbind_setup implementation
with the correct argument.   We can keep it ASIS and add a new
new one, __gnu_mbind_setup_v2, if needed.

> That said, I am OK to live with minor kludges and we can keep the design
> as is.
>
>>
>>> And you may also want to define the flow for fully archive bound static
>>> binaries.
>>
>> For static executable, __gnu_mbind_setup will be called on all MBIND
>> segments before constructors are called.  __gnu_mbind_setup in libc.a
>> is weak and will be overridden by the real one in libmbind.a.
>
> Lets add this also in the ABI support document.
>

How about this:

Run-time support

int __gnu_mbind_setup_v1 (unsigned int type, void *addr, size_t length);

It sets up special memory area of 'type' and 'length' at 'addr' where
'addr' is a multiple of page size.  It returns zero for success, positive
value of ERRNO for non-fatal error and negative value of ERRNO for fatal
error.

After all shared objects and the executable file are loaded, relocations
are processed, for each GNU_MBIND segment in a shared object or the
executable file, run-time loader calls __gnu_mbind_setup_v1 with type,
address and length.  If __gnu_mbind_setup_v1 must be defined in run-time
loader, it should be implemented as a weak function:

int
__gnu_mbind_setup_v1 (unsigned int type, void *addr, size_t length)
{
  return 0;
}

in run-time loader so that the GNU_MBIND run-time library isn't required
for normal executable nor shared object.  The real implementation of
__gnu_mbind_setup_v1 should be in the GNU_MBIND run-time library and
overridde the weak one in run-time loader.



-- 
H.J.