Re: [Xenomai-core] Automatic shadowing in POSIX lib constructor

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> 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
>    with SCHED_OTHER
> 
>  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
>    default
>  - 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?

The libtpthread_rt constructor is clearly written for the most common
case. I agree with your idea. Nevertheless, I think that when we detect
the failing case (I do not know yet how), we should issue a clear
message directing the use to the --enable-dlopen option.

-- 
                                                 Gilles.