[Xenomai] Porting a library to Xenomai

[Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

Hi,

I'm working to make a library to work with Xenomai. It's a library that has a 
thread and open a socket to communicate with an external device via network.

I have read the guide "Porting a Linux application to Xenomai dual kernel [1]" 
but still I have some doubts in some details. So, here my topics without any 
importance order:

- What is the recommended way to obtain the link, flags, etc information to 
build an application that use Xenomai? xeno-config, pkg-config, some build 
macros to find the information, ... 

- I would like to have a code that could be used with an Standard POSIX or a 
Xenomai. I thought that protecting my code with some #ifdef __XENO__ I could 
choose which part is specific to Xenomai and which no. However, I'm a bit 
confused, because then, I don't understand what is the utility of the wrap 
script. Please, could you elaborate a bit more this part, especially focused 
in an application the could use an standard network interface or rtnet 
version.

- In the document, there's a section about the mlockall option. So, may I 
understand that from xenomai <= 2.6.3 it's not needed that I call the mlockall 
function?

Best regards,

Leopold
----
[1] https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/
[2] http://letsmakerobots.com/node/28812#comment-86166
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151211/90b8a76b/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Fri, Dec 11, 2015 at 01:44:01PM +0100, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> I'm working to make a library to work with Xenomai. It's a library that has a 
> thread and open a socket to communicate with an external device via network.
> 
> I have read the guide "Porting a Linux application to Xenomai dual kernel [1]" 
> but still I have some doubts in some details. So, here my topics without any 
> importance order:
> 
> - What is the recommended way to obtain the link, flags, etc information to 
> build an application that use Xenomai? xeno-config, pkg-config, some build 
> macros to find the information, ... 

Quoting the document you say you have read:
"Compilation flags

To ease that task, the xeno-config script, installed when compiling
Xenomai user-space support, is able to give you these flags. (...) 
Beware: this way of obtaining the compilation flags is recommended,
if for anything because it will make using a different release of
Xenomai easier: the flags may change between two different releases." 

> 
> - I would like to have a code that could be used with an Standard POSIX or a 
> Xenomai. I thought that protecting my code with some #ifdef __XENO__ I could 
> choose which part is specific to Xenomai and which no. However, I'm a bit 
> confused, because then, I don't understand what is the utility of the wrap 
> script. Please, could you elaborate a bit more this part, especially focused 
> in an application the could use an standard network interface or rtnet 
> version.

Quoting the documentation again: "Use of Linux original services

It may happen that you would like to use Linux services instead of
Xenomai POSIX skin overloaded services. In this case, the –wrap
mechanism described in section Under the hood: the –wrap flag.
offers a solution: prefix the name of the service you would like to
use with the __real_ prefix, such as, for instance
__real_pthread_create.

If you do that, and would still want to be able to compile your
application without Xenomai (it may be a good idea, as it allows,
for instance, to run your application with valgrind, which you can
not do with an application compiled for Xenomai), Xenomai
compilation flags define a preprocessor macro (__XENO__) which
allows you to know whether or not you are compiling the application
for Xenomai. You can use it for instance in the following way:

 /* Open a plain Linux UDP socket. */
 #ifndef __XENO__
       fd = socket(PF_INET, SOCK_DGRAM, 0);
 #else /* __XENO__ */
       fd = __real_socket(PF_INET, SOCK_DGRAM, 0);
 #endif /* __XENO__ */
"

> 
> - In the document, there's a section about the mlockall option. So, may I 
> understand that from xenomai <= 2.6.3 it's not needed that I call the mlockall 
> function?

Quoting the documentation again: "
Starting with version 2.6.3, as part of their initialization,
Xenomai libraries systematically call mlockall to commit and lock
the whole application memory.
(...)
Before version 2.6.3

Xenomai POSIX library only invoked mlockall if the
–enable-posix-auto-mlockall option was passed to the configure
script when compiling Xenomai user-space support. So, applications
which did not want to depend on this configuration had to call
mlockall by themselves, before using any Xenomai service, by using: 

 mlockall(MCL_CURRENT | MCL_FUTURE);"


-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

El Divendres, 11 de desembre de 2015, a les 14:20:12, Gilles Chanteperdrix va 
escriure:
> On Fri, Dec 11, 2015 at 01:44:01PM +0100, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > I'm working to make a library to work with Xenomai. It's a library that
> > has a thread and open a socket to communicate with an external device via
> > network.
> > 
> > I have read the guide "Porting a Linux application to Xenomai dual kernel
> > [1]" but still I have some doubts in some details. So, here my topics
> > without any importance order:
> > 
> > - What is the recommended way to obtain the link, flags, etc information
> > to
> > build an application that use Xenomai? xeno-config, pkg-config, some build
> > macros to find the information, ...
> 
> Quoting the document you say you have read:

:-)

> "Compilation flags
> 
> To ease that task, the xeno-config script, installed when compiling
> Xenomai user-space support, is able to give you these flags. (...)
> Beware: this way of obtaining the compilation flags is recommended,
> if for anything because it will make using a different release of
> Xenomai easier: the flags may change between two different releases."

ok, but this solution implies that xeno-config must be available. In any case 
as CMake user, following your indications the Macros should use xeno-config. 
For what I have seen in the net, not all the people use that.

> > - I would like to have a code that could be used with an Standard POSIX or
> > a Xenomai. I thought that protecting my code with some #ifdef __XENO__ I
> > could choose which part is specific to Xenomai and which no. However, I'm
> > a bit confused, because then, I don't understand what is the utility of
> > the wrap script. Please, could you elaborate a bit more this part,
> > especially focused in an application the could use an standard network
> > interface or rtnet version.
> 
> Quoting the documentation again: "Use of Linux original services
> 

[....]


No Gilles, that's the point that I don't understand. Maybe it could be a 
language problem. 

Are you saying that, for instance using a rtnet driver, it's the same to NOT 
use the wrap script and use this:

 /* Open a plain Linux UDP socket. */
 #ifndef __XENO__
       fd = socket(PF_INET, SOCK_DGRAM, 0);
 #else /* __XENO__ */
       fd = rt_dev_socket(PF_INET, SOCK_DGRAM, 0);
 #endif /* __XENO__ */

Or, 

 #ifndef __XENO__
       printf("Stopping the robot.\n");
 #else /* __XENO__ */
       rt_printf("Stopping the robot.\n");
 #endif /* __XENO__ */


And which are the implications of the use of the wrap script? Could I avoid 
the use of the script protecting the wrapped functions with __XENO__ and it's 
the same?

> 
> > - In the document, there's a section about the mlockall option. So, may I
> > understand that from xenomai <= 2.6.3 it's not needed that I call the
> > mlockall function?
> 
> Quoting the documentation again: "
> Starting with version 2.6.3, as part of their initialization,
> Xenomai libraries systematically call mlockall to commit and lock
> the whole application memory.

Ok, so why it's use it in your example:

http://www.xenomai.org/documentation/xenomai-2.6/html/api/trivial-periodic_8c-example.html

May I understand that that line is not needed?

Thanks,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151211/e165c3df/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Fri, Dec 11, 2015 at 03:03:55PM +0100, Leopold Palomo-Avellaneda wrote:
> El Divendres, 11 de desembre de 2015, a les 14:20:12, Gilles Chanteperdrix va 
> escriure:
> > On Fri, Dec 11, 2015 at 01:44:01PM +0100, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > I'm working to make a library to work with Xenomai. It's a library that
> > > has a thread and open a socket to communicate with an external device via
> > > network.
> > > 
> > > I have read the guide "Porting a Linux application to Xenomai dual kernel
> > > [1]" but still I have some doubts in some details. So, here my topics
> > > without any importance order:
> > > 
> > > - What is the recommended way to obtain the link, flags, etc information
> > > to
> > > build an application that use Xenomai? xeno-config, pkg-config, some build
> > > macros to find the information, ...
> > 
> > Quoting the document you say you have read:
> 
> :-)
> 
> > "Compilation flags
> > 
> > To ease that task, the xeno-config script, installed when compiling
> > Xenomai user-space support, is able to give you these flags. (...)
> > Beware: this way of obtaining the compilation flags is recommended,
> > if for anything because it will make using a different release of
> > Xenomai easier: the flags may change between two different releases."
> 
> ok, but this solution implies that xeno-config must be available. In any case 
> as CMake user, following your indications the Macros should use xeno-config. 
> For what I have seen in the net, not all the people use that.

