From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <519225B0.6080009@siemens.com> Date: Tue, 14 May 2013 13:53:20 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <516BA4E9.3070201@xenomai.org> <5182B1B5.1000107@xenomai.org> <12E434B4-4F26-44AC-8D50-2CF70B5089E1@kabelmail.de> <5183FFB3.1000006@xenomai.org> <8D9AB79C-4A66-4511-B08B-ACF825FED1BF@kabelmail.de> <518A98F5.30000@xenomai.org> <0ECFC8C0-CF1D-4D65-9724-B0A1A91887DC@kabelmail.de> <518CF43E.3080601@xenomai.org> <5F179C54-A023-4C27-9082-13195B16B9BB@kabelmail.de> <518D07BB.1060900@xenomai.org> <518D24E8.6070305@xenomai.org> <518D2815.7000602@xenomai.org> <19C79116-400B-4A5C-BFDA-87EEF8799554@kabelmail.de> <41BEC449-99F8-4C31-AA75-B98690DB3F23@kabelmail.de> <5191DC82.6090509@xenomai.org> <5191ED8D.90105@xenomai.org> <42470BFE-71B5-41BD-9A90-EA3ACF1D1C1C@kabelmail.de> <519201D7.6050800@siemens.com> <51921369.4000703@siemens.com> <519219C0.9000209@xenomai.org> <51921BFC.9020404@siemens.com> <51921F78.60504@xenomai.org> In-Reply-To: <51921F78.60504@xenomai.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Raspberry and Beaglebone patches List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Stephan Kappertz , Xenomai On 2013-05-14 13:26, Gilles Chanteperdrix wrote: > On 05/14/2013 01:11 PM, Jan Kiszka wrote: > >> On 2013-05-14 13:02, Gilles Chanteperdrix wrote: >>>> OK, I pushed the patch for upstream merge. It's probably better to carry >>>> the workaround than letting users find out the reason the hard way. >>>> Gilles, please consider it for 2.6.3. >>> >>> >>> Ok, but does not the workaround of un-inlining xeno_bind_skin make more >>> sense? >> >> The issue is not with xeno_bind_skin and its inlining but with patterns like >> >> my_function() >> { >> if (condition) >> return; >> do_other_stuff(); >> } >> >> gcc tends to push do_other_stuff into a sub-function called >> my_function.part.0, and that part is then incorrectly registered as >> constructor function as well. > > > I understood that, but in the case of the native skin, the only such > branch is created by the fact that xeno_bind_skin is inlined (and it is > the other way around, it is the if branch that goes in a helper > function, the unlikely branch in fact). One of the first things I tried was commenting out xeno_bind_skin, and the problem unfortunately remained. There are two more spots in __init_xeno_interface: around fork_handler_registered and error handling of pthread_atfork. In fact, the latter code is what is factored out into a separate function here. > So, if the native skin > initialization is the only one to be problematic, then it fixes the > issue. If the native skin initialization is not the only one to be > problematic, then your patch is unsufficient. It is also unsufficient > because it does not guarantee that the compiler will not inline > __init_xeno_interface in __init_wrapper when we use other more > aggressive compilation options, at minimum __attribute__((noinline)) > would be needed, and not only for the native skin. So, I nack this patch. > > So, since we know that this is a broken compiler and that there are > other versions that work, I propose to detect it in the configure script > and abort compilation when we find this compiler. > > Yet another solution would be to suppress the automatic binding with > __attribute__((constructor)) and bind the skin on first use of the > "muxid", with a static inline function using a static pthread_once_t. I would prefer limiting the workaround to init code, leaving runtime paths alone. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux