Re: RFC: ABI support for special memory area

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

On Thu, Mar 16, 2017 at 10:18 AM, Suprateeka R Hegde
<hegdesmailbox@gmail.com> wrote:
> On 16-Mar-2017 03:33 AM, H.J. Lu wrote:
>> Run-time support
>>
>> int __gnu_mbind_setup (unsigned int type, void *addr, size_t length);
>
> I still think the above interface is specific to MCDRAM proposal and is
> not generic enough for other special memory types. I would prefer it
> more in the form of something I showed.
>
> Or something even better than what I showed for the ABI support
> documentation and hence glibc implementation.
>
>>
>> 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.
>
> Let me rephrase what I want to know or what I am telling. Assume my
> interface of __gnu_mbind_setup is as follows:
>
> int __gnu_mbind_setup (unsigned int type, __nvm_kmem_t *nvm_kmem_obj,
>                                                         size_t length);
>
> Then, What is the expected way to add the default implementation for
> this vendor specific interface in glibc? Because this differs from the
> interface seen in glibc (from your patch).
>
> Are you saying we should use #ifdef for default implementation of every
> vendor? And hence a vendor specific ld.so? I dont think this is what you
> meant as this has lot of obvious problems.
>
> Or are you saying that we do not add vendor specific default
> implementations at all in glibc and just keep one interface and one
> default implementation that you have mentioned? And then the real
> implementation (with a different interface) would override glibc one
> (with the interface you have defined)?

Yes, that is what I proposed.

> If that is what you are designing, it looks like the overriding is
> purely based on the symbol name and not the the full interface of the
> function. Personally I feel this is a overriding hack based on
> linker/loader symbol resolution magic.

The goal is to link in special memory run-time only when special memory
is used. Otherwise, every executable will be linked with libmbind.

> 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.  The question is what the possible info needed
for all memory types 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.

> Assuming I am not missing anything above, if you still want to keep the
> interface as defined by you currently, I am OK with that. But we should
> at least add a couple of lines in addition, something like:
>
> "...which can be overridden by a different implementation at link-time.
> Such an implementation is required to provide a C style (unmangled)
> __gnu_mbind_setup function. However, the arguments and return type of
> the function need not match the one defined here"

What do you have in mind?  You can't change return type in real
__gnu_mbind_setup.  Otherwise, ld.so won't work correctly.

> BTW, what if the real implementation library also includes stddef.h?
> Wont there be prototype difference if the vendor
> implementation/interface is different?
>

The only type used is size_t.  It should be the same for everyone on
a given platform.

-- 
H.J.