We can not force people to use the recommended solution. This is
implied in the word "recommended".

> 
> > > - I would like to have a code that could be used with an Standard POSIX or
> > > a Xenomai. I thought that protecting my code with some #ifdef __XENO__ I
> > > could choose which part is specific to Xenomai and which no. However, I'm
> > > a bit confused, because then, I don't understand what is the utility of
> > > the wrap script. Please, could you elaborate a bit more this part,
> > > especially focused in an application the could use an standard network
> > > interface or rtnet version.
> > 
> > Quoting the documentation again: "Use of Linux original services
> > 
> 
> [....]
> 
> 
> No Gilles, that's the point that I don't understand. Maybe it could be a 
> language problem. 

If you do not understand the text. Read the example.

> > 
> > > - In the document, there's a section about the mlockall option. So, may I
> > > understand that from xenomai <= 2.6.3 it's not needed that I call the
> > > mlockall function?
> > 
> > Quoting the documentation again: "
> > Starting with version 2.6.3, as part of their initialization,
> > Xenomai libraries systematically call mlockall to commit and lock
> > the whole application memory.
> 
> Ok, so why it's use it in your example:
> 
> http://www.xenomai.org/documentation/xenomai-2.6/html/api/trivial-periodic_8c-example.html
> 
> May I understand that that line is not needed?

It is not needed indeed.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

El Divendres, 11 de desembre de 2015, a les 15:09:27, Gilles Chanteperdrix va 
escriure:
[...]
> > 
> > No Gilles, that's the point that I don't understand. Maybe it could be a
> > language problem.
> 
> If you do not understand the text. Read the example.

what I'm worried about if theses wraps implies more things that are hidden. 
The example is clear. Maybe I'm imagine more things that really exists.

The most surprising thing to me is that using that wrap, with a few 
considerations a "normal" POSIX program that uses a socket and has a thread 
could be migrated to Xenoma RT easily, just defining some compiler/linker flags.

Thanks for all,

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151211/1f54dfbe/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Fri, Dec 11, 2015 at 04:33:58PM +0100, Leopold Palomo-Avellaneda wrote:
> El Divendres, 11 de desembre de 2015, a les 15:09:27, Gilles Chanteperdrix va 
> escriure:
> [...]
> > > 
> > > No Gilles, that's the point that I don't understand. Maybe it could be a
> > > language problem.
> > 
> > If you do not understand the text. Read the example.
> 
> what I'm worried about if theses wraps implies more things that are hidden. 
> The example is clear. Maybe I'm imagine more things that really
> exists.

The fact that wrapping may be a problem for large applications where
you only want a small part of the application to use xenomai
services is the reason why Xenomai 3.x gives you another choice: do
not wrap xenomai services, but specify you want to use them with the
__RT() macro.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

El Divendres, 11 de desembre de 2015, a les 17:31:14, Gilles Chanteperdrix va 
escriure:
[...]

> 
> The fact that wrapping may be a problem for large applications where
> you only want a small part of the application to use xenomai
> services is the reason why Xenomai 3.x gives you another choice: do
> not wrap xenomai services, but specify you want to use them with the
> __RT() macro.

 ... following this thread. There's a point that I'm still confused: the rtnet 
part.

Since 2.6.4, rtnet was another project, that installed its includes (rtnet.h 
and rtmac.h) in its own place. From 3.x rtnet is integrated.

