Re: RFC: ABI support for special memory area

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

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)?

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.

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.?

And you may also want to define the flow for fully archive bound static
binaries.

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"

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

--
Supra