Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka <jan.kiszka@siemens.com>]

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