Looking the rtnet.h file, there are declared some #define and some include 
protected by __KERNEL__

My question is:

Using the POSIX wrapper, all the socket functions are wrap. But, how does it 
affect the rtnet part of the code? 

I mean, if I have a rtnet device, what is the difference of manually change all 
the network functions with a -DRTNET protected Realtime versions functions or 
use the wrap?

I understand that if I open a device that it's not rtnet, I lose the Realtime, 
although I open the device with a POSIX wrapped function. That's correct?

Best regards,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151215/67bbf584/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Tue, Dec 15, 2015 at 04:16:23PM +0100, Leopold Palomo-Avellaneda wrote:
> El Divendres, 11 de desembre de 2015, a les 17:31:14, Gilles Chanteperdrix va 
> escriure:
> [...]
> 
> > 
> > The fact that wrapping may be a problem for large applications where
> > you only want a small part of the application to use xenomai
> > services is the reason why Xenomai 3.x gives you another choice: do
> > not wrap xenomai services, but specify you want to use them with the
> > __RT() macro.
> 
>  ... following this thread. There's a point that I'm still confused: the rtnet 
> part.
> 
> Since 2.6.4, rtnet was another project, that installed its includes (rtnet.h 
> and rtmac.h) in its own place. From 3.x rtnet is integrated.
> 
> Looking the rtnet.h file, there are declared some #define and some include 
> protected by __KERNEL__
> 
> My question is:
> 
> Using the POSIX wrapper, all the socket functions are wrap. But, how does it 
> affect the rtnet part of the code? 
> 
> I mean, if I have a rtnet device, what is the difference of manually change all 
> the network functions with a -DRTNET protected Realtime versions functions or 
> use the wrap?
> 
> I understand that if I open a device that it's not rtnet, I lose the Realtime, 
> although I open the device with a POSIX wrapped function. That's correct?

There is no difference whatsoever between 2.6 and 3.x in the way to
use RTnet through the POSIX wrapped interface or through the
native/alchemy skin.

If you decide to use RTnet through the POSIX skin, then the wrapped
socket function will create RTnet sockets, and the wrapped sendto
and recvfrom will send and receive data from that socket. No need
for -DRTNET (or -D__XENO__ more likely, as this gets defined by
xeno-config).

If you decide to use RTnet through the alchemy skin, then you would
use the rt_dev or rt_ variant (never can recall what they are
called). Here you would probably use the ugly -D__XENO__.

Now, the difference between 2.6 and 3.x, is that there is a third
way to the POSIX interface: without the wrapping. In that case, if
you call socket(), you get an Linux socket, and if you use
_RT(socket()), you get an RTnet socket (if RTnet stack is compiled
and loaded), of course, you then need to use _RT(sendto()) and
_RT(recvfrom()) to send/receive from that socket.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

