From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4926A240.6040709@domain.hid> Date: Fri, 21 Nov 2008 12:57:52 +0100 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Xenomai-core] Automatic shadowing in POSIX lib constructor List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai-core 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? Jan -- Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux