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

[Henning Schild <henning.schild@siemens.com>]

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