El Dimarts, 15 de desembre de 2015, a les 16:46:21, Gilles Chanteperdrix va 
escriure:
> On Tue, Dec 15, 2015 at 04:16:23PM +0100, Leopold Palomo-Avellaneda wrote:
> > El Divendres, 11 de desembre de 2015, a les 17:31:14, Gilles Chanteperdrix
> > va escriure:
> > [...]
> > 
> > > The fact that wrapping may be a problem for large applications where
> > > you only want a small part of the application to use xenomai
> > > services is the reason why Xenomai 3.x gives you another choice: do
> > > not wrap xenomai services, but specify you want to use them with the
> > > __RT() macro.
> >  
> >  ... following this thread. There's a point that I'm still confused: the
> >  rtnet> 
> > part.
> > 
> > Since 2.6.4, rtnet was another project, that installed its includes
> > (rtnet.h and rtmac.h) in its own place. From 3.x rtnet is integrated.
> > 
> > Looking the rtnet.h file, there are declared some #define and some include
> > protected by __KERNEL__
> > 
> > My question is:
> > 
> > Using the POSIX wrapper, all the socket functions are wrap. But, how does
> > it affect the rtnet part of the code?
> > 
> > I mean, if I have a rtnet device, what is the difference of manually
> > change all the network functions with a -DRTNET protected Realtime
> > versions functions or use the wrap?
> > 
> > I understand that if I open a device that it's not rtnet, I lose the
> > Realtime, although I open the device with a POSIX wrapped function.
> > That's correct?
> There is no difference whatsoever between 2.6 and 3.x in the way to
> use RTnet through the POSIX wrapped interface or through the
> native/alchemy skin.
> 
> If you decide to use RTnet through the POSIX skin, then the wrapped
> socket function will create RTnet sockets, and the wrapped sendto
> and recvfrom will send and receive data from that socket. No need
> for -DRTNET (or -D__XENO__ more likely, as this gets defined by
> xeno-config).
> 
> If you decide to use RTnet through the alchemy skin, then you would
> use the rt_dev or rt_ variant (never can recall what they are
> called). Here you would probably use the ugly -D__XENO__.
> 
> Now, the difference between 2.6 and 3.x, is that there is a third
> way to the POSIX interface: without the wrapping. In that case, if
> you call socket(), you get an Linux socket, and if you use
> _RT(socket()), you get an RTnet socket (if RTnet stack is compiled
> and loaded), of course, you then need to use _RT(sendto()) and
> _RT(recvfrom()) to send/receive from that socket.

Thanks Gilles,

the wrap mechanism IMHO open a huge gamma of possibilities. Just, two more 
questions:

- Some of you have tried to "Xenomaize" a common POSIX library, for instance 
with threads and sockets (Poco?... )?

- If I create a library (POSIX) and I wrap the functions (-
Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers). The library users must wrap 
wrap their code too, right? (for instance if they have a printf...)

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151216/987b741f/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Wed, Dec 16, 2015 at 04:45:38PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 15 de desembre de 2015, a les 16:46:21, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Dec 15, 2015 at 04:16:23PM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Divendres, 11 de desembre de 2015, a les 17:31:14, Gilles Chanteperdrix
> > > va escriure:
> > > [...]
> > > 
> > > > The fact that wrapping may be a problem for large applications where
> > > > you only want a small part of the application to use xenomai
> > > > services is the reason why Xenomai 3.x gives you another choice: do
> > > > not wrap xenomai services, but specify you want to use them with the
> > > > __RT() macro.
> > >  
> > >  ... following this thread. There's a point that I'm still confused: the
> > >  rtnet> 
> > > part.
> > > 
> > > Since 2.6.4, rtnet was another project, that installed its includes
> > > (rtnet.h and rtmac.h) in its own place. From 3.x rtnet is integrated.
> > > 
> > > Looking the rtnet.h file, there are declared some #define and some include
> > > protected by __KERNEL__
> > > 
> > > My question is:
> > > 
> > > Using the POSIX wrapper, all the socket functions are wrap. But, how does
> > > it affect the rtnet part of the code?
> > > 
> > > I mean, if I have a rtnet device, what is the difference of manually
> > > change all the network functions with a -DRTNET protected Realtime
> > > versions functions or use the wrap?
> > > 
> > > I understand that if I open a device that it's not rtnet, I lose the
> > > Realtime, although I open the device with a POSIX wrapped function.
> > > That's correct?
> > There is no difference whatsoever between 2.6 and 3.x in the way to
> > use RTnet through the POSIX wrapped interface or through the
> > native/alchemy skin.
> > 
> > If you decide to use RTnet through the POSIX skin, then the wrapped
> > socket function will create RTnet sockets, and the wrapped sendto
> > and recvfrom will send and receive data from that socket. No need
> > for -DRTNET (or -D__XENO__ more likely, as this gets defined by
> > xeno-config).
> > 
> > If you decide to use RTnet through the alchemy skin, then you would
> > use the rt_dev or rt_ variant (never can recall what they are
> > called). Here you would probably use the ugly -D__XENO__.
> > 
> > Now, the difference between 2.6 and 3.x, is that there is a third
> > way to the POSIX interface: without the wrapping. In that case, if
> > you call socket(), you get an Linux socket, and if you use
> > _RT(socket()), you get an RTnet socket (if RTnet stack is compiled
> > and loaded), of course, you then need to use _RT(sendto()) and
> > _RT(recvfrom()) to send/receive from that socket.
> 
> Thanks Gilles,
> 
> the wrap mechanism IMHO open a huge gamma of possibilities. Just, two more 
> questions:
> 
> - Some of you have tried to "Xenomaize" a common POSIX library, for instance 
> with threads and sockets (Poco?... )?

