On Wed, 12 Nov 2014, Ilya Enkovich wrote:

> MPX runtime needs to be linked with programs using MPX because it 
> initializes hardware.  Without it all MPX instructions are just NOPs.  
> Thus it's not an extra functionality, but is for basic MPX 
> functionality.

So what if you just have the constructor that initializes the hardware - 
could everything else (handling environment variables, printing more 
detailed diagnostics, etc.) be separate?  How much is basic MPX 
functionality, how much is extra?  Basic functionality should arguably be 
like libgcc in namespace terms (so not calling any libc functions outside 
of ISO C90 namespace, using reserved-namespace versions such as __write 
instead if necessary and if such versions are available); extra 
functionality need not be so restricted.

> I also fixed other issues you mentioned in your previous comments.  
> Below is a new version.  Does it look better?

I don't see anything obvious to do symbol versioning.

If this isn't providing interfaces for the user program or 
compiler-generated code to call, then the symbol versioning could hide all 
symbols (so there are no exported symbols at all and the library operates 
purely through its initialization constructor).  Or build with 
-fvisibility=hidden to hide the symbols that way.  Either way, the dynamic 
symbol table of the shared library would end up with just undefined 
symbols, nothing exported by the library.

The issue with signal handlers calling inappropriate functions still 
applies - you're calling vfprintf from a signal handler.  Using 
pthread_mutex_lock around it doesn't help at all; vfprintf can call 
malloc, and the signal may have interrupted malloc, for example.  You 
really can't use stdio at all inside signal handlers - if you want to do 
I/O in them, you have to use write ().  (There's an argument that dprintf 
or an snprintf/write combination ought to be AS-safe, but currently they 
aren't; see <https://sourceware.org/bugzilla/show_bug.cgi?id=16060>; 
snprintf is probably safe than dprintf in practice.)

I mentioned the question of static writable variables.  If those variables 
are only ever modified at startup, before any threads have been created, 
could you add comments to that effect (and otherwise ensure comments on 
the variables explain how you ensure they are accessed in a thread-safe 
way)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to