[PATCH, MPX runtime 1/2] Integrate MPX runtime library

[Ilya Enkovich]

2014-11-13 2:03 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> On Thu, 13 Nov 2014, Ilya Enkovich wrote:
>
>> It's hard to decide which of runtime functionality should be
>> considered as basic and how it should be used.  We may say that the
>> only basic thing is hardware enabling which is enable_mpx and stop
>> here.  But then you get minimal but quite useless library.  Yes, it
>> can enable MPX and thus make bounds violation to interrupt a program.
>> But users cannot enable/disable MPX dinamycally then.  Also they
>> cannot configure it.  Thus either control via environmental variables
>> appears in this core library or we transform initialization function
>> from constructor to interface function and use it from another
>> extended MPX library which support environment variables, logging etc.
>> But the core library will only be used by this extended MPX library
>> and nothing else. So why not to leave it as a single library as it is?
>
> You can leave it as a single library - it's just that imposes libgcc-like
> constraints on what the library does and how it does things, so as to be
> usable for arbitrary programs built with MPX (e.g. using
> reserved-namespace names such as __write when available - direct syscalls
> may also be a possibility in some cases).

I really don't want to make it libgcc-like and complicate its further
development.  What is the reason for that?  Is it because library is
linked by -mmpx?  Can it be avoided if library is linked only at
'-fcheck-pointer-bounds -mmpx' combination?  If single -mmpx is used
then compiler actually doesn't generate any MPX instructions and user
doesn't even have builtins to do that.  The only option for user to
generate mpx instructions without pointer bounds checker is to write
inline assembler.  In this case he should be prepared enough to enable
MPX in his assembler :) Alternatively enable_mpx function may be put
into i386 intrin headers and used manually in programs by including
immintrin.h.  Does it sound like a viable option?

Thanks,
Ilya

>
> --
> Joseph S. Myers
> joseph@codesourcery.com