Yes, back in 2006 to 2009, I ported several applications related to
VOIP to use Xenomai and RTnet. From this experience, I wrote this
guide:
https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/

> 
> - If I create a library (POSIX) and I wrap the functions (-
> Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers). The library users must wrap 
> wrap their code too, right? (for instance if they have a
> printf...)

You should compile (and more importantly link edit) all your code,
whether library or executable, with the flags obtained via
xeno-config. If you want to use the static version of the POSIX skin
library, it gets a little more complicated, you do not want to wrap
the symbols of the POSIX skin library itself and you should use the
"wrap-link.sh" script, to do the link edit in two stages.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Porting a library to Xenomai

[Leopold Palomo-Avellaneda]

El Dijous, 17 de desembre de 2015, a les 01:05:18, Gilles Chanteperdrix va 
escriure:
[...]
> > 
> > - Some of you have tried to "Xenomaize" a common POSIX library, for
> > instance with threads and sockets (Poco?... )?
> 
> Yes, back in 2006 to 2009, I ported several applications related to
> VOIP to use Xenomai and RTnet. From this experience, I wrote this
> guide:
> https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kern
> el/

the famous great page ...

> > - If I create a library (POSIX) and I wrap the functions (-
> > Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers). The library users must wrap
> > wrap their code too, right? (for instance if they have a
> > printf...)
> 
> You should compile (and more importantly link edit) all your code,
> whether library or executable, with the flags obtained via
> xeno-config. 

ok, that's clear. For the current case I suppose that it's be the same if the 
library is C++ or C. To be more concisely, if I create a dynamic C++ library 
(*) (libXenofoo), with some *.cpp files. I understand that:

- to compile the files I have to pass the POSIX cflags obtained by xeno-config
- to link that library, I have to pass the POSIX ldflags obtained by xeno-config 
(wrap, etc)

After, if I have a program the uses libXenofoo (dynamic)
- to compile my program, If I don't uses any __Xeno__ * flag I don't need to 
pass the POSIX cflags. Right?
- to link the program against libXenofoo, I understand that yes, that I should 
uses the POSIX ldflags obtained by xeno-config (wrap, etc). Right?

> If you want to use the static version of the POSIX skin
> library, it gets a little more complicated, you do not want to wrap
> the symbols of the POSIX skin library itself and you should use the
> "wrap-link.sh" script, to do the link edit in two stages.

I don't understand that, probably because I use cmake and hides this. But, I 
have created my static version of libXenofoo passing _only_ one time and the 
program have worked. Please, could you elaborate a bit more this?

Leopold


(*) C++ simple, nothing sophisticated with templates, dynamic memory 
allocations, garbage collection. Some classes taking care about memory, etc. 


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151217/e69efd1b/attachment.sig>

Re: [Xenomai] Porting a library to Xenomai

[Gilles Chanteperdrix]

