[Xenomai] xenomai 2 LDFLAGS wrappers, posix only

Philippe Gerum rpm at xenomai.org
Tue Jan 17 11:25:55 CET 2017

On 01/12/2017 07:33 PM, Henning Schild wrote:
> Am Thu, 12 Jan 2017 18:54:56 +0100
> schrieb Philippe Gerum <rpm at xenomai.org>:
>> On 01/12/2017 06:32 PM, Henning Schild wrote:
>>> Am Wed, 11 Jan 2017 15:47:59 +0100
>>> schrieb Henning Schild <henning.schild at siemens.com>:
>>>> Am Wed, 11 Jan 2017 12:03:23 +0100
>>>> schrieb Philippe Gerum <rpm at xenomai.org>:
>>>>> On 01/10/2017 04:07 PM, Henning Schild wrote:    
>>>>>> Hi,
>>>>>> i am about to include three more wrappers into xenomai2 to
>>>>>> assert_nrt, later i plan to create a xenomai3 patch as well. The
>>>>>> functions to wrap are __cxa_guard_(acquire|release|abort). They
>>>>>> contain mutexes protecting the initialization state of static
>>>>>> objects in c++ code, often found when people implement the
>>>>>> singleton pattern.
>>>>>> I have got the wrapping code but found that xeno-config will
>>>>>> create the wrapping LDFLAGS only for the posix skin. Is that
>>>>>> intentional or an inconsistency?
>>>>>> Even the wrappers in the "common" skin get applied for posix
>>>>>> only.
>>>>>> I tried calling malloc/free in a "--skin=native" example and did
>>>>>> not get the SIGXCPU.
>>>>>> Now i am guessing that the way wrappers are applied in xenomai2
>>>>>> is somehow inconsistent. Is that something that should be fixed
>>>>>> by having common and per skin wrappers, or would it be ok to
>>>>>> simply always append the posix LDFLAGS as well?      
>>>>> --posix is supposed to be passed only when a wrapping is expected.
>>>>> Omitting it allows to build apps over non-POSIX Xenomai APIs,
>>>>> while assuming that any POSIX call also present in the code can
>>>>> only be obtained from the glibc.    
>>>> Ok i see. Just adding the --posix all the time would change the
>>>> implementation of all the pthread_* stuff where the developer might
>>>> just want to use non-rt pthreads.
>>>> There seem to be two classes of wrappers. Those that just
>>>> assert_nrt() and do not change the implementation of the function
>>>> to be called. And the other class actually replaces the original
>>>> implementation.
>>>> The ones that just insert the assert_nrt() are relevant for all
>>>> skins and should be applied there, while at the moment they are
>>>> only used for posix/rtdm.
>>>> For xenomai3 that is malloc and free
>>>> (./lib/cobalt/assert_context.c), for xenomai2 it is those two plus
>>>> gettimeofday (src/skins/common/assert_context.c). These should be
>>>> wrapped in any skin, not just posix.  
>> Is this requirement to wrap gettimeofday() on v2 a LART for preventing
>> deadlocks with the read_seqcount construct in kernel space?
> I do not know why it is in there.
>>>> The three __cxa_guard wrappers would also be of the "insert
>>>> assertion" type and should therefore go into all skins.  
>>> Do you agree with the observation? Should the assert_nrt guys be
>>> applied on all skins? Should we add the stdc++ __cxa_guard
>>> functions as such wrappers?  
>> I agree on the purpose, but __cxa_guard may depend on the C++ ABI. How
>> are you going to deal with this?
> My current patch provides weak dummy-versions of them. That way you can
> still link even when not using c++. 

I was referring to architecture-specific signatures of those guard ops.
For instance, in its CPPABI supplement (ABI rev 2.10 from Nov '15), ARM
mentions a variation from the generic CPPABI for __cxa_guard_acquire and
_release regarding their int32 argument, instead of int64.

So that would mean that we'd need architecture-specific wrappers, those
could not be generic ones. I did not check further, just raising the point.


More information about the Xenomai mailing list