Hi Gilles,

as indicated in an earlier post, my customer managed to reveal some
issues around dlopen'ing Xenomai libs, more precisely libs that were
linked against libpthread_rt. The constructor of the POSIX lib has
several problems here, and I think some are not fixable:

 o it auto-maps the constructor's caller even if it is not the main
   thread, and before main() was called

 o it ignores the caller's priority and sched policy, overwriting it

 o it removes mlockall from the process even if it was locked on entry

At least the last thing seems to be very hard to fix, but also for the
first item (testing if we are executed on application startup or later)
I see no solution right now.

So I propose to control automatic mapping as follows:
 - rebrand --without-__thread as --enable-dlopen, keeping it off by
 - continue to check for platform support of initial-exec TLS, only
   use it when available *and* --enable-dlopen is not selected
 - don't perform auto-mapping in __init_posix_interface if
   --enable-dlopen is selected

This is build around the assumption that the user intentionally sets
--enable-dlopen because (s)he actually wants to use Xenomai libs like
that. And in that case (s)he is also expected to has a custom approach
which threads are shadowed (and with which priority) and which maybe not.

Comments? Better suggestions?


Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to