All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2 LDFLAGS wrappers, posix only
Date: Thu, 12 Jan 2017 18:32:31 +0100	[thread overview]
Message-ID: <20170112183231.12bf8d56@md1em3qc> (raw)
In-Reply-To: <20170111154759.228693f3@md1em3qc>

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



  reply	other threads:[~2017-01-12 17:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 15:07 [Xenomai] xenomai 2 LDFLAGS wrappers, posix only Henning Schild
2017-01-11 11:03 ` Philippe Gerum
2017-01-11 14:47   ` Henning Schild
2017-01-12 17:32     ` Henning Schild [this message]
2017-01-12 17:54       ` Philippe Gerum
2017-01-12 18:33         ` Henning Schild
2017-01-12 20:27           ` Jan Kiszka
2017-01-17 10:25           ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170112183231.12bf8d56@md1em3qc \
    --to=henning.schild@siemens.com \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.