[Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Henning Schild]

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?

Henning

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Henning Schild]

Am Wed, 11 Jan 2017 12:03:23 +0100
schrieb Philippe Gerum <rpm@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.

The three __cxa_guard wrappers would also be of the "insert assertion"
type and should therefore go into all skins.

Henning

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Henning Schild]

Am Wed, 11 Jan 2017 15:47:59 +0100
schrieb Henning Schild <henning.schild@siemens.com>:

> Am Wed, 11 Jan 2017 12:03:23 +0100
> schrieb Philippe Gerum <rpm@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.
> 
> 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 am working on patches to extract the assert_nrt wrappers out of
posix.wrappers and put them into common.wrappers. The last patch of the
series would add the stdc++ guys to the common wrappers.

The file posix.wrappers is mentioned in configure.in and
skins/posix/Makefile.(in|am). And a new file will probably have to go
there as well. So this seemingly little change might produce a rather
big changeset including autotool changes.

Maybe i should start with the xenomai3 version of it to have a better
basis for a discussion?

Henning

> Henning

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Philippe Gerum]

On 01/12/2017 06:32 PM, Henning Schild wrote:
> Am Wed, 11 Jan 2017 15:47:59 +0100
> schrieb Henning Schild <henning.schild@siemens.com>:
> 
>> Am Wed, 11 Jan 2017 12:03:23 +0100
>> schrieb Philippe Gerum <rpm@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?

>>
>> 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?

> 
> I am working on patches to extract the assert_nrt wrappers out of
> posix.wrappers and put them into common.wrappers. The last patch of the
> series would add the stdc++ guys to the common wrappers.
> 
> The file posix.wrappers is mentioned in configure.in and
> skins/posix/Makefile.(in|am). And a new file will probably have to go
> there as well. So this seemingly little change might produce a rather
> big changeset including autotool changes.
> 
> Maybe i should start with the xenomai3 version of it to have a better
> basis for a discussion?
> 

2.6 maintenance is definitely closed upstream, so I would base the
discussion on v3 exclusively.

-- 
Philippe.

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Henning Schild]

Am Thu, 12 Jan 2017 18:54:56 +0100
schrieb Philippe Gerum <rpm@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@siemens.com>:
> >   
> >> Am Wed, 11 Jan 2017 12:03:23 +0100
> >> schrieb Philippe Gerum <rpm@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 guess another option could be to wrap them only when xeno-config is
told to produce c++ ldflags. The downside of that would be that people
would likely have to change the way they call xeno-config in
their makefiles.

> > 
> > I am working on patches to extract the assert_nrt wrappers out of
> > posix.wrappers and put them into common.wrappers. The last patch of
> > the series would add the stdc++ guys to the common wrappers.
> > 
> > The file posix.wrappers is mentioned in configure.in and
> > skins/posix/Makefile.(in|am). And a new file will probably have to
> > go there as well. So this seemingly little change might produce a
> > rather big changeset including autotool changes.
> > 
> > Maybe i should start with the xenomai3 version of it to have a
> > better basis for a discussion?
> >   
> 
> 2.6 maintenance is definitely closed upstream, so I would base the
> discussion on v3 exclusively.

I will have to write patches for both versions anyways, actually
primarily v2. Consequently both patchqs will be published here and
hopefully merged upstream. But the technical discussion is the same for
both versions, so i will start with v3.

Henning

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Jan Kiszka]

On 2017-01-12 19:33, Henning Schild wrote:
> Am Thu, 12 Jan 2017 18:54:56 +0100
> schrieb Philippe Gerum <rpm@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@siemens.com>:
>>>   
>>>> Am Wed, 11 Jan 2017 12:03:23 +0100
>>>> schrieb Philippe Gerum <rpm@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.
> 

>From the original commit message of my patch back then (I do not find
this in git, though, but it's in xenomai-core archives):

"Provide assert_nrt helper that checks if the caller is either not a
shadow thread or is currently running in relaxed mode. If not, SIG_XCPU
is raised.

This service is then used to provide wrappers for glibc functions that
are not realtime-safe but do not always trigger a syscall. Such
functions may therefore be used by RT threads in primary mode for quite
a while without being detected via some Xenomai mode switch. Moreover,
some functions that go through the vsyscall page even to raise an
ordinary syscall may not allow proper stack backtraces, making it harder
to find their callers.

So far we provide wrappers (for use with the --wrap linker switch) for
malloc/free, gettimeofday and clock_gettime. Adding more (if there
are/will be more) is trivial."

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only

[Philippe Gerum]

On 01/12/2017 07:33 PM, Henning Schild wrote:
> Am Thu, 12 Jan 2017 18:54:56 +0100
> schrieb Philippe Gerum <rpm@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@siemens.com>:
>>>   
>>>> Am Wed, 11 Jan 2017 12:03:23 +0100
>>>> schrieb Philippe Gerum <rpm@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.

-- 
Philippe.