On Thu, Dec 17, 2015 at 10:00:17AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dijous, 17 de desembre de 2015, a les 01:05:18, Gilles Chanteperdrix va 
> escriure:
> [...]
> > > 
> > > - Some of you have tried to "Xenomaize" a common POSIX library, for
> > > instance with threads and sockets (Poco?... )?
> > 
> > Yes, back in 2006 to 2009, I ported several applications related to
> > VOIP to use Xenomai and RTnet. From this experience, I wrote this
> > guide:
> > https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kern
> > el/
> 
> the famous great page ...
> 
> > > - If I create a library (POSIX) and I wrap the functions (-
> > > Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers). The library users must wrap
> > > wrap their code too, right? (for instance if they have a
> > > printf...)
> > 
> > You should compile (and more importantly link edit) all your code,
> > whether library or executable, with the flags obtained via
> > xeno-config. 
> 
> ok, that's clear. For the current case I suppose that it's be the same if the 
> library is C++ or C. To be more concisely, if I create a dynamic C++ library 
> (*) (libXenofoo), with some *.cpp files. I understand that:
> 
> - to compile the files I have to pass the POSIX cflags obtained by xeno-config
> - to link that library, I have to pass the POSIX ldflags obtained by xeno-config 
> (wrap, etc)
> 
> After, if I have a program the uses libXenofoo (dynamic)
> - to compile my program, If I don't uses any __Xeno__ * flag I don't need to 
> pass the POSIX cflags. Right?

It is recommended to use them. Xenomai interposes its own header,
which add some definitions, for instance of functions implemented in
xenomai posix skin, but not in glibc. By including these headers:
- you get the declaration of the __real functions, in case you want
to use the unwrapped function (says __real_pthread_create, to create
a plain Linux thread).
- you get the declaration for Xenomai-specific _np functions, such
as pthread_setmode_np.

> - to link the program against libXenofoo, I understand that yes, that I should 
> uses the POSIX ldflags obtained by xeno-config (wrap, etc). Right?
> 
> > If you want to use the static version of the POSIX skin
> > library, it gets a little more complicated, you do not want to wrap
> > the symbols of the POSIX skin library itself and you should use the
> > "wrap-link.sh" script, to do the link edit in two stages.
> 
> I don't understand that, probably because I use cmake and hides this. But, I 
> have created my static version of libXenofoo passing _only_ one time and the 
> program have worked. Please, could you elaborate a bit more this?

This all happens in the POSIX skin library. The typical __wrap
function calls the __real function under the hood, and a .c file
contains the definition of the __real functions used by the POSIX
skin library itself. So, for instance __wrap_pthread_create calls
__real_pthread_create, which is implemented as a simple call to
pthread_create. If you link that with --wrap (what is vicious is
that I am not sure it happens on all architecture), the call to
pthread_call will be turned into a call to __wrap_pthread_create,
and you get, at run time,  an infinite recursion which ends up with
a segmentation fault due to a stack overflow.

When you generate the POSIX skin library dynamically, this is not a
problem, you just have to link the POSIX skin dynamic library itself
without the --wrap flags.

But when you link your program with the static library, if you do:

gcc -o program program.o libposix.a -lpthread -lrt

The symbols in program.o are not wrapped, so Xenomai functions are
not called.

If you do:

gcc -o program -Wl,--wrap=pthread_create program.o libposix.a -lpthread -lrt

The implementation of __real_pthread_create in libposix.a ends-up
calling __wrap_pthread_create and you get the infinite recursion.

So, the solution is to do:

gcc -Wl,-r -o program.partial-link -Wl,--wrap=pthraed_create program.o
gcc -o program program.partial-link libposix.a -lpthread -lrt

wrap-link.sh saves you the trouble from doing this yoursel, if you do:

wrap-link.sh -o program -Wl,--wrap=pthread_create program.o libposix.a -lpthread -lrt

It will split the link-edit in two stages. I see no reason why cmake
would do that automatically.


> 
> Leopold
> 
> 
> (*) C++ simple, nothing sophisticated with templates, dynamic memory 
> allocations, garbage collection. Some classes taking care about
> memory, etc.

I do not think the C++ features you use matter. What could matter
are static/global objects initializations (as explained in the
document), but I think this has been resolved in Xenomai 3.

-- 
					    Gilles.
https://click-hack.org