[Xenomai] Raspberry and Beaglebone patches

[Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

Hi Stephan, Paul,

we have a problem with the patches for Raspberry and BeagleBone: they
are based on the 3.2.21 patch, which we know is broken. So, we can not
really ship the next version of Xenomai with these patches.

There are two ways we could keep patches for these machines:
- you could send patches for 3.4 or 3.5, or even 3.8
- we could backport the fixes to 3.2, but as already discussed on this
list, this would cost some time to re-validate the 3.2 patch on all
architectures. However, if you do the backport, validate it on your
side, I could validate the result on my test boards, and we would
release a new version of the patch for 3.2 only for the ARM architecture.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Paul]

Hi Gilles

On Monday 15 April 2013, Gilles Chanteperdrix wrote:
> we have a problem with the patches for Raspberry and BeagleBone: they
> are based on the 3.2.21 patch, which we know is broken. So, we can
> not really ship the next version of Xenomai with these patches.

The original Raspberry patch from Ian-cim consisted of adding ipipe 
timer support to the BSP sources in 3.2.21. My efforts concentrated on 
backporting some of the Raspberry specific support from their 3.6.y 
tree to Xenomai 3.5.7 - Any breakages in 3.2.xx shouldn't be an issue.

> There are two ways we could keep patches for these machines:
> - you could send patches for 3.4 or 3.5, or even 3.8

The Raspberry patch is already at 3.5.7, not sure what state the 
raspberry-3.8.y tree is in at the moment. Time allowing, I'll have a 
look at a 3.8 patch over the next few days.

> - we could backport the fixes to 3.2, but as already discussed on
> this list, this would cost some time to re-validate the 3.2 patch on
> all architectures. However, if you do the backport, validate it on
> your side, I could validate the result on my test boards, and we
> would release a new version of the patch for 3.2 only for the ARM
> architecture.

I feel my time would be better spent on updating to 3.8, so I'll give 
the backport a miss for now ;-)


Regards, Paul.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 04/15/2013 12:52 PM, Paul wrote:

> 
> Hi Gilles
> 
> On Monday 15 April 2013, Gilles Chanteperdrix wrote:
>> we have a problem with the patches for Raspberry and BeagleBone: they
>> are based on the 3.2.21 patch, which we know is broken. So, we can
>> not really ship the next version of Xenomai with these patches.
> 
> The original Raspberry patch from Ian-cim consisted of adding ipipe 
> timer support to the BSP sources in 3.2.21. My efforts concentrated on 
> backporting some of the Raspberry specific support from their 3.6.y 
> tree to Xenomai 3.5.7 - Any breakages in 3.2.xx shouldn't be an issue.
> 
>> There are two ways we could keep patches for these machines:
>> - you could send patches for 3.4 or 3.5, or even 3.8
> 
> The Raspberry patch is already at 3.5.7, not sure what state the 
> raspberry-3.8.y tree is in at the moment. Time allowing, I'll have a 
> look at a 3.8 patch over the next few days.
> 
>> - we could backport the fixes to 3.2, but as already discussed on
>> this list, this would cost some time to re-validate the 3.2 patch on
>> all architectures. However, if you do the backport, validate it on
>> your side, I could validate the result on my test boards, and we
>> would release a new version of the patch for 3.2 only for the ARM
>> architecture.
> 
> I feel my time would be better spent on updating to 3.8, so I'll give 
> the backport a miss for now ;-)


Sorry for the noise, I thought the Raspberry Pi patch was for 3.2. Yes,
the patch for 3.8 would be intersting to get for the 2.6.3 release.


-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:

> 
> Hi Stephan, Paul,
> 
> we have a problem with the patches for Raspberry and BeagleBone: they
> are based on the 3.2.21 patch, which we know is broken. So, we can not
> really ship the next version of Xenomai with these patches.
> 
> There are two ways we could keep patches for these machines:
> - you could send patches for 3.4 or 3.5, or even 3.8
> - we could backport the fixes to 3.2, but as already discussed on this
> list, this would cost some time to re-validate the 3.2 patch on all
> architectures. However, if you do the backport, validate it on your
> side, I could validate the result on my test boards, and we would
> release a new version of the patch for 3.2 only for the ARM architecture.
> 
> Regards.
> 
> -- 
>                                                                Gilles.
> 

Hi Gilles,

there's a 3.8.7 branch available for beagleBone at https://github.com/beagleboard/kernel/tree/3.8.

I can look into updating the beagleBone patch for that repository. Where do I find the latest ipipe patch for 3.8 on ARM?

- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 04/16/2013 12:26 PM, Stephan Kappertz wrote:

> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
> 
>>
>> Hi Stephan, Paul,
>>
>> we have a problem with the patches for Raspberry and BeagleBone: they
>> are based on the 3.2.21 patch, which we know is broken. So, we can not
>> really ship the next version of Xenomai with these patches.
>>
>> There are two ways we could keep patches for these machines:
>> - you could send patches for 3.4 or 3.5, or even 3.8
>> - we could backport the fixes to 3.2, but as already discussed on this
>> list, this would cost some time to re-validate the 3.2 patch on all
>> architectures. However, if you do the backport, validate it on your
>> side, I could validate the result on my test boards, and we would
>> release a new version of the patch for 3.2 only for the ARM architecture.
>>
>> Regards.
>>
>> -- 
>>                                                                Gilles.
>>
> 
> Hi Gilles,
> 
> there's a 3.8.7 branch available for beagleBone at https://github.com/beagleboard/kernel/tree/3.8.
> 
> I can look into updating the beagleBone patch for that repository. Where do I find the latest ipipe patch for 3.8 on ARM?


ipipe-gch repository, for-core-3.8 branch.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Paul]

On Monday 15 April 2013, Gilles Chanteperdrix wrote:
> On 04/15/2013 12:52 PM, Paul wrote:
> > Hi Gilles
> >
> > On Monday 15 April 2013, Gilles Chanteperdrix wrote:
> >> we have a problem with the patches for Raspberry and BeagleBone:
> >> they are based on the 3.2.21 patch, which we know is broken. So,
> >> we can not really ship the next version of Xenomai with these
> >> patches.
> >
> > The original Raspberry patch from Ian-cim consisted of adding ipipe
> > timer support to the BSP sources in 3.2.21. My efforts concentrated
> > on backporting some of the Raspberry specific support from their
> > 3.6.y tree to Xenomai 3.5.7 - Any breakages in 3.2.xx shouldn't be
> > an issue.
> >
> >> There are two ways we could keep patches for these machines:
> >> - you could send patches for 3.4 or 3.5, or even 3.8
> >
> > The Raspberry patch is already at 3.5.7, not sure what state the
> > raspberry-3.8.y tree is in at the moment. Time allowing, I'll have
> > a look at a 3.8 patch over the next few days.
> >
> >> - we could backport the fixes to 3.2, but as already discussed on
> >> this list, this would cost some time to re-validate the 3.2 patch
> >> on all architectures. However, if you do the backport, validate it
> >> on your side, I could validate the result on my test boards, and
> >> we would release a new version of the patch for 3.2 only for the
> >> ARM architecture.
> >
> > I feel my time would be better spent on updating to 3.8, so I'll
> > give the backport a miss for now ;-)
>
> Sorry for the noise, I thought the Raspberry Pi patch was for 3.2.
> Yes, the patch for 3.8 would be intersting to get for the 2.6.3
> release.

Just finished compiling a 3.8.8 kernel based on the 
github.com/raspberrypi/linux.git sources with the for-core-3.8 patches 
on top. When you're ready to tag an ipipe-core-3.8 and release the 
patch, I can generate pre/post patches for the Raspberry Pi (almost) on 
demand.


Regards, Paul.

Re: [Xenomai] Raspberry and Beaglebone patches

[Jason Kridner]

On Sat, Apr 20, 2013 at 7:44 PM, Paul <paul_c@tuxcnc.org> wrote:
> On Monday 15 April 2013, Gilles Chanteperdrix wrote:
>> On 04/15/2013 12:52 PM, Paul wrote:
>> > Hi Gilles
>> >
>> > On Monday 15 April 2013, Gilles Chanteperdrix wrote:
>> >> we have a problem with the patches for Raspberry and BeagleBone:
>> >> they are based on the 3.2.21 patch, which we know is broken. So,
>> >> we can not really ship the next version of Xenomai with these
>> >> patches.
>> >
>> > The original Raspberry patch from Ian-cim consisted of adding ipipe
>> > timer support to the BSP sources in 3.2.21. My efforts concentrated
>> > on backporting some of the Raspberry specific support from their
>> > 3.6.y tree to Xenomai 3.5.7 - Any breakages in 3.2.xx shouldn't be
>> > an issue.
>> >
>> >> There are two ways we could keep patches for these machines:
>> >> - you could send patches for 3.4 or 3.5, or even 3.8
>> >
>> > The Raspberry patch is already at 3.5.7, not sure what state the
>> > raspberry-3.8.y tree is in at the moment. Time allowing, I'll have
>> > a look at a 3.8 patch over the next few days.
>> >
>> >> - we could backport the fixes to 3.2, but as already discussed on
>> >> this list, this would cost some time to re-validate the 3.2 patch
>> >> on all architectures. However, if you do the backport, validate it
>> >> on your side, I could validate the result on my test boards, and
>> >> we would release a new version of the patch for 3.2 only for the
>> >> ARM architecture.
>> >
>> > I feel my time would be better spent on updating to 3.8, so I'll
>> > give the backport a miss for now ;-)
>>
>> Sorry for the noise, I thought the Raspberry Pi patch was for 3.2.
>> Yes, the patch for 3.8 would be intersting to get for the 2.6.3
>> release.
>
> Just finished compiling a 3.8.8 kernel based on the
> github.com/raspberrypi/linux.git sources with the for-core-3.8 patches
> on top. When you're ready to tag an ipipe-core-3.8 and release the
> patch, I can generate pre/post patches for the Raspberry Pi (almost) on
> demand.

Should I ever expect to see a pull request to
http://github.com/beagleboard/kernel/tree/3.8 to either pre or post
patch in Xenomai?  The way we maintain the kernel, you simply drop the
patches into a subdirectory of the patches directory and add the name
of that subdirectory to patch.sh.  Running patch.sh applies all of the
vendor patches against the mainline-stable tree.

Over time, I certainly hope our out-of-tree patches will go to 0 and
we are working on it.

>
>
> Regards, Paul.
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:

> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
> 
>> 
>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>> 
>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>> 
>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> 
>>>>> Hi Stephan, Paul,
>>>>> 
>>>>> we have a problem with the patches for Raspberry and BeagleBone: they
>>>>> are based on the 3.2.21 patch, which we know is broken. So, we can not
>>>>> really ship the next version of Xenomai with these patches.
>>>>> 
>>>>> There are two ways we could keep patches for these machines:
>>>>> - you could send patches for 3.4 or 3.5, or even 3.8
>>>>> - we could backport the fixes to 3.2, but as already discussed on this
>>>>> list, this would cost some time to re-validate the 3.2 patch on all
>>>>> architectures. However, if you do the backport, validate it on your
>>>>> side, I could validate the result on my test boards, and we would
>>>>> release a new version of the patch for 3.2 only for the ARM architecture.
>>>>> 
>>>>> Regards.
>>>>> 
>>>>> -- 
>>>>>                                                              Gilles.
>>>>> 
>>>> 
>>>> Hi Gilles,
>>>> 
>>>> there's a 3.8.7 branch available for beagleBone at https://github.com/beagleboard/kernel/tree/3.8.
>>>> 
>>>> I can look into updating the beagleBone patch for that repository. Where do I find the latest ipipe patch for 3.8 on ARM?
>>> 
>>> 
>>> ipipe-gch repository, for-core-3.8 branch.
>>> 
>>> -- 
>>>                                                               Gilles.
>>> 
>> 
>> Hi Gilles, do you have a script to create the ipipe patch file? Can't find any in the pipe-gch repository.
> 
> 
> It is not yet in the repository, if you want the definitive patch,
> please wait a bit, the patch should be released soon.
> 
> 
> -- 
>                                                                Gilles.
> 

Hi Gilles,

I have created a ipipe post patch for the beagleBone kernel v3.8.10 found here:

https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8, branch am33x-v3.8

Your pipe-gch repository is based on 3.8 while the upper repository is at 3.8.10. Thus I had to apply a few minor changes to the patch file created from your git. Are you going to rebase the ipipe patch to 3.8.10 or higher before releasing it? If so, the beagleBone patch gets reduced to the post patch below:

- Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: post.patch
Type: application/octet-stream
Size: 1483 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130503/47580d87/attachment.obj>
-------------- next part --------------

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/03/2013 04:28 PM, Stephan Kappertz wrote:

> 
> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
> 
>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>> 
>>> 
>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>> 
>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>> 
>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>> 
>>>>>> 
>>>>>> Hi Stephan, Paul,
>>>>>> 
>>>>>> we have a problem with the patches for Raspberry and
>>>>>> BeagleBone: they are based on the 3.2.21 patch, which we
>>>>>> know is broken. So, we can not really ship the next version
>>>>>> of Xenomai with these patches.
>>>>>> 
>>>>>> There are two ways we could keep patches for these
>>>>>> machines: - you could send patches for 3.4 or 3.5, or even
>>>>>> 3.8 - we could backport the fixes to 3.2, but as already
>>>>>> discussed on this list, this would cost some time to
>>>>>> re-validate the 3.2 patch on all architectures. However, if
>>>>>> you do the backport, validate it on your side, I could
>>>>>> validate the result on my test boards, and we would release
>>>>>> a new version of the patch for 3.2 only for the ARM
>>>>>> architecture.
>>>>>> 
>>>>>> Regards.
>>>>>> 
>>>>>> -- Gilles.
>>>>>> 
>>>>> 
>>>>> Hi Gilles,
>>>>> 
>>>>> there's a 3.8.7 branch available for beagleBone at
>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>> 
>>>>> I can look into updating the beagleBone patch for that
>>>>> repository. Where do I find the latest ipipe patch for 3.8 on
>>>>> ARM?
>>>> 
>>>> 
>>>> ipipe-gch repository, for-core-3.8 branch.
>>>> 
>>>> -- Gilles.
>>>> 
>>> 
>>> Hi Gilles, do you have a script to create the ipipe patch file?
>>> Can't find any in the pipe-gch repository.
>> 
>> 
>> It is not yet in the repository, if you want the definitive patch, 
>> please wait a bit, the patch should be released soon.
>> 
>> 
>> -- Gilles.
>> 
> 
> Hi Gilles,
> 
> I have created a ipipe post patch for the beagleBone kernel v3.8.10
> found here:
> 
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8, branch
> am33x-v3.8
> 
> Your pipe-gch repository is based on 3.8 while the upper repository
> is at 3.8.10. Thus I had to apply a few minor changes to the patch
> file created from your git. Are you going to rebase the ipipe patch
> to 3.8.10 or higher before releasing it?


I do not know, Philippe is going to make the patch, he will decide on
which version he rebases.

> If so, the beagleBone patch
> gets reduced to the post patch below:


Ok, several remarks:
- can not we put that code in the mainline kernel (meaning, does
soc_is_am33xx() exist in the mainline kernel, if it does not exist, can
not we add it?)
- the coding style for the tsc declaration is bad, braces are not put on
separate lines in the Linux kernel coding style;
- since the only difference between am33xx and other omaps is
OMAP_TIMER_CAPTURE_REG vs OMAP_TIMER_COUNTER_REG, why not put this in a
local variable and use it twice?


-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:

> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
> 
>> 
>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>> 
>>>> 
>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>>> 
>>>>>>> 
>>>>>>> Hi Stephan, Paul,
>>>>>>> 
>>>>>>> we have a problem with the patches for Raspberry and
>>>>>>> BeagleBone: they are based on the 3.2.21 patch, which we
>>>>>>> know is broken. So, we can not really ship the next version
>>>>>>> of Xenomai with these patches.
>>>>>>> 
>>>>>>> There are two ways we could keep patches for these
>>>>>>> machines: - you could send patches for 3.4 or 3.5, or even
>>>>>>> 3.8 - we could backport the fixes to 3.2, but as already
>>>>>>> discussed on this list, this would cost some time to
>>>>>>> re-validate the 3.2 patch on all architectures. However, if
>>>>>>> you do the backport, validate it on your side, I could
>>>>>>> validate the result on my test boards, and we would release
>>>>>>> a new version of the patch for 3.2 only for the ARM
>>>>>>> architecture.
>>>>>>> 
>>>>>>> Regards.
>>>>>>> 
>>>>>>> -- Gilles.
>>>>>>> 
>>>>>> 
>>>>>> Hi Gilles,
>>>>>> 
>>>>>> there's a 3.8.7 branch available for beagleBone at
>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>> 
>>>>>> I can look into updating the beagleBone patch for that
>>>>>> repository. Where do I find the latest ipipe patch for 3.8 on
>>>>>> ARM?
>>>>> 
>>>>> 
>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>> 
>>>>> -- Gilles.
>>>>> 
>>>> 
>>>> Hi Gilles, do you have a script to create the ipipe patch file?
>>>> Can't find any in the pipe-gch repository.
>>> 
>>> 
>>> It is not yet in the repository, if you want the definitive patch, 
>>> please wait a bit, the patch should be released soon.
>>> 
>>> 
>>> -- Gilles.
>>> 
>> 
>> Hi Gilles,
>> 
>> I have created a ipipe post patch for the beagleBone kernel v3.8.10
>> found here:
>> 
>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8, branch
>> am33x-v3.8
>> 
>> Your pipe-gch repository is based on 3.8 while the upper repository
>> is at 3.8.10. Thus I had to apply a few minor changes to the patch
>> file created from your git. Are you going to rebase the ipipe patch
>> to 3.8.10 or higher before releasing it?
> 
> 
> I do not know, Philippe is going to make the patch, he will decide on
> which version he rebases.
> 
>> If so, the beagleBone patch
>> gets reduced to the post patch below:
> 
> 
> Ok, several remarks:
> - can not we put that code in the mainline kernel (meaning, does
> soc_is_am33xx() exist in the mainline kernel, if it does not exist, can
> not we add it?)
> - the coding style for the tsc declaration is bad, braces are not put on
> separate lines in the Linux kernel coding style;
> - since the only difference between am33xx and other omaps is
> OMAP_TIMER_CAPTURE_REG vs OMAP_TIMER_COUNTER_REG, why not put this in a
> local variable and use it twice?
> 
> 
> -- 
>                                                                Gilles.
> 

Yes, soc_is_am33xx() is indeed defined in the mainline kernel starting from 3.6. So the beagleBone patch can safely be put into the mainline ipipe sources. 

I'll fix the coding style and send a new patch. Actually using soc_is_am33xx() for the TSC register location decision was an unnecessary constraint. The OMAP timer struct has a revision field that is 2 for the v2 timer IP. In rev 2, all functional registers are offset by OMAP_TIMER_V2_FUNC_OFFSET.

-- Stephan

 

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/03/2013 10:41 PM, Stephan Kappertz wrote:

> 
> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
> 
>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>> 
>>> 
>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>> 
>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>> 
>>>>> 
>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>> 
>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>> 
>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Stephan, Paul,
>>>>>>>> 
>>>>>>>> we have a problem with the patches for Raspberry and 
>>>>>>>> BeagleBone: they are based on the 3.2.21 patch, which
>>>>>>>> we know is broken. So, we can not really ship the next
>>>>>>>> version of Xenomai with these patches.
>>>>>>>> 
>>>>>>>> There are two ways we could keep patches for these 
>>>>>>>> machines: - you could send patches for 3.4 or 3.5, or
>>>>>>>> even 3.8 - we could backport the fixes to 3.2, but as
>>>>>>>> already discussed on this list, this would cost some
>>>>>>>> time to re-validate the 3.2 patch on all architectures.
>>>>>>>> However, if you do the backport, validate it on your
>>>>>>>> side, I could validate the result on my test boards,
>>>>>>>> and we would release a new version of the patch for 3.2
>>>>>>>> only for the ARM architecture.
>>>>>>>> 
>>>>>>>> Regards.
>>>>>>>> 
>>>>>>>> -- Gilles.
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi Gilles,
>>>>>>> 
>>>>>>> there's a 3.8.7 branch available for beagleBone at 
>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>> 
>>>>>>> I can look into updating the beagleBone patch for that 
>>>>>>> repository. Where do I find the latest ipipe patch for
>>>>>>> 3.8 on ARM?
>>>>>> 
>>>>>> 
>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>> 
>>>>>> -- Gilles.
>>>>>> 
>>>>> 
>>>>> Hi Gilles, do you have a script to create the ipipe patch
>>>>> file? Can't find any in the pipe-gch repository.
>>>> 
>>>> 
>>>> It is not yet in the repository, if you want the definitive
>>>> patch, please wait a bit, the patch should be released soon.
>>>> 
>>>> 
>>>> -- Gilles.
>>>> 
>>> 
>>> Hi Gilles,
>>> 
>>> I have created a ipipe post patch for the beagleBone kernel
>>> v3.8.10 found here:
>>> 
>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>> branch am33x-v3.8
>>> 
>>> Your pipe-gch repository is based on 3.8 while the upper
>>> repository is at 3.8.10. Thus I had to apply a few minor changes
>>> to the patch file created from your git. Are you going to rebase
>>> the ipipe patch to 3.8.10 or higher before releasing it?
>> 
>> 
>> I do not know, Philippe is going to make the patch, he will decide
>> on which version he rebases.
>> 
>>> If so, the beagleBone patch gets reduced to the post patch
>>> below:
>> 
>> 
>> Ok, several remarks: - can not we put that code in the mainline
>> kernel (meaning, does soc_is_am33xx() exist in the mainline kernel,
>> if it does not exist, can not we add it?) - the coding style for
>> the tsc declaration is bad, braces are not put on separate lines in
>> the Linux kernel coding style; - since the only difference between
>> am33xx and other omaps is OMAP_TIMER_CAPTURE_REG vs
>> OMAP_TIMER_COUNTER_REG, why not put this in a local variable and
>> use it twice?
>> 
>> 
>> -- Gilles.
>> 
> 
> Yes, soc_is_am33xx() is indeed defined in the mainline kernel
> starting from 3.6. So the beagleBone patch can safely be put into the
> mainline ipipe sources.
> 
> I'll fix the coding style and send a new patch. Actually using
> soc_is_am33xx() for the TSC register location decision was an
> unnecessary constraint. The OMAP timer struct has a revision field
> that is 2 for the v2 timer IP. In rev 2, all functional registers are
> offset by OMAP_TIMER_V2_FUNC_OFFSET.


Hi,

any news about this patch?

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 08.05.2013 um 20:27 schrieb Gilles Chanteperdrix:

> On 05/03/2013 10:41 PM, Stephan Kappertz wrote:
> 
>> 
>> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>>> 
>>>> 
>>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>> 
>>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>>> 
>>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>>> 
>>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Stephan, Paul,
>>>>>>>>> 
>>>>>>>>> we have a problem with the patches for Raspberry and 
>>>>>>>>> BeagleBone: they are based on the 3.2.21 patch, which
>>>>>>>>> we know is broken. So, we can not really ship the next
>>>>>>>>> version of Xenomai with these patches.
>>>>>>>>> 
>>>>>>>>> There are two ways we could keep patches for these 
>>>>>>>>> machines: - you could send patches for 3.4 or 3.5, or
>>>>>>>>> even 3.8 - we could backport the fixes to 3.2, but as
>>>>>>>>> already discussed on this list, this would cost some
>>>>>>>>> time to re-validate the 3.2 patch on all architectures.
>>>>>>>>> However, if you do the backport, validate it on your
>>>>>>>>> side, I could validate the result on my test boards,
>>>>>>>>> and we would release a new version of the patch for 3.2
>>>>>>>>> only for the ARM architecture.
>>>>>>>>> 
>>>>>>>>> Regards.
>>>>>>>>> 
>>>>>>>>> -- Gilles.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Gilles,
>>>>>>>> 
>>>>>>>> there's a 3.8.7 branch available for beagleBone at 
>>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>>> 
>>>>>>>> I can look into updating the beagleBone patch for that 
>>>>>>>> repository. Where do I find the latest ipipe patch for
>>>>>>>> 3.8 on ARM?
>>>>>>> 
>>>>>>> 
>>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>>> 
>>>>>>> -- Gilles.
>>>>>>> 
>>>>>> 
>>>>>> Hi Gilles, do you have a script to create the ipipe patch
>>>>>> file? Can't find any in the pipe-gch repository.
>>>>> 
>>>>> 
>>>>> It is not yet in the repository, if you want the definitive
>>>>> patch, please wait a bit, the patch should be released soon.
>>>>> 
>>>>> 
>>>>> -- Gilles.
>>>>> 
>>>> 
>>>> Hi Gilles,
>>>> 
>>>> I have created a ipipe post patch for the beagleBone kernel
>>>> v3.8.10 found here:
>>>> 
>>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>>> branch am33x-v3.8
>>>> 
>>>> Your pipe-gch repository is based on 3.8 while the upper
>>>> repository is at 3.8.10. Thus I had to apply a few minor changes
>>>> to the patch file created from your git. Are you going to rebase
>>>> the ipipe patch to 3.8.10 or higher before releasing it?
>>> 
>>> 
>>> I do not know, Philippe is going to make the patch, he will decide
>>> on which version he rebases.
>>> 
>>>> If so, the beagleBone patch gets reduced to the post patch
>>>> below:
>>> 
>>> 
>>> Ok, several remarks: - can not we put that code in the mainline
>>> kernel (meaning, does soc_is_am33xx() exist in the mainline kernel,
>>> if it does not exist, can not we add it?) - the coding style for
>>> the tsc declaration is bad, braces are not put on separate lines in
>>> the Linux kernel coding style; - since the only difference between
>>> am33xx and other omaps is OMAP_TIMER_CAPTURE_REG vs
>>> OMAP_TIMER_COUNTER_REG, why not put this in a local variable and
>>> use it twice?
>>> 
>>> 
>>> -- Gilles.
>>> 
>> 
>> Yes, soc_is_am33xx() is indeed defined in the mainline kernel
>> starting from 3.6. So the beagleBone patch can safely be put into the
>> mainline ipipe sources.
>> 
>> I'll fix the coding style and send a new patch. Actually using
>> soc_is_am33xx() for the TSC register location decision was an
>> unnecessary constraint. The OMAP timer struct has a revision field
>> that is 2 for the v2 timer IP. In rev 2, all functional registers are
>> offset by OMAP_TIMER_V2_FUNC_OFFSET.
> 
> 
> Hi,
> 
> any news about this patch?
> 
> Regards.
> 
> -- 
>                                                                Gilles.
> 

Sorry for the delay, here it is. Tested against pipe-gch for-core-3.8. Xenomai is successfully starting on the beagleBone:

[    0.537862] I-pipe: head domain Xenomai registered.
[    0.537909] Xenomai: hal/arm started.
[    0.539781] Xenomai: scheduling class idle registered.
[    0.539815] Xenomai: scheduling class rt registered.
[    0.545077] Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.
[    0.545089] Xenomai: debug mode enabled.
[    0.545733] Xenomai: starting native API services.
[    0.545752] Xenomai: starting POSIX services.
[    0.545930] Xenomai: starting RTDM services.

# cat /proc/xenomai/version 
2.6.2.1

# cat /proc/ipipe/version 
3

# ls /proc/xenomai/interfaces/
native  posix   rtdm    sys

but I do see the same problem as Michael, xenon-test output:

# xeno-test
Started child 127: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ /usr/bin/arith
Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.
(modprobe xeno_native?)
# 

- Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: post.patch
Type: application/octet-stream
Size: 1478 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130510/e97d1e4d/attachment.obj>
-------------- next part --------------

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/10/2013 01:53 PM, Stephan Kappertz wrote:

> Am 08.05.2013 um 20:27 schrieb Gilles Chanteperdrix:
> 
>> On 05/03/2013 10:41 PM, Stephan Kappertz wrote:
>>
>>>
>>> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
>>>
>>>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>>>>
>>>>>
>>>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>>>>
>>>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>>>>
>>>>>>>
>>>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>>>>
>>>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>>>>
>>>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Stephan, Paul,
>>>>>>>>>>
>>>>>>>>>> we have a problem with the patches for Raspberry and 
>>>>>>>>>> BeagleBone: they are based on the 3.2.21 patch, which
>>>>>>>>>> we know is broken. So, we can not really ship the next
>>>>>>>>>> version of Xenomai with these patches.
>>>>>>>>>>
>>>>>>>>>> There are two ways we could keep patches for these 
>>>>>>>>>> machines: - you could send patches for 3.4 or 3.5, or
>>>>>>>>>> even 3.8 - we could backport the fixes to 3.2, but as
>>>>>>>>>> already discussed on this list, this would cost some
>>>>>>>>>> time to re-validate the 3.2 patch on all architectures.
>>>>>>>>>> However, if you do the backport, validate it on your
>>>>>>>>>> side, I could validate the result on my test boards,
>>>>>>>>>> and we would release a new version of the patch for 3.2
>>>>>>>>>> only for the ARM architecture.
>>>>>>>>>>
>>>>>>>>>> Regards.
>>>>>>>>>>
>>>>>>>>>> -- Gilles.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Gilles,
>>>>>>>>>
>>>>>>>>> there's a 3.8.7 branch available for beagleBone at 
>>>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>>>>
>>>>>>>>> I can look into updating the beagleBone patch for that 
>>>>>>>>> repository. Where do I find the latest ipipe patch for
>>>>>>>>> 3.8 on ARM?
>>>>>>>>
>>>>>>>>
>>>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>>>>
>>>>>>>> -- Gilles.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Gilles, do you have a script to create the ipipe patch
>>>>>>> file? Can't find any in the pipe-gch repository.
>>>>>>
>>>>>>
>>>>>> It is not yet in the repository, if you want the definitive
>>>>>> patch, please wait a bit, the patch should be released soon.
>>>>>>
>>>>>>
>>>>>> -- Gilles.
>>>>>>
>>>>>
>>>>> Hi Gilles,
>>>>>
>>>>> I have created a ipipe post patch for the beagleBone kernel
>>>>> v3.8.10 found here:
>>>>>
>>>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>>>> branch am33x-v3.8
>>>>>
>>>>> Your pipe-gch repository is based on 3.8 while the upper
>>>>> repository is at 3.8.10. Thus I had to apply a few minor changes
>>>>> to the patch file created from your git. Are you going to rebase
>>>>> the ipipe patch to 3.8.10 or higher before releasing it?
>>>>
>>>>
>>>> I do not know, Philippe is going to make the patch, he will decide
>>>> on which version he rebases.
>>>>
>>>>> If so, the beagleBone patch gets reduced to the post patch
>>>>> below:
>>>>
>>>>
>>>> Ok, several remarks: - can not we put that code in the mainline
>>>> kernel (meaning, does soc_is_am33xx() exist in the mainline kernel,
>>>> if it does not exist, can not we add it?) - the coding style for
>>>> the tsc declaration is bad, braces are not put on separate lines in
>>>> the Linux kernel coding style; - since the only difference between
>>>> am33xx and other omaps is OMAP_TIMER_CAPTURE_REG vs
>>>> OMAP_TIMER_COUNTER_REG, why not put this in a local variable and
>>>> use it twice?
>>>>
>>>>
>>>> -- Gilles.
>>>>
>>>
>>> Yes, soc_is_am33xx() is indeed defined in the mainline kernel
>>> starting from 3.6. So the beagleBone patch can safely be put into the
>>> mainline ipipe sources.
>>>
>>> I'll fix the coding style and send a new patch. Actually using
>>> soc_is_am33xx() for the TSC register location decision was an
>>> unnecessary constraint. The OMAP timer struct has a revision field
>>> that is 2 for the v2 timer IP. In rev 2, all functional registers are
>>> offset by OMAP_TIMER_V2_FUNC_OFFSET.
>>
>>
>> Hi,
>>
>> any news about this patch?
>>
>> Regards.
>>
>> -- 
>>                                                                Gilles.
>>
> 
> Sorry for the delay, here it is. Tested against pipe-gch for-core-3.8. Xenomai is successfully starting on the beagleBone:


What version of Linux are you using, is this 3.8.0, or another version
as you told me in a previous mail?

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 10.05.2013 um 15:21 schrieb Gilles Chanteperdrix:

> On 05/10/2013 01:53 PM, Stephan Kappertz wrote:
> 
>> Am 08.05.2013 um 20:27 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/03/2013 10:41 PM, Stephan Kappertz wrote:
>>> 
>>>> 
>>>> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>> 
>>>>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>>>>> 
>>>>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>>>>> 
>>>>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>>>>> 
>>>>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles Chanteperdrix:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi Stephan, Paul,
>>>>>>>>>>> 
>>>>>>>>>>> we have a problem with the patches for Raspberry and 
>>>>>>>>>>> BeagleBone: they are based on the 3.2.21 patch, which
>>>>>>>>>>> we know is broken. So, we can not really ship the next
>>>>>>>>>>> version of Xenomai with these patches.
>>>>>>>>>>> 
>>>>>>>>>>> There are two ways we could keep patches for these 
>>>>>>>>>>> machines: - you could send patches for 3.4 or 3.5, or
>>>>>>>>>>> even 3.8 - we could backport the fixes to 3.2, but as
>>>>>>>>>>> already discussed on this list, this would cost some
>>>>>>>>>>> time to re-validate the 3.2 patch on all architectures.
>>>>>>>>>>> However, if you do the backport, validate it on your
>>>>>>>>>>> side, I could validate the result on my test boards,
>>>>>>>>>>> and we would release a new version of the patch for 3.2
>>>>>>>>>>> only for the ARM architecture.
>>>>>>>>>>> 
>>>>>>>>>>> Regards.
>>>>>>>>>>> 
>>>>>>>>>>> -- Gilles.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Gilles,
>>>>>>>>>> 
>>>>>>>>>> there's a 3.8.7 branch available for beagleBone at 
>>>>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>>>>> 
>>>>>>>>>> I can look into updating the beagleBone patch for that 
>>>>>>>>>> repository. Where do I find the latest ipipe patch for
>>>>>>>>>> 3.8 on ARM?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>>>>> 
>>>>>>>>> -- Gilles.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Gilles, do you have a script to create the ipipe patch
>>>>>>>> file? Can't find any in the pipe-gch repository.
>>>>>>> 
>>>>>>> 
>>>>>>> It is not yet in the repository, if you want the definitive
>>>>>>> patch, please wait a bit, the patch should be released soon.
>>>>>>> 
>>>>>>> 
>>>>>>> -- Gilles.
>>>>>>> 
>>>>>> 
>>>>>> Hi Gilles,
>>>>>> 
>>>>>> I have created a ipipe post patch for the beagleBone kernel
>>>>>> v3.8.10 found here:
>>>>>> 
>>>>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>>>>> branch am33x-v3.8
>>>>>> 
>>>>>> Your pipe-gch repository is based on 3.8 while the upper
>>>>>> repository is at 3.8.10. Thus I had to apply a few minor changes
>>>>>> to the patch file created from your git. Are you going to rebase
>>>>>> the ipipe patch to 3.8.10 or higher before releasing it?
>>>>> 
>>>>> 
>>>>> I do not know, Philippe is going to make the patch, he will decide
>>>>> on which version he rebases.
>>>>> 
>>>>>> If so, the beagleBone patch gets reduced to the post patch
>>>>>> below:
>>>>> 
>>>>> 
>>>>> Ok, several remarks: - can not we put that code in the mainline
>>>>> kernel (meaning, does soc_is_am33xx() exist in the mainline kernel,
>>>>> if it does not exist, can not we add it?) - the coding style for
>>>>> the tsc declaration is bad, braces are not put on separate lines in
>>>>> the Linux kernel coding style; - since the only difference between
>>>>> am33xx and other omaps is OMAP_TIMER_CAPTURE_REG vs
>>>>> OMAP_TIMER_COUNTER_REG, why not put this in a local variable and
>>>>> use it twice?
>>>>> 
>>>>> 
>>>>> -- Gilles.
>>>>> 
>>>> 
>>>> Yes, soc_is_am33xx() is indeed defined in the mainline kernel
>>>> starting from 3.6. So the beagleBone patch can safely be put into the
>>>> mainline ipipe sources.
>>>> 
>>>> I'll fix the coding style and send a new patch. Actually using
>>>> soc_is_am33xx() for the TSC register location decision was an
>>>> unnecessary constraint. The OMAP timer struct has a revision field
>>>> that is 2 for the v2 timer IP. In rev 2, all functional registers are
>>>> offset by OMAP_TIMER_V2_FUNC_OFFSET.
>>> 
>>> 
>>> Hi,
>>> 
>>> any news about this patch?
>>> 
>>> Regards.
>>> 
>>> -- 
>>>                                                               Gilles.
>>> 
>> 
>> Sorry for the delay, here it is. Tested against pipe-gch for-core-3.8. Xenomai is successfully starting on the beagleBone:
> 
> 
> What version of Linux are you using, is this 3.8.0, or another version
> as you told me in a previous mail?
> 
> -- 
>                                                                Gilles.
> 

I'm using your git repository directly. Applied my post.patch and compiled the kernel. So this is 3.8.0. Looks like my Xenomai user space compile was broken. Still working on fixing it.

- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/10/2013 04:43 PM, Stephan Kappertz wrote:

> 
> Am 10.05.2013 um 15:21 schrieb Gilles Chanteperdrix:
> 
>> On 05/10/2013 01:53 PM, Stephan Kappertz wrote:
>> 
>>> Am 08.05.2013 um 20:27 schrieb Gilles Chanteperdrix:
>>> 
>>>> On 05/03/2013 10:41 PM, Stephan Kappertz wrote:
>>>> 
>>>>> 
>>>>> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
>>>>> 
>>>>>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>>>>>> 
>>>>>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>>>>>> 
>>>>>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>>>>>> 
>>>>>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles
>>>>>>>>>>> Chanteperdrix:
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Stephan, Paul,
>>>>>>>>>>>> 
>>>>>>>>>>>> we have a problem with the patches for
>>>>>>>>>>>> Raspberry and BeagleBone: they are based on the
>>>>>>>>>>>> 3.2.21 patch, which we know is broken. So, we
>>>>>>>>>>>> can not really ship the next version of Xenomai
>>>>>>>>>>>> with these patches.
>>>>>>>>>>>> 
>>>>>>>>>>>> There are two ways we could keep patches for
>>>>>>>>>>>> these machines: - you could send patches for
>>>>>>>>>>>> 3.4 or 3.5, or even 3.8 - we could backport the
>>>>>>>>>>>> fixes to 3.2, but as already discussed on this
>>>>>>>>>>>> list, this would cost some time to re-validate
>>>>>>>>>>>> the 3.2 patch on all architectures. However, if
>>>>>>>>>>>> you do the backport, validate it on your side,
>>>>>>>>>>>> I could validate the result on my test boards, 
>>>>>>>>>>>> and we would release a new version of the patch
>>>>>>>>>>>> for 3.2 only for the ARM architecture.
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards.
>>>>>>>>>>>> 
>>>>>>>>>>>> -- Gilles.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi Gilles,
>>>>>>>>>>> 
>>>>>>>>>>> there's a 3.8.7 branch available for beagleBone
>>>>>>>>>>> at 
>>>>>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>>>>>> 
>>>>>>>>>>> I can look into updating the beagleBone patch for
>>>>>>>>>>> that repository. Where do I find the latest ipipe
>>>>>>>>>>> patch for 3.8 on ARM?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>>>>>> 
>>>>>>>>>> -- Gilles.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Gilles, do you have a script to create the ipipe
>>>>>>>>> patch file? Can't find any in the pipe-gch
>>>>>>>>> repository.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> It is not yet in the repository, if you want the
>>>>>>>> definitive patch, please wait a bit, the patch should
>>>>>>>> be released soon.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- Gilles.
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi Gilles,
>>>>>>> 
>>>>>>> I have created a ipipe post patch for the beagleBone
>>>>>>> kernel v3.8.10 found here:
>>>>>>> 
>>>>>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>>>>>>
>>>>>>> 


branch am33x-v3.8

>>>>>>> 
>>>>>>> Your pipe-gch repository is based on 3.8 while the upper 
>>>>>>> repository is at 3.8.10. Thus I had to apply a few minor
>>>>>>> changes to the patch file created from your git. Are you
>>>>>>> going to rebase the ipipe patch to 3.8.10 or higher
>>>>>>> before releasing it?
>>>>>> 
>>>>>> 
>>>>>> I do not know, Philippe is going to make the patch, he will
>>>>>> decide on which version he rebases.
>>>>>> 
>>>>>>> If so, the beagleBone patch gets reduced to the post
>>>>>>> patch below:
>>>>>> 
>>>>>> 
>>>>>> Ok, several remarks: - can not we put that code in the
>>>>>> mainline kernel (meaning, does soc_is_am33xx() exist in the
>>>>>> mainline kernel, if it does not exist, can not we add it?)
>>>>>> - the coding style for the tsc declaration is bad, braces
>>>>>> are not put on separate lines in the Linux kernel coding
>>>>>> style; - since the only difference between am33xx and other
>>>>>> omaps is OMAP_TIMER_CAPTURE_REG vs OMAP_TIMER_COUNTER_REG,
>>>>>> why not put this in a local variable and use it twice?
>>>>>> 
>>>>>> 
>>>>>> -- Gilles.
>>>>>> 
>>>>> 
>>>>> Yes, soc_is_am33xx() is indeed defined in the mainline
>>>>> kernel starting from 3.6. So the beagleBone patch can safely
>>>>> be put into the mainline ipipe sources.
>>>>> 
>>>>> I'll fix the coding style and send a new patch. Actually
>>>>> using soc_is_am33xx() for the TSC register location decision
>>>>> was an unnecessary constraint. The OMAP timer struct has a
>>>>> revision field that is 2 for the v2 timer IP. In rev 2, all
>>>>> functional registers are offset by
>>>>> OMAP_TIMER_V2_FUNC_OFFSET.
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> any news about this patch?
>>>> 
>>>> Regards.
>>>> 
>>>> -- Gilles.
>>>> 
>>> 
>>> Sorry for the delay, here it is. Tested against pipe-gch
>>> for-core-3.8. Xenomai is successfully starting on the
>>> beagleBone:
>> 
>> 
>> What version of Linux are you using, is this 3.8.0, or another
>> version as you told me in a previous mail?
>> 
>> -- Gilles.
>> 
> 
> I'm using your git repository directly. Applied my post.patch and
> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
> space compile was broken. Still working on fixing it.


What options did you pass to the configure script?


-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 10.05.2013 um 16:44 schrieb Gilles Chanteperdrix:

> On 05/10/2013 04:43 PM, Stephan Kappertz wrote:
> 
>> 
>> Am 10.05.2013 um 15:21 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/10/2013 01:53 PM, Stephan Kappertz wrote:
>>> 
>>>> Am 08.05.2013 um 20:27 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 05/03/2013 10:41 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>> 
>>>>>> Am 03.05.2013 um 20:19 schrieb Gilles Chanteperdrix:
>>>>>> 
>>>>>>> On 05/03/2013 04:28 PM, Stephan Kappertz wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> Am 02.05.2013 um 20:34 schrieb Gilles Chanteperdrix:
>>>>>>>> 
>>>>>>>>> On 05/02/2013 02:19 PM, Stephan Kappertz wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Am 16.04.2013 um 20:06 schrieb Gilles Chanteperdrix:
>>>>>>>>>> 
>>>>>>>>>>> On 04/16/2013 12:26 PM, Stephan Kappertz wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Am 15.04.2013 um 08:57 schrieb Gilles
>>>>>>>>>>>> Chanteperdrix:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Stephan, Paul,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> we have a problem with the patches for
>>>>>>>>>>>>> Raspberry and BeagleBone: they are based on the
>>>>>>>>>>>>> 3.2.21 patch, which we know is broken. So, we
>>>>>>>>>>>>> can not really ship the next version of Xenomai
>>>>>>>>>>>>> with these patches.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There are two ways we could keep patches for
>>>>>>>>>>>>> these machines: - you could send patches for
>>>>>>>>>>>>> 3.4 or 3.5, or even 3.8 - we could backport the
>>>>>>>>>>>>> fixes to 3.2, but as already discussed on this
>>>>>>>>>>>>> list, this would cost some time to re-validate
>>>>>>>>>>>>> the 3.2 patch on all architectures. However, if
>>>>>>>>>>>>> you do the backport, validate it on your side,
>>>>>>>>>>>>> I could validate the result on my test boards, 
>>>>>>>>>>>>> and we would release a new version of the patch
>>>>>>>>>>>>> for 3.2 only for the ARM architecture.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- Gilles.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Gilles,
>>>>>>>>>>>> 
>>>>>>>>>>>> there's a 3.8.7 branch available for beagleBone
>>>>>>>>>>>> at 
>>>>>>>>>>>> https://github.com/beagleboard/kernel/tree/3.8.
>>>>>>>>>>>> 
>>>>>>>>>>>> I can look into updating the beagleBone patch for
>>>>>>>>>>>> that repository. Where do I find the latest ipipe
>>>>>>>>>>>> patch for 3.8 on ARM?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ipipe-gch repository, for-core-3.8 branch.
>>>>>>>>>>> 
>>>>>>>>>>> -- Gilles.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Gilles, do you have a script to create the ipipe
>>>>>>>>>> patch file? Can't find any in the pipe-gch
>>>>>>>>>> repository.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> It is not yet in the repository, if you want the
>>>>>>>>> definitive patch, please wait a bit, the patch should
>>>>>>>>> be released soon.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- Gilles.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Gilles,
>>>>>>>> 
>>>>>>>> I have created a ipipe post patch for the beagleBone
>>>>>>>> kernel v3.8.10 found here:
>>>>>>>> 
>>>>>>>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.8,
>>>>>>>> 
>>>>>>>> 
> 
> 
> branch am33x-v3.8
> 
>>>>>>>> 
>>>>>>>> Your pipe-gch repository is based on 3.8 while the upper 
>>>>>>>> repository is at 3.8.10. Thus I had to apply a few minor
>>>>>>>> changes to the patch file created from your git. Are you
>>>>>>>> going to rebase the ipipe patch to 3.8.10 or higher
>>>>>>>> before releasing it?
>>>>>>> 
>>>>>>> 
>>>>>>> I do not know, Philippe is going to make the patch, he will
>>>>>>> decide on which version he rebases.
>>>>>>> 
>>>>>>>> If so, the beagleBone patch gets reduced to the post
>>>>>>>> patch below:
>>>>>>> 
>>>>>>> 
>>>>>>> Ok, several remarks: - can not we put that code in the
>>>>>>> mainline kernel (meaning, does soc_is_am33xx() exist in the
>>>>>>> mainline kernel, if it does not exist, can not we add it?)
>>>>>>> - the coding style for the tsc declaration is bad, braces
>>>>>>> are not put on separate lines in the Linux kernel coding
>>>>>>> style; - since the only difference between am33xx and other
>>>>>>> omaps is OMAP_TIMER_CAPTURE_REG vs OMAP_TIMER_COUNTER_REG,
>>>>>>> why not put this in a local variable and use it twice?
>>>>>>> 
>>>>>>> 
>>>>>>> -- Gilles.
>>>>>>> 
>>>>>> 
>>>>>> Yes, soc_is_am33xx() is indeed defined in the mainline
>>>>>> kernel starting from 3.6. So the beagleBone patch can safely
>>>>>> be put into the mainline ipipe sources.
>>>>>> 
>>>>>> I'll fix the coding style and send a new patch. Actually
>>>>>> using soc_is_am33xx() for the TSC register location decision
>>>>>> was an unnecessary constraint. The OMAP timer struct has a
>>>>>> revision field that is 2 for the v2 timer IP. In rev 2, all
>>>>>> functional registers are offset by
>>>>>> OMAP_TIMER_V2_FUNC_OFFSET.
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> any news about this patch?
>>>>> 
>>>>> Regards.
>>>>> 
>>>>> -- Gilles.
>>>>> 
>>>> 
>>>> Sorry for the delay, here it is. Tested against pipe-gch
>>>> for-core-3.8. Xenomai is successfully starting on the
>>>> beagleBone:
>>> 
>>> 
>>> What version of Linux are you using, is this 3.8.0, or another
>>> version as you told me in a previous mail?
>>> 
>>> -- Gilles.
>>> 
>> 
>> I'm using your git repository directly. Applied my post.patch and
>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>> space compile was broken. Still working on fixing it.
> 
> 
> What options did you pass to the configure script?
> 
> 
> -- 
>                                                                Gilles.
> 

../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/

This is a buildroot build.

- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/10/2013 06:40 PM, Stephan Kappertz wrote:

>>>>
>>>
>>> I'm using your git repository directly. Applied my post.patch and
>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>> space compile was broken. Still working on fixing it.
>>
>>
>> What options did you pass to the configure script?
>>
>>
>> -- 
>>                                                                Gilles.
>>
> 
> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
> 
> This is a buildroot build.


Could you:
- tell me what version of gcc, binutils, etc... you use?
- show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
- instrument the function xeno_sigill_handler in
src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
- send me (privately) your kernel configuration?

Thanks in advance.
Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:

> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
> 
>>>>>
>>>>
>>>> I'm using your git repository directly. Applied my post.patch and
>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>> space compile was broken. Still working on fixing it.
>>>
>>>
>>> What options did you pass to the configure script?
>>>
>>>
>>> -- 
>>>                                                                Gilles.
>>>
>>
>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>
>> This is a buildroot build.
> 
> 
> Could you:
> - tell me what version of gcc, binutils, etc... you use?
> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
> - instrument the function xeno_sigill_handler in
> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?


Sorry, you do not take the SIGILL handler, please instrument
xeno_bind_skin_opt to print the value of "muxid" returned by the
XENOMAI_SYSBIND system call.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:

> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
> 
>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>> 
>>>>>> 
>>>>> 
>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>> space compile was broken. Still working on fixing it.
>>>> 
>>>> 
>>>> What options did you pass to the configure script?
>>>> 
>>>> 
>>>> -- 
>>>>                                                               Gilles.
>>>> 
>>> 
>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>> 
>>> This is a buildroot build.
>> 
>> 
>> Could you:
>> - tell me what version of gcc, binutils, etc... you use?
>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>> - instrument the function xeno_sigill_handler in
>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
> 
> 
> Sorry, you do not take the SIGILL handler, please instrument
> xeno_bind_skin_opt to print the value of "muxid" returned by the
> XENOMAI_SYSBIND system call.
> 
> -- 
>                                                                Gilles.
> 


Ok, here's the compiler spec:

$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

Binutils are 2.22:

arm-linux-gnueabi-as -v
GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22


Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.

If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.

Do you still want to see the disassembly?

-- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:

> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
> 
>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>> 
>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>> 
>>>>>>> 
>>>>>> 
>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>> space compile was broken. Still working on fixing it.
>>>>> 
>>>>> 
>>>>> What options did you pass to the configure script?
>>>>> 
>>>>> 
>>>>> -- 
>>>>>                                                              Gilles.
>>>>> 
>>>> 
>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>> 
>>>> This is a buildroot build.
>>> 
>>> 
>>> Could you:
>>> - tell me what version of gcc, binutils, etc... you use?
>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>> - instrument the function xeno_sigill_handler in
>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>> 
>> 
>> Sorry, you do not take the SIGILL handler, please instrument
>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>> XENOMAI_SYSBIND system call.
>> 
>> -- 
>>                                                               Gilles.
>> 
> 
> 
> Ok, here's the compiler spec:
> 
> $ arm-linux-gnueabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-linux-gnueabi-gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
> Target: arm-linux-gnueabi
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> 
> Binutils are 2.22:
> 
> arm-linux-gnueabi-as -v
> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
> 
> 
> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
> 
> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
> 
> Do you still want to see the disassembly?
> 
> -- Stephan
> 

Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:

$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
Target: arm-buildroot-linux-uclibcgnueabi
Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
Thread model: posix
gcc version 4.6.3 (Buildroot 2013.02) 

/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1

-- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/13/2013 12:37 PM, Stephan Kappertz wrote:

> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
> 
>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>> 
>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>> 
>>>>>>> 
>>>>>> 
>>>>>> I'm using your git repository directly. Applied my
>>>>>> post.patch and compiled the kernel. So this is 3.8.0. Looks
>>>>>> like my Xenomai user space compile was broken. Still
>>>>>> working on fixing it.
>>>>> 
>>>>> 
>>>>> What options did you pass to the configure script?
>>>>> 
>>>>> 
>>>>> -- Gilles.
>>>>> 
>>>> 
>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi
>>>> --host=arm-buildroot-linux-uclibcgnueabi
>>>> --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr
>>>> --sysconfdir=/etc --program-prefix="" --enable-static
>>>> --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3"
>>>> LDFLAGS="-march=armv7-a -mfpu=vfp3"
>>>> --includedir=/usr/include/xenomai/
>>>> 
>>>> This is a buildroot build.
>>> 
>>> 
>>> Could you: - tell me what version of gcc, binutils, etc... you
>>> use? - show me a disassembly of the xeno_bind_skip_opt function
>>> in libxenomai.so? - instrument the function xeno_sigill_handler
>>> in src/skins/common/bind.c to see if you are indeed taking the
>>> SIGILL signal?
>> 
>> 
>> Sorry, you do not take the SIGILL handler, please instrument 
>> xeno_bind_skin_opt to print the value of "muxid" returned by the 
>> XENOMAI_SYSBIND system call.
>> 
>> -- Gilles.
>> 
> 
> 
> Ok, here's the compiler spec:
> 
> $ arm-linux-gnueabi-gcc -v Using built-in specs. 
> COLLECT_GCC=arm-linux-gnueabi-gcc 
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper 
> Target: arm-linux-gnueabi Configured with: ../src/configure -v
> --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5'
> --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix
> --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --enable-gnu-unique-object --enable-plugin --enable-objc-gc
> --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a
> --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
> --disable-werror --enable-checking=release --build=i686-linux-gnu
> --host=i686-linux-gnu --target=arm-linux-gnueabi
> --program-prefix=arm-linux-gnueabi-
> --includedir=/usr/arm-linux-gnueabi/include
> --with-headers=/usr/arm-linux-gnueabi/include
> --with-libs=/usr/arm-linux-gnueabi/lib Thread model: posix gcc
> version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> 
> Binutils are 2.22:
> 
> arm-linux-gnueabi-as -v GNU assembler version 2.22
> (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
> 
> 
> Now what's interesting is: as soon as I am adding an instrumentation
> "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);"
> to "static inline int xeno_bind_skin(unsigned skin_magic, const char
> *skin, const char *module)", binding succeeds and all xeno-test pass.
> The other option to get it work was:  declaring "int
> xeno_bind_skin(unsigned skin_magic, const char *skin, const char
> *module);" in bind.h and defining it in bind.c.
> 
> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never
> gets called in the original code.
> 
> Do you still want to see the disassembly?


Are you using a dynamic or static build of xenomai? If dynamic, could
you put
libxenomai.so and libnative.so somewhere where I could download them? If
static, could you make "arith" somewhere where I could download it?

Also, I am interested in your kernel configuration.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/13/2013 12:37 PM, Stephan Kappertz wrote:

> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
> 
>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>
>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>
>>>>>>>
>>>>>>
>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>> space compile was broken. Still working on fixing it.
>>>>>
>>>>>
>>>>> What options did you pass to the configure script?
>>>>>
>>>>>
>>>>> -- 
>>>>>                                                               Gilles.
>>>>>
>>>>
>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>
>>>> This is a buildroot build.
>>>
>>>
>>> Could you:
>>> - tell me what version of gcc, binutils, etc... you use?
>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>> - instrument the function xeno_sigill_handler in
>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>
>>
>> Sorry, you do not take the SIGILL handler, please instrument
>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>> XENOMAI_SYSBIND system call.
>>
>> -- 
>>                                                                Gilles.
>>
> 
> 
> Ok, here's the compiler spec:
> 
> $ arm-linux-gnueabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-linux-gnueabi-gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
> Target: arm-linux-gnueabi
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib

> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> 
> Binutils are 2.22:
> 
> arm-linux-gnueabi-as -v
> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
> 
> 
> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
> 
> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.


That looks impossible, have you tried putting a printf at the very
beginning of xeno_bind_skin_opt? I can not seem to find the function
__init_xeno_interface in libnative.so.3.0.0, do you see it with the
version of objdump you use?

This all screams for a bug in the syscall assembly, but if
xeno_bind_skin_opt gets magically inlined in libnative.so.3.0.0, we need
to find the inlined version to find the assembly bug.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/13/2013 01:52 PM, Gilles Chanteperdrix wrote:

> On 05/13/2013 12:37 PM, Stephan Kappertz wrote:
> 
>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>
>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>
>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>
>>>>>>
>>>>>> What options did you pass to the configure script?
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>                                                               Gilles.
>>>>>>
>>>>>
>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>
>>>>> This is a buildroot build.
>>>>
>>>>
>>>> Could you:
>>>> - tell me what version of gcc, binutils, etc... you use?
>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>> - instrument the function xeno_sigill_handler in
>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>
>>>
>>> Sorry, you do not take the SIGILL handler, please instrument
>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>> XENOMAI_SYSBIND system call.
>>>
>>> -- 
>>>                                                                Gilles.
>>>
>>
>>
>> Ok, here's the compiler spec:
>>
>> $ arm-linux-gnueabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=arm-linux-gnueabi-gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>> Target: arm-linux-gnueabi
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib

> 
>> Thread model: posix
>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>
>> Binutils are 2.22:
>>
>> arm-linux-gnueabi-as -v
>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>
>>
>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>
>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
> 
> 
> That looks impossible, have you tried putting a printf at the very
> beginning of xeno_bind_skin_opt? I can not seem to find the function
> __init_xeno_interface in libnative.so.3.0.0, do you see it with the
> version of objdump you use?
> 
> This all screams for a bug in the syscall assembly, but if
> xeno_bind_skin_opt gets magically inlined in libnative.so.3.0.0, we need
> to find the inlined version to find the assembly bug.
> 

Have the binaries you sent me been stripped by any chance? Could you
send me the unstripped versions? If possible even compiled with -g?

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/13/2013 01:20 PM, Stephan Kappertz wrote:

> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
> 
>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>
>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>
>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>
>>>>>>
>>>>>> What options did you pass to the configure script?
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>                                                              Gilles.
>>>>>>
>>>>>
>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>
>>>>> This is a buildroot build.
>>>>
>>>>
>>>> Could you:
>>>> - tell me what version of gcc, binutils, etc... you use?
>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>> - instrument the function xeno_sigill_handler in
>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>
>>>
>>> Sorry, you do not take the SIGILL handler, please instrument
>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>> XENOMAI_SYSBIND system call.
>>>
>>> -- 
>>>                                                               Gilles.
>>>
>>
>>
>> Ok, here's the compiler spec:
>>
>> $ arm-linux-gnueabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=arm-linux-gnueabi-gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>> Target: arm-linux-gnueabi
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib

>> Thread model: posix
>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>
>> Binutils are 2.22:
>>
>> arm-linux-gnueabi-as -v
>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>
>>
>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>
>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>
>> Do you still want to see the disassembly?
>>
>> -- Stephan
>>
> 
> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
> 
> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
> Target: arm-buildroot-linux-uclibcgnueabi
> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.ws
.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
> Thread model: posix
> gcc version 4.6.3 (Buildroot 2013.02) 
> 
> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1


Hi Stefan,

I have no other explanation than that the combination of the toolchain
you use with Xenomai code you use produces broken code.

The version of libnative.so generated with a similar toolchain
(codesourcery 2012.03) has three pointers in its .init_array section,
these are the pointers to the functions which are invoked upon library
startup:
frame_dummy
__init_xeno_interface
__init_native_tskey

The version of libnative.so you sent me has four pointers in its
.init_array section:
0x2458
0x2254
0x22b8
0x2308

I do not have the function names, I believe, because the binary you sent
me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
looks like __init_native_tskey, and 0x22b8 has the following disassembly:

    22b8:	e92d4008 	push	{r3, lr}
    22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
    22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
    22c4:	e08f3003 	add	r3, pc, r3
    22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
    22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
    22d0:	e7930000 	ldr	r0, [r3, r0]
    22d4:	e08f1001 	add	r1, pc, r1
    22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
    22dc:	e08f2002 	add	r2, pc, r2
    22e0:	e08f3003 	add	r3, pc, r3
    22e4:	e5900000 	ldr	r0, [r0]
    22e8:	ebffff5f 	bl	206c <fprintf@plt>
    22ec:	e3a00001 	mov	r0, #1
    22f0:	ebffff99 	bl	215c <exit@plt>

Which means that it calls directly fprintf and exit, without even
calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
__init_xeno_interface, assuming xeno_bind_skin_opt always return -1.

So, questions now:
- what commit in xenomai git are you using?
- could you try another toolchain ?

Regards.
-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/14/2013 08:41 AM, Gilles Chanteperdrix wrote:

> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
> 
>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>
>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>
>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>
>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>
>>>>>>>
>>>>>>> What options did you pass to the configure script?
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>>                                                              Gilles.
>>>>>>>
>>>>>>
>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>
>>>>>> This is a buildroot build.
>>>>>
>>>>>
>>>>> Could you:
>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>> - instrument the function xeno_sigill_handler in
>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>
>>>>
>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>> XENOMAI_SYSBIND system call.
>>>>
>>>> -- 
>>>>                                                               Gilles.
>>>>
>>>
>>>
>>> Ok, here's the compiler spec:
>>>
>>> $ arm-linux-gnueabi-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>> Target: arm-linux-gnueabi
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/li
b
> 
>>> Thread model: posix
>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>
>>> Binutils are 2.22:
>>>
>>> arm-linux-gnueabi-as -v
>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>
>>>
>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>
>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>
>>> Do you still want to see the disassembly?
>>>
>>> -- Stephan
>>>
>>
>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>
>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>> Target: arm-buildroot-linux-uclibcgnueabi
>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.w
s
> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>> Thread model: posix
>> gcc version 4.6.3 (Buildroot 2013.02) 
>>
>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
> 
> 
> Hi Stefan,
> 
> I have no other explanation than that the combination of the toolchain
> you use with Xenomai code you use produces broken code.
> 
> The version of libnative.so generated with a similar toolchain
> (codesourcery 2012.03) has three pointers in its .init_array section,
> these are the pointers to the functions which are invoked upon library
> startup:
> frame_dummy
> __init_xeno_interface
> __init_native_tskey
> 
> The version of libnative.so you sent me has four pointers in its
> .init_array section:
> 0x2458
> 0x2254
> 0x22b8
> 0x2308
> 
> I do not have the function names, I believe, because the binary you sent
> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
> 
>     22b8:	e92d4008 	push	{r3, lr}
>     22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>     22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>     22c4:	e08f3003 	add	r3, pc, r3
>     22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>     22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>     22d0:	e7930000 	ldr	r0, [r3, r0]
>     22d4:	e08f1001 	add	r1, pc, r1
>     22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>     22dc:	e08f2002 	add	r2, pc, r2
>     22e0:	e08f3003 	add	r3, pc, r3
>     22e4:	e5900000 	ldr	r0, [r0]
>     22e8:	ebffff5f 	bl	206c <fprintf@plt>
>     22ec:	e3a00001 	mov	r0, #1
>     22f0:	ebffff99 	bl	215c <exit@plt>
> 
> Which means that it calls directly fprintf and exit, without even
> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
> 
> So, questions now:
> - what commit in xenomai git are you using?
> - could you try another toolchain ?


Do you have the compilation logs so that we can see which flags exactly
are passed to gcc when compiling and linking libnative.so?

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:

> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
> 
>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>> 
>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>> 
>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>> 
>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>> 
>>>>>>> 
>>>>>>> What options did you pass to the configure script?
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>>                                                             Gilles.
>>>>>>> 
>>>>>> 
>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>> 
>>>>>> This is a buildroot build.
>>>>> 
>>>>> 
>>>>> Could you:
>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>> - instrument the function xeno_sigill_handler in
>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>> 
>>>> 
>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>> XENOMAI_SYSBIND system call.
>>>> 
>>>> -- 
>>>>                                                              Gilles.
>>>> 
>>> 
>>> 
>>> Ok, here's the compiler spec:
>>> 
>>> $ arm-linux-gnueabi-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>> Target: arm-linux-gnueabi
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
> 
>>> Thread model: posix
>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>> 
>>> Binutils are 2.22:
>>> 
>>> arm-linux-gnueabi-as -v
>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>> 
>>> 
>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>> 
>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>> 
>>> Do you still want to see the disassembly?
>>> 
>>> -- Stephan
>>> 
>> 
>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>> 
>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>> Target: arm-buildroot-linux-uclibcgnueabi
>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.ws
> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>> Thread model: posix
>> gcc version 4.6.3 (Buildroot 2013.02) 
>> 
>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
> 
> 
> Hi Stefan,
> 
> I have no other explanation than that the combination of the toolchain
> you use with Xenomai code you use produces broken code.
> 
> The version of libnative.so generated with a similar toolchain
> (codesourcery 2012.03) has three pointers in its .init_array section,
> these are the pointers to the functions which are invoked upon library
> startup:
> frame_dummy
> __init_xeno_interface
> __init_native_tskey
> 
> The version of libnative.so you sent me has four pointers in its
> .init_array section:
> 0x2458
> 0x2254
> 0x22b8
> 0x2308
> 
> I do not have the function names, I believe, because the binary you sent
> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
> 
>    22b8:	e92d4008 	push	{r3, lr}
>    22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>    22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>    22c4:	e08f3003 	add	r3, pc, r3
>    22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>    22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>    22d0:	e7930000 	ldr	r0, [r3, r0]
>    22d4:	e08f1001 	add	r1, pc, r1
>    22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>    22dc:	e08f2002 	add	r2, pc, r2
>    22e0:	e08f3003 	add	r3, pc, r3
>    22e4:	e5900000 	ldr	r0, [r0]
>    22e8:	ebffff5f 	bl	206c <fprintf@plt>
>    22ec:	e3a00001 	mov	r0, #1
>    22f0:	ebffff99 	bl	215c <exit@plt>
> 
> Which means that it calls directly fprintf and exit, without even
> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
> 
> So, questions now:
> - what commit in xenomai git are you using?
> - could you try another toolchain ?
> 
> Regards.
> -- 
>                                                                Gilles.
> 

Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.

I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:

commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Date:   Fri May 10 15:27:38 2013 +0200

    native: avoid calling copy_from_user with hard irqs off

I also tried 2.6.2.1 release and that version does work (compile) correctly.

GCC flags are:

arm-buildroot-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I../../../../src/include   -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../../../include  -g -march=armv7-a -mfpu=vfp3 -MT 

-- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/14/2013 09:33 AM, Stephan Kappertz wrote:

> 
> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
> 
>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>
>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>
>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>
>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>
>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>
>>>>>>>>
>>>>>>>> What options did you pass to the configure script?
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>>                                                             Gilles.
>>>>>>>>
>>>>>>>
>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>
>>>>>>> This is a buildroot build.
>>>>>>
>>>>>>
>>>>>> Could you:
>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>> - instrument the function xeno_sigill_handler in
>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>
>>>>>
>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>> XENOMAI_SYSBIND system call.
>>>>>
>>>>> -- 
>>>>>                                                              Gilles.
>>>>>
>>>>
>>>>
>>>> Ok, here's the compiler spec:
>>>>
>>>> $ arm-linux-gnueabi-gcc -v
>>>> Using built-in specs.
>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>> Target: arm-linux-gnueabi
>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
ib
>>
>>>> Thread model: posix
>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>
>>>> Binutils are 2.22:
>>>>
>>>> arm-linux-gnueabi-as -v
>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>
>>>>
>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>
>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>
>>>> Do you still want to see the disassembly?
>>>>
>>>> -- Stephan
>>>>
>>>
>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>
>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>> Target: arm-buildroot-linux-uclibcgnueabi
>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
ws
>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>> Thread model: posix
>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>
>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>
>>
>> Hi Stefan,
>>
>> I have no other explanation than that the combination of the toolchain
>> you use with Xenomai code you use produces broken code.
>>
>> The version of libnative.so generated with a similar toolchain
>> (codesourcery 2012.03) has three pointers in its .init_array section,
>> these are the pointers to the functions which are invoked upon library
>> startup:
>> frame_dummy
>> __init_xeno_interface
>> __init_native_tskey
>>
>> The version of libnative.so you sent me has four pointers in its
>> .init_array section:
>> 0x2458
>> 0x2254
>> 0x22b8
>> 0x2308
>>
>> I do not have the function names, I believe, because the binary you sent
>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>
>>    22b8:	e92d4008 	push	{r3, lr}
>>    22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>    22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>    22c4:	e08f3003 	add	r3, pc, r3
>>    22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>    22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>    22d0:	e7930000 	ldr	r0, [r3, r0]
>>    22d4:	e08f1001 	add	r1, pc, r1
>>    22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>    22dc:	e08f2002 	add	r2, pc, r2
>>    22e0:	e08f3003 	add	r3, pc, r3
>>    22e4:	e5900000 	ldr	r0, [r0]
>>    22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>    22ec:	e3a00001 	mov	r0, #1
>>    22f0:	ebffff99 	bl	215c <exit@plt>
>>
>> Which means that it calls directly fprintf and exit, without even
>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>
>> So, questions now:
>> - what commit in xenomai git are you using?
>> - could you try another toolchain ?
>>
>> Regards.
>> -- 
>>                                                                Gilles.
>>
> 
> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
> 
> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
> 
> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Date:   Fri May 10 15:27:38 2013 +0200
> 
>     native: avoid calling copy_from_user with hard irqs off
> 
> I also tried 2.6.2.1 release and that version does work (compile) correctly.


Could you try git bisect to see which commit causes it?

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:

> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
> 
>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>> 
>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>> 
>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>> 
>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>> 
>>>>>>> 
>>>>>>> What options did you pass to the configure script?
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>>                                                             Gilles.
>>>>>>> 
>>>>>> 
>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>> 
>>>>>> This is a buildroot build.
>>>>> 
>>>>> 
>>>>> Could you:
>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>> - instrument the function xeno_sigill_handler in
>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>> 
>>>> 
>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>> XENOMAI_SYSBIND system call.
>>>> 
>>>> -- 
>>>>                                                              Gilles.
>>>> 
>>> 
>>> 
>>> Ok, here's the compiler spec:
>>> 
>>> $ arm-linux-gnueabi-gcc -v
>>> Using built-in specs.
>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>> Target: arm-linux-gnueabi
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
> 
>>> Thread model: posix
>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>> 
>>> Binutils are 2.22:
>>> 
>>> arm-linux-gnueabi-as -v
>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>> 
>>> 
>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>> 
>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>> 
>>> Do you still want to see the disassembly?
>>> 
>>> -- Stephan
>>> 
>> 
>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>> 
>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>> Target: arm-buildroot-linux-uclibcgnueabi
>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.ws
> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>> Thread model: posix
>> gcc version 4.6.3 (Buildroot 2013.02) 
>> 
>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
> 
> 
> Hi Stefan,
> 
> I have no other explanation than that the combination of the toolchain
> you use with Xenomai code you use produces broken code.
> 
> The version of libnative.so generated with a similar toolchain
> (codesourcery 2012.03) has three pointers in its .init_array section,
> these are the pointers to the functions which are invoked upon library
> startup:
> frame_dummy
> __init_xeno_interface
> __init_native_tskey
> 
> The version of libnative.so you sent me has four pointers in its
> .init_array section:
> 0x2458
> 0x2254
> 0x22b8
> 0x2308
> 
> I do not have the function names, I believe, because the binary you sent
> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
> 
>    22b8:	e92d4008 	push	{r3, lr}
>    22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>    22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>    22c4:	e08f3003 	add	r3, pc, r3
>    22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>    22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>    22d0:	e7930000 	ldr	r0, [r3, r0]
>    22d4:	e08f1001 	add	r1, pc, r1
>    22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>    22dc:	e08f2002 	add	r2, pc, r2
>    22e0:	e08f3003 	add	r3, pc, r3
>    22e4:	e5900000 	ldr	r0, [r0]
>    22e8:	ebffff5f 	bl	206c <fprintf@plt>
>    22ec:	e3a00001 	mov	r0, #1
>    22f0:	ebffff99 	bl	215c <exit@plt>
> 
> Which means that it calls directly fprintf and exit, without even
> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
> 
> So, questions now:
> - what commit in xenomai git are you using?
> - could you try another toolchain ?
> 
> Regards.
> -- 
>                                                                Gilles.
> 

Recompiled Xenomai with gcc 4.7.2, binutils 2.22: binding and xeno-test both succeed. Next: bisecting with 4.6.3

$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.7.2/lto-wrapper
Target: arm-buildroot-linux-uclibcgnueabi
Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.7.2/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
Thread model: posix
gcc version 4.7.2 (Buildroot 2013.02) 

-- Stephan
 

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:

> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
> 
>> 
>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>> 
>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>> 
>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>> 
>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>> 
>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>>                                                            Gilles.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>> 
>>>>>>>> This is a buildroot build.
>>>>>>> 
>>>>>>> 
>>>>>>> Could you:
>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>> 
>>>>>> 
>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>> XENOMAI_SYSBIND system call.
>>>>>> 
>>>>>> -- 
>>>>>>                                                             Gilles.
>>>>>> 
>>>>> 
>>>>> 
>>>>> Ok, here's the compiler spec:
>>>>> 
>>>>> $ arm-linux-gnueabi-gcc -v
>>>>> Using built-in specs.
>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>> Target: arm-linux-gnueabi
>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
> ib
>>> 
>>>>> Thread model: posix
>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>> 
>>>>> Binutils are 2.22:
>>>>> 
>>>>> arm-linux-gnueabi-as -v
>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>> 
>>>>> 
>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>> 
>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>> 
>>>>> Do you still want to see the disassembly?
>>>>> 
>>>>> -- Stephan
>>>>> 
>>>> 
>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>> 
>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>> Using built-in specs.
>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
> ws
>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>> Thread model: posix
>>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>> 
>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>> 
>>> 
>>> Hi Stefan,
>>> 
>>> I have no other explanation than that the combination of the toolchain
>>> you use with Xenomai code you use produces broken code.
>>> 
>>> The version of libnative.so generated with a similar toolchain
>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>> these are the pointers to the functions which are invoked upon library
>>> startup:
>>> frame_dummy
>>> __init_xeno_interface
>>> __init_native_tskey
>>> 
>>> The version of libnative.so you sent me has four pointers in its
>>> .init_array section:
>>> 0x2458
>>> 0x2254
>>> 0x22b8
>>> 0x2308
>>> 
>>> I do not have the function names, I believe, because the binary you sent
>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>> 
>>>   22b8:	e92d4008 	push	{r3, lr}
>>>   22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>>   22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>>   22c4:	e08f3003 	add	r3, pc, r3
>>>   22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>>   22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>>   22d0:	e7930000 	ldr	r0, [r3, r0]
>>>   22d4:	e08f1001 	add	r1, pc, r1
>>>   22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>>   22dc:	e08f2002 	add	r2, pc, r2
>>>   22e0:	e08f3003 	add	r3, pc, r3
>>>   22e4:	e5900000 	ldr	r0, [r0]
>>>   22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>>   22ec:	e3a00001 	mov	r0, #1
>>>   22f0:	ebffff99 	bl	215c <exit@plt>
>>> 
>>> Which means that it calls directly fprintf and exit, without even
>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>> 
>>> So, questions now:
>>> - what commit in xenomai git are you using?
>>> - could you try another toolchain ?
>>> 
>>> Regards.
>>> -- 
>>>                                                               Gilles.
>>> 
>> 
>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>> 
>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>> 
>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>> Date:   Fri May 10 15:27:38 2013 +0200
>> 
>>    native: avoid calling copy_from_user with hard irqs off
>> 
>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
> 
> 
> Could you try git bisect to see which commit causes it?
> 
> -- 
>                                                                Gilles.
> 

Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:

a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Apr 23 14:32:01 2013 +0200

    Remove mlockall alert handler
    
    The probability of such errors is negligible now because we lock
    unconditionally. So we can remove the machinery that used to report such
    bugs to the user. The nucleus will still raise a signal if userspace
    willingly unlocked the memory - it will get what it deserves (an
    untranslated signal).
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

:040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M	include
:040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M	src

Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka]

On 2013-05-14 11:11, Stephan Kappertz wrote:
> 
> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
> 
>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>
>>>
>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>
>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>
>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>
>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>
>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>
>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>>                                                            Gilles.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>
>>>>>>>>> This is a buildroot build.
>>>>>>>>
>>>>>>>>
>>>>>>>> Could you:
>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>
>>>>>>>
>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>
>>>>>>> -- 
>>>>>>>                                                             Gilles.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Ok, here's the compiler spec:
>>>>>>
>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>> Using built-in specs.
>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>> Target: arm-linux-gnueabi
>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>  u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>> ib
>>>>
>>>>>> Thread model: posix
>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>
>>>>>> Binutils are 2.22:
>>>>>>
>>>>>> arm-linux-gnueabi-as -v
>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>
>>>>>>
>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>
>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>
>>>>>> Do you still want to see the disassembly?
>>>>>>
>>>>>> -- Stephan
>>>>>>
>>>>>
>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>
>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>> Using built-in specs.
>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>  n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>> ws
>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>> Thread model: posix
>>>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>>>
>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>
>>>>
>>>> Hi Stefan,
>>>>
>>>> I have no other explanation than that the combination of the toolchain
>>>> you use with Xenomai code you use produces broken code.
>>>>
>>>> The version of libnative.so generated with a similar toolchain
>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>> these are the pointers to the functions which are invoked upon library
>>>> startup:
>>>> frame_dummy
>>>> __init_xeno_interface
>>>> __init_native_tskey
>>>>
>>>> The version of libnative.so you sent me has four pointers in its
>>>> .init_array section:
>>>> 0x2458
>>>> 0x2254
>>>> 0x22b8
>>>> 0x2308
>>>>
>>>> I do not have the function names, I believe, because the binary you sent
>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>
>>>>   22b8:	e92d4008 	push	{r3, lr}
>>>>   22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>>>   22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>>>   22c4:	e08f3003 	add	r3, pc, r3
>>>>   22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>>>   22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>>>   22d0:	e7930000 	ldr	r0, [r3, r0]
>>>>   22d4:	e08f1001 	add	r1, pc, r1
>>>>   22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>>>   22dc:	e08f2002 	add	r2, pc, r2
>>>>   22e0:	e08f3003 	add	r3, pc, r3
>>>>   22e4:	e5900000 	ldr	r0, [r0]
>>>>   22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>>>   22ec:	e3a00001 	mov	r0, #1
>>>>   22f0:	ebffff99 	bl	215c <exit@plt>
>>>>
>>>> Which means that it calls directly fprintf and exit, without even
>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>
>>>> So, questions now:
>>>> - what commit in xenomai git are you using?
>>>> - could you try another toolchain ?
>>>>
>>>> Regards.
>>>> -- 
>>>>                                                               Gilles.
>>>>
>>>
>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>
>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>
>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>
>>>    native: avoid calling copy_from_user with hard irqs off
>>>
>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>
>>
>> Could you try git bisect to see which commit causes it?
>>
>> -- 
>>                                                                Gilles.
>>
> 
> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
> 
> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Tue Apr 23 14:32:01 2013 +0200
> 
>     Remove mlockall alert handler
>     
>     The probability of such errors is negligible now because we lock
>     unconditionally. So we can remove the machinery that used to report such
>     bugs to the user. The nucleus will still raise a signal if userspace
>     willingly unlocked the memory - it will get what it deserves (an
>     untranslated signal).
>     
>     Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M	include
> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M	src
> 

Oh, you ran into an ugly gcc bug that won't be fixed for that version
anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 

We just started carrying this workaround locally, still undecided what
to do upstream.


native: Work around gcc-2.6

This avoid that gcc bug 56712 lets the initialization of the native skin
fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
background. Affects in particular Ubuntu 12.4 LTS.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 src/skins/native/init.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/skins/native/init.c b/src/skins/native/init.c
index e380ca6..8e77e1c 100644
--- a/src/skins/native/init.c
+++ b/src/skins/native/init.c
@@ -50,8 +50,7 @@ void __init_native_tskey(void)
 }
 #endif /* !HAVE___THREAD */
 
-static __attribute__ ((constructor))
-void __init_xeno_interface(void)
+static void __init_xeno_interface(void)
 {
 	int err;
 
@@ -71,3 +70,8 @@ void __init_xeno_interface(void)
 	}
 	fork_handler_registered = 1;
 }
+
+static __attribute__ ((constructor)) void __init_wrapper(void)
+{
+	__init_xeno_interface();
+}


Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 11:20 schrieb Jan Kiszka:

> On 2013-05-14 11:11, Stephan Kappertz wrote:
>> 
>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>> 
>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>> 
>>>> 
>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>> 
>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>> 
>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>> 
>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>> 
>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>> 
>>>>>>>>>> This is a buildroot build.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Could you:
>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>>                                                            Gilles.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Ok, here's the compiler spec:
>>>>>>> 
>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>> Using built-in specs.
>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>> Target: arm-linux-gnueabi
>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>> ib
>>>>> 
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>> 
>>>>>>> Binutils are 2.22:
>>>>>>> 
>>>>>>> arm-linux-gnueabi-as -v
>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>> 
>>>>>>> 
>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>> 
>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>> 
>>>>>>> Do you still want to see the disassembly?
>>>>>>> 
>>>>>>> -- Stephan
>>>>>>> 
>>>>>> 
>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>> 
>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>> Using built-in specs.
>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>> ws
>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>> Thread model: posix
>>>>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>>>> 
>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>> 
>>>>> 
>>>>> Hi Stefan,
>>>>> 
>>>>> I have no other explanation than that the combination of the toolchain
>>>>> you use with Xenomai code you use produces broken code.
>>>>> 
>>>>> The version of libnative.so generated with a similar toolchain
>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>> these are the pointers to the functions which are invoked upon library
>>>>> startup:
>>>>> frame_dummy
>>>>> __init_xeno_interface
>>>>> __init_native_tskey
>>>>> 
>>>>> The version of libnative.so you sent me has four pointers in its
>>>>> .init_array section:
>>>>> 0x2458
>>>>> 0x2254
>>>>> 0x22b8
>>>>> 0x2308
>>>>> 
>>>>> I do not have the function names, I believe, because the binary you sent
>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>> 
>>>>>  22b8:	e92d4008 	push	{r3, lr}
>>>>>  22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>>>>  22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>>>>  22c4:	e08f3003 	add	r3, pc, r3
>>>>>  22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>>>>  22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>>>>  22d0:	e7930000 	ldr	r0, [r3, r0]
>>>>>  22d4:	e08f1001 	add	r1, pc, r1
>>>>>  22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>>>>  22dc:	e08f2002 	add	r2, pc, r2
>>>>>  22e0:	e08f3003 	add	r3, pc, r3
>>>>>  22e4:	e5900000 	ldr	r0, [r0]
>>>>>  22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>>>>  22ec:	e3a00001 	mov	r0, #1
>>>>>  22f0:	ebffff99 	bl	215c <exit@plt>
>>>>> 
>>>>> Which means that it calls directly fprintf and exit, without even
>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>> 
>>>>> So, questions now:
>>>>> - what commit in xenomai git are you using?
>>>>> - could you try another toolchain ?
>>>>> 
>>>>> Regards.
>>>>> -- 
>>>>>                                                              Gilles.
>>>>> 
>>>> 
>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>> 
>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>> 
>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>> 
>>>>   native: avoid calling copy_from_user with hard irqs off
>>>> 
>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>> 
>>> 
>>> Could you try git bisect to see which commit causes it?
>>> 
>>> -- 
>>>                                                               Gilles.
>>> 
>> 
>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>> 
>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>> Date:   Tue Apr 23 14:32:01 2013 +0200
>> 
>>    Remove mlockall alert handler
>> 
>>    The probability of such errors is negligible now because we lock
>>    unconditionally. So we can remove the machinery that used to report such
>>    bugs to the user. The nucleus will still raise a signal if userspace
>>    willingly unlocked the memory - it will get what it deserves (an
>>    untranslated signal).
>> 
>>    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> 
>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M	include
>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M	src
>> 
> 
> Oh, you ran into an ugly gcc bug that won't be fixed for that version
> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 
> 
> We just started carrying this workaround locally, still undecided what
> to do upstream.
> 
> 
> native: Work around gcc-2.6
> 
> This avoid that gcc bug 56712 lets the initialization of the native skin
> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
> background. Affects in particular Ubuntu 12.4 LTS.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> src/skins/native/init.c |    8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
> index e380ca6..8e77e1c 100644
> --- a/src/skins/native/init.c
> +++ b/src/skins/native/init.c
> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
> }
> #endif /* !HAVE___THREAD */
> 
> -static __attribute__ ((constructor))
> -void __init_xeno_interface(void)
> +static void __init_xeno_interface(void)
> {
> 	int err;
> 
> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
> 	}
> 	fork_handler_registered = 1;
> }
> +
> +static __attribute__ ((constructor)) void __init_wrapper(void)
> +{
> +	__init_xeno_interface();
> +}
> 
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
> 

Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.

-- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka]

On 2013-05-14 11:44, Stephan Kappertz wrote:
> 
> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
> 
>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>
>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>
>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>
>>>>>
>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>
>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>
>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>
>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>
>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>
>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>
>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you:
>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>                                                            Gilles.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>
>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>> Using built-in specs.
>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>> ib
>>>>>>
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>
>>>>>>>> Binutils are 2.22:
>>>>>>>>
>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>
>>>>>>>>
>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>
>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>
>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>
>>>>>>>> -- Stephan
>>>>>>>>
>>>>>>>
>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>
>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>> Using built-in specs.
>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>> ws
>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.6.3 (Buildroot 2013.02)
>>>>>>>
>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>
>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>> startup:
>>>>>> frame_dummy
>>>>>> __init_xeno_interface
>>>>>> __init_native_tskey
>>>>>>
>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>> .init_array section:
>>>>>> 0x2458
>>>>>> 0x2254
>>>>>> 0x22b8
>>>>>> 0x2308
>>>>>>
>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>
>>>>>>  22b8:    e92d4008        push    {r3, lr}
>>>>>>  22bc:    e59f3030        ldr     r3, [pc, #48]   ; 22f4 <free@plt+0x108>
>>>>>>  22c0:    e59f0030        ldr     r0, [pc, #48]   ; 22f8 <free@plt+0x10c>
>>>>>>  22c4:    e08f3003        add     r3, pc, r3
>>>>>>  22c8:    e59f102c        ldr     r1, [pc, #44]   ; 22fc <free@plt+0x110>
>>>>>>  22cc:    e59f202c        ldr     r2, [pc, #44]   ; 2300 <free@plt+0x114>
>>>>>>  22d0:    e7930000        ldr     r0, [r3, r0]
>>>>>>  22d4:    e08f1001        add     r1, pc, r1
>>>>>>  22d8:    e59f3024        ldr     r3, [pc, #36]   ; 2304 <free@plt+0x118>
>>>>>>  22dc:    e08f2002        add     r2, pc, r2
>>>>>>  22e0:    e08f3003        add     r3, pc, r3
>>>>>>  22e4:    e5900000        ldr     r0, [r0]
>>>>>>  22e8:    ebffff5f        bl      206c <fprintf@plt>
>>>>>>  22ec:    e3a00001        mov     r0, #1
>>>>>>  22f0:    ebffff99        bl      215c <exit@plt>
>>>>>>
>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>
>>>>>> So, questions now:
>>>>>> - what commit in xenomai git are you using?
>>>>>> - could you try another toolchain ?
>>>>>>
>>>>>> Regards.
>>>>>> --
>>>>>>                                                              Gilles.
>>>>>>
>>>>>
>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>
>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>
>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>
>>>>>   native: avoid calling copy_from_user with hard irqs off
>>>>>
>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>
>>>>
>>>> Could you try git bisect to see which commit causes it?
>>>>
>>>> --
>>>>                                                               Gilles.
>>>>
>>>
>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>
>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>
>>>    Remove mlockall alert handler
>>>
>>>    The probability of such errors is negligible now because we lock
>>>    unconditionally. So we can remove the machinery that used to report such
>>>    bugs to the user. The nucleus will still raise a signal if userspace
>>>    willingly unlocked the memory - it will get what it deserves (an
>>>    untranslated signal).
>>>
>>>    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M   include
>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M   src
>>>
>>
>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
>>
>> We just started carrying this workaround locally, still undecided what
>> to do upstream.
>>
>>
>> native: Work around gcc-2.6
>>
>> This avoid that gcc bug 56712 lets the initialization of the native skin
>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>> background. Affects in particular Ubuntu 12.4 LTS.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>> src/skins/native/init.c |    8 ++++++--
>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>> index e380ca6..8e77e1c 100644
>> --- a/src/skins/native/init.c
>> +++ b/src/skins/native/init.c
>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>> }
>> #endif /* !HAVE___THREAD */
>>
>> -static __attribute__ ((constructor))
>> -void __init_xeno_interface(void)
>> +static void __init_xeno_interface(void)
>> {
>>       int err;
>>
>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>>       }
>>       fork_handler_registered = 1;
>> }
>> +
>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>> +{
>> +     __init_xeno_interface();
>> +}
>>
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> Corporate Competence Center Embedded Linux
>>
> 
> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.

OK, I pushed the patch for upstream merge. It's probably better to carry
the workaround than letting users find out the reason the hard way.
Gilles, please consider it for 2.6.3.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/14/2013 12:35 PM, Jan Kiszka wrote:

> On 2013-05-14 11:44, Stephan Kappertz wrote:
>>
>> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
>>
>>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>>
>>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>>
>>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>>
>>>>>>
>>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>>
>>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>>
>>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>>
>>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>>
>>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>
>>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>>
>>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Could you:
>>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>                                                            Gilles.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>>
>>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>>> Using built-in specs.
>>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>>> ib
>>>>>>>
>>>>>>>>> Thread model: posix
>>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>>
>>>>>>>>> Binutils are 2.22:
>>>>>>>>>
>>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>>
>>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>>
>>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>>
>>>>>>>>> -- Stephan
>>>>>>>>>
>>>>>>>>
>>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>>
>>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>>> Using built-in specs.
>>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>>> ws
>>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.6.3 (Buildroot 2013.02)
>>>>>>>>
>>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>>
>>>>>>>
>>>>>>> Hi Stefan,
>>>>>>>
>>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>>
>>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>>> startup:
>>>>>>> frame_dummy
>>>>>>> __init_xeno_interface
>>>>>>> __init_native_tskey
>>>>>>>
>>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>>> .init_array section:
>>>>>>> 0x2458
>>>>>>> 0x2254
>>>>>>> 0x22b8
>>>>>>> 0x2308
>>>>>>>
>>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>>
>>>>>>>  22b8:    e92d4008        push    {r3, lr}
>>>>>>>  22bc:    e59f3030        ldr     r3, [pc, #48]   ; 22f4 <free@plt+0x108>
>>>>>>>  22c0:    e59f0030        ldr     r0, [pc, #48]   ; 22f8 <free@plt+0x10c>
>>>>>>>  22c4:    e08f3003        add     r3, pc, r3
>>>>>>>  22c8:    e59f102c        ldr     r1, [pc, #44]   ; 22fc <free@plt+0x110>
>>>>>>>  22cc:    e59f202c        ldr     r2, [pc, #44]   ; 2300 <free@plt+0x114>
>>>>>>>  22d0:    e7930000        ldr     r0, [r3, r0]
>>>>>>>  22d4:    e08f1001        add     r1, pc, r1
>>>>>>>  22d8:    e59f3024        ldr     r3, [pc, #36]   ; 2304 <free@plt+0x118>
>>>>>>>  22dc:    e08f2002        add     r2, pc, r2
>>>>>>>  22e0:    e08f3003        add     r3, pc, r3
>>>>>>>  22e4:    e5900000        ldr     r0, [r0]
>>>>>>>  22e8:    ebffff5f        bl      206c <fprintf@plt>
>>>>>>>  22ec:    e3a00001        mov     r0, #1
>>>>>>>  22f0:    ebffff99        bl      215c <exit@plt>
>>>>>>>
>>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>>
>>>>>>> So, questions now:
>>>>>>> - what commit in xenomai git are you using?
>>>>>>> - could you try another toolchain ?
>>>>>>>
>>>>>>> Regards.
>>>>>>> --
>>>>>>>                                                              Gilles.
>>>>>>>
>>>>>>
>>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>>
>>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>>
>>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>>
>>>>>>   native: avoid calling copy_from_user with hard irqs off
>>>>>>
>>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>>
>>>>>
>>>>> Could you try git bisect to see which commit causes it?
>>>>>
>>>>> --
>>>>>                                                               Gilles.
>>>>>
>>>>
>>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>>
>>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>>
>>>>    Remove mlockall alert handler
>>>>
>>>>    The probability of such errors is negligible now because we lock
>>>>    unconditionally. So we can remove the machinery that used to report such
>>>>    bugs to the user. The nucleus will still raise a signal if userspace
>>>>    willingly unlocked the memory - it will get what it deserves (an
>>>>    untranslated signal).
>>>>
>>>>    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M   include
>>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M   src
>>>>
>>>
>>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
>>>
>>> We just started carrying this workaround locally, still undecided what
>>> to do upstream.
>>>
>>>
>>> native: Work around gcc-2.6
>>>
>>> This avoid that gcc bug 56712 lets the initialization of the native skin
>>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>>> background. Affects in particular Ubuntu 12.4 LTS.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>> src/skins/native/init.c |    8 ++++++--
>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>>> index e380ca6..8e77e1c 100644
>>> --- a/src/skins/native/init.c
>>> +++ b/src/skins/native/init.c
>>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>>> }
>>> #endif /* !HAVE___THREAD */
>>>
>>> -static __attribute__ ((constructor))
>>> -void __init_xeno_interface(void)
>>> +static void __init_xeno_interface(void)
>>> {
>>>       int err;
>>>
>>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>>>       }
>>>       fork_handler_registered = 1;
>>> }
>>> +
>>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>>> +{
>>> +     __init_xeno_interface();
>>> +}
>>>
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>> Corporate Competence Center Embedded Linux
>>>
>>
>> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.
> 
> OK, I pushed the patch for upstream merge. It's probably better to carry
> the workaround than letting users find out the reason the hard way.
> Gilles, please consider it for 2.6.3.


Ok, but does not the workaround of un-inlining xeno_bind_skin make more
sense?

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka]

On 2013-05-14 13:02, Gilles Chanteperdrix wrote:
>> OK, I pushed the patch for upstream merge. It's probably better to carry
>> the workaround than letting users find out the reason the hard way.
>> Gilles, please consider it for 2.6.3.
> 
> 
> Ok, but does not the workaround of un-inlining xeno_bind_skin make more
> sense?

The issue is not with xeno_bind_skin and its inlining but with patterns like

my_function()
{
	if (condition)
		return;
	do_other_stuff();
}

gcc tends to push do_other_stuff into a sub-function called
my_function.part.0, and that part is then incorrectly registered as
constructor function as well.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 13:02 schrieb Gilles Chanteperdrix:

> On 05/14/2013 12:35 PM, Jan Kiszka wrote:
> 
>> On 2013-05-14 11:44, Stephan Kappertz wrote:
>>> 
>>> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
>>> 
>>>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>>> 
>>>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>>> 
>>>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>>> 
>>>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>>> 
>>>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>>> 
>>>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>>> 
>>>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>                                                          Gilles.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Could you:
>>>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>>> 
>>>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>>>> Using built-in specs.
>>>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>>>> ib
>>>>>>>> 
>>>>>>>>>> Thread model: posix
>>>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>>> 
>>>>>>>>>> Binutils are 2.22:
>>>>>>>>>> 
>>>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>>> 
>>>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>>> 
>>>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>>> 
>>>>>>>>>> -- Stephan
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>>> 
>>>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>>>> Using built-in specs.
>>>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>>>> ws
>>>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>>>> Thread model: posix
>>>>>>>>> gcc version 4.6.3 (Buildroot 2013.02)
>>>>>>>>> 
>>>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Stefan,
>>>>>>>> 
>>>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>>> 
>>>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>>>> startup:
>>>>>>>> frame_dummy
>>>>>>>> __init_xeno_interface
>>>>>>>> __init_native_tskey
>>>>>>>> 
>>>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>>>> .init_array section:
>>>>>>>> 0x2458
>>>>>>>> 0x2254
>>>>>>>> 0x22b8
>>>>>>>> 0x2308
>>>>>>>> 
>>>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>>> 
>>>>>>>> 22b8:    e92d4008        push    {r3, lr}
>>>>>>>> 22bc:    e59f3030        ldr     r3, [pc, #48]   ; 22f4 <free@plt+0x108>
>>>>>>>> 22c0:    e59f0030        ldr     r0, [pc, #48]   ; 22f8 <free@plt+0x10c>
>>>>>>>> 22c4:    e08f3003        add     r3, pc, r3
>>>>>>>> 22c8:    e59f102c        ldr     r1, [pc, #44]   ; 22fc <free@plt+0x110>
>>>>>>>> 22cc:    e59f202c        ldr     r2, [pc, #44]   ; 2300 <free@plt+0x114>
>>>>>>>> 22d0:    e7930000        ldr     r0, [r3, r0]
>>>>>>>> 22d4:    e08f1001        add     r1, pc, r1
>>>>>>>> 22d8:    e59f3024        ldr     r3, [pc, #36]   ; 2304 <free@plt+0x118>
>>>>>>>> 22dc:    e08f2002        add     r2, pc, r2
>>>>>>>> 22e0:    e08f3003        add     r3, pc, r3
>>>>>>>> 22e4:    e5900000        ldr     r0, [r0]
>>>>>>>> 22e8:    ebffff5f        bl      206c <fprintf@plt>
>>>>>>>> 22ec:    e3a00001        mov     r0, #1
>>>>>>>> 22f0:    ebffff99        bl      215c <exit@plt>
>>>>>>>> 
>>>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>>> 
>>>>>>>> So, questions now:
>>>>>>>> - what commit in xenomai git are you using?
>>>>>>>> - could you try another toolchain ?
>>>>>>>> 
>>>>>>>> Regards.
>>>>>>>> --
>>>>>>>>                                                             Gilles.
>>>>>>>> 
>>>>>>> 
>>>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>>> 
>>>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>>> 
>>>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>>> 
>>>>>>>  native: avoid calling copy_from_user with hard irqs off
>>>>>>> 
>>>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>>> 
>>>>>> 
>>>>>> Could you try git bisect to see which commit causes it?
>>>>>> 
>>>>>> --
>>>>>>                                                              Gilles.
>>>>>> 
>>>>> 
>>>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>>> 
>>>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>>> 
>>>>>   Remove mlockall alert handler
>>>>> 
>>>>>   The probability of such errors is negligible now because we lock
>>>>>   unconditionally. So we can remove the machinery that used to report such
>>>>>   bugs to the user. The nucleus will still raise a signal if userspace
>>>>>   willingly unlocked the memory - it will get what it deserves (an
>>>>>   untranslated signal).
>>>>> 
>>>>>   Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> 
>>>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M   include
>>>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M   src
>>>>> 
>>>> 
>>>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>>>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
>>>> 
>>>> We just started carrying this workaround locally, still undecided what
>>>> to do upstream.
>>>> 
>>>> 
>>>> native: Work around gcc-2.6
>>>> 
>>>> This avoid that gcc bug 56712 lets the initialization of the native skin
>>>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>>>> background. Affects in particular Ubuntu 12.4 LTS.
>>>> 
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> ---
>>>> src/skins/native/init.c |    8 ++++++--
>>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>>>> index e380ca6..8e77e1c 100644
>>>> --- a/src/skins/native/init.c
>>>> +++ b/src/skins/native/init.c
>>>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>>>> }
>>>> #endif /* !HAVE___THREAD */
>>>> 
>>>> -static __attribute__ ((constructor))
>>>> -void __init_xeno_interface(void)
>>>> +static void __init_xeno_interface(void)
>>>> {
>>>>      int err;
>>>> 
>>>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>>>>      }
>>>>      fork_handler_registered = 1;
>>>> }
>>>> +
>>>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>>>> +{
>>>> +     __init_xeno_interface();
>>>> +}
>>>> 
>>>> 
>>>> Jan
>>>> 
>>>> --
>>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>>> Corporate Competence Center Embedded Linux
>>>> 
>>> 
>>> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.
>> 
>> OK, I pushed the patch for upstream merge. It's probably better to carry
>> the workaround than letting users find out the reason the hard way.
>> Gilles, please consider it for 2.6.3.
> 
> 
> Ok, but does not the workaround of un-inlining xeno_bind_skin make more
> sense?
> 
> -- 
>                                                                Gilles.
> 

I'd say yes because it fixes all skins.

-- Stephan
 

Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka]

On 2013-05-14 13:19, Stephan Kappertz wrote:
> 
> Am 14.05.2013 um 13:02 schrieb Gilles Chanteperdrix:
> 
>> On 05/14/2013 12:35 PM, Jan Kiszka wrote:
>>
>>> On 2013-05-14 11:44, Stephan Kappertz wrote:
>>>>
>>>> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
>>>>
>>>>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>>>>
>>>>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>>>>
>>>>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>>>>
>>>>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>>>>
>>>>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>>>>
>>>>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>>>>
>>>>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>                                                          Gilles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you:
>>>>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>>>>
>>>>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>>>>> Using built-in specs.
>>>>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>>>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>>>>> ib
>>>>>>>>>
>>>>>>>>>>> Thread model: posix
>>>>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>>>>
>>>>>>>>>>> Binutils are 2.22:
>>>>>>>>>>>
>>>>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>>>>
>>>>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>>>>
>>>>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>>>>
>>>>>>>>>>> -- Stephan
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>>>>
>>>>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>>>>> Using built-in specs.
>>>>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>>>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>>>>> ws
>>>>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>>>>> Thread model: posix
>>>>>>>>>> gcc version 4.6.3 (Buildroot 2013.02)
>>>>>>>>>>
>>>>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Stefan,
>>>>>>>>>
>>>>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>>>>
>>>>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>>>>> startup:
>>>>>>>>> frame_dummy
>>>>>>>>> __init_xeno_interface
>>>>>>>>> __init_native_tskey
>>>>>>>>>
>>>>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>>>>> .init_array section:
>>>>>>>>> 0x2458
>>>>>>>>> 0x2254
>>>>>>>>> 0x22b8
>>>>>>>>> 0x2308
>>>>>>>>>
>>>>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>>>>
>>>>>>>>> 22b8:    e92d4008        push    {r3, lr}
>>>>>>>>> 22bc:    e59f3030        ldr     r3, [pc, #48]   ; 22f4 <free@plt+0x108>
>>>>>>>>> 22c0:    e59f0030        ldr     r0, [pc, #48]   ; 22f8 <free@plt+0x10c>
>>>>>>>>> 22c4:    e08f3003        add     r3, pc, r3
>>>>>>>>> 22c8:    e59f102c        ldr     r1, [pc, #44]   ; 22fc <free@plt+0x110>
>>>>>>>>> 22cc:    e59f202c        ldr     r2, [pc, #44]   ; 2300 <free@plt+0x114>
>>>>>>>>> 22d0:    e7930000        ldr     r0, [r3, r0]
>>>>>>>>> 22d4:    e08f1001        add     r1, pc, r1
>>>>>>>>> 22d8:    e59f3024        ldr     r3, [pc, #36]   ; 2304 <free@plt+0x118>
>>>>>>>>> 22dc:    e08f2002        add     r2, pc, r2
>>>>>>>>> 22e0:    e08f3003        add     r3, pc, r3
>>>>>>>>> 22e4:    e5900000        ldr     r0, [r0]
>>>>>>>>> 22e8:    ebffff5f        bl      206c <fprintf@plt>
>>>>>>>>> 22ec:    e3a00001        mov     r0, #1
>>>>>>>>> 22f0:    ebffff99        bl      215c <exit@plt>
>>>>>>>>>
>>>>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>>>>
>>>>>>>>> So, questions now:
>>>>>>>>> - what commit in xenomai git are you using?
>>>>>>>>> - could you try another toolchain ?
>>>>>>>>>
>>>>>>>>> Regards.
>>>>>>>>> --
>>>>>>>>>                                                             Gilles.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>>>>
>>>>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>>>>
>>>>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>>>>
>>>>>>>>  native: avoid calling copy_from_user with hard irqs off
>>>>>>>>
>>>>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>>>>
>>>>>>>
>>>>>>> Could you try git bisect to see which commit causes it?
>>>>>>>
>>>>>>> --
>>>>>>>                                                              Gilles.
>>>>>>>
>>>>>>
>>>>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>>>>
>>>>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>>>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>>>>
>>>>>>   Remove mlockall alert handler
>>>>>>
>>>>>>   The probability of such errors is negligible now because we lock
>>>>>>   unconditionally. So we can remove the machinery that used to report such
>>>>>>   bugs to the user. The nucleus will still raise a signal if userspace
>>>>>>   willingly unlocked the memory - it will get what it deserves (an
>>>>>>   untranslated signal).
>>>>>>
>>>>>>   Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M   include
>>>>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M   src
>>>>>>
>>>>>
>>>>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>>>>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712
>>>>>
>>>>> We just started carrying this workaround locally, still undecided what
>>>>> to do upstream.
>>>>>
>>>>>
>>>>> native: Work around gcc-2.6
>>>>>
>>>>> This avoid that gcc bug 56712 lets the initialization of the native skin
>>>>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>>>>> background. Affects in particular Ubuntu 12.4 LTS.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> ---
>>>>> src/skins/native/init.c |    8 ++++++--
>>>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>>>>> index e380ca6..8e77e1c 100644
>>>>> --- a/src/skins/native/init.c
>>>>> +++ b/src/skins/native/init.c
>>>>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>>>>> }
>>>>> #endif /* !HAVE___THREAD */
>>>>>
>>>>> -static __attribute__ ((constructor))
>>>>> -void __init_xeno_interface(void)
>>>>> +static void __init_xeno_interface(void)
>>>>> {
>>>>>      int err;
>>>>>
>>>>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>>>>>      }
>>>>>      fork_handler_registered = 1;
>>>>> }
>>>>> +
>>>>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>>>>> +{
>>>>> +     __init_xeno_interface();
>>>>> +}
>>>>>
>>>>>
>>>>> Jan
>>>>>
>>>>> --
>>>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>>>> Corporate Competence Center Embedded Linux
>>>>>
>>>>
>>>> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.
>>>
>>> OK, I pushed the patch for upstream merge. It's probably better to carry
>>> the workaround than letting users find out the reason the hard way.
>>> Gilles, please consider it for 2.6.3.
>>
>>
>> Ok, but does not the workaround of un-inlining xeno_bind_skin make more
>> sense?
>>
>> --
>>                                                                Gilles.
>>
> 
> I'd say yes because it fixes all skins.

I didn't find any other skin that is affected as well.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/14/2013 01:11 PM, Jan Kiszka wrote:

> On 2013-05-14 13:02, Gilles Chanteperdrix wrote:
>>> OK, I pushed the patch for upstream merge. It's probably better to carry
>>> the workaround than letting users find out the reason the hard way.
>>> Gilles, please consider it for 2.6.3.
>>
>>
>> Ok, but does not the workaround of un-inlining xeno_bind_skin make more
>> sense?
> 
> The issue is not with xeno_bind_skin and its inlining but with patterns like
> 
> my_function()
> {
> 	if (condition)
> 		return;
> 	do_other_stuff();
> }
> 
> gcc tends to push do_other_stuff into a sub-function called
> my_function.part.0, and that part is then incorrectly registered as
> constructor function as well.


I understood that, but in the case of the native skin, the only such
branch is created by the fact that xeno_bind_skin is inlined (and it is
the other way around, it is the if branch that goes in a helper
function, the unlikely branch in fact). So, if the native skin
initialization is the only one to be problematic, then it fixes the
issue. If the native skin initialization is not the only one to be
problematic, then your patch is unsufficient. It is also unsufficient
because it does not guarantee that the compiler will not inline
__init_xeno_interface in __init_wrapper when we use other more
aggressive compilation options, at minimum __attribute__((noinline))
would be needed, and not only for the native skin. So, I nack this patch.

So, since we know that this is a broken compiler and that there are
other versions that work, I propose to detect it in the configure script
and abort compilation when we find this compiler.

Yet another solution would be to suppress the automatic binding with
__attribute__((constructor)) and bind the skin on first use of the
"muxid", with a static inline function using a static pthread_once_t.

-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Jan Kiszka]

On 2013-05-14 13:26, Gilles Chanteperdrix wrote:
> On 05/14/2013 01:11 PM, Jan Kiszka wrote:
> 
>> On 2013-05-14 13:02, Gilles Chanteperdrix wrote:
>>>> OK, I pushed the patch for upstream merge. It's probably better to carry
>>>> the workaround than letting users find out the reason the hard way.
>>>> Gilles, please consider it for 2.6.3.
>>>
>>>
>>> Ok, but does not the workaround of un-inlining xeno_bind_skin make more
>>> sense?
>>
>> The issue is not with xeno_bind_skin and its inlining but with patterns like
>>
>> my_function()
>> {
>> 	if (condition)
>> 		return;
>> 	do_other_stuff();
>> }
>>
>> gcc tends to push do_other_stuff into a sub-function called
>> my_function.part.0, and that part is then incorrectly registered as
>> constructor function as well.
> 
> 
> I understood that, but in the case of the native skin, the only such
> branch is created by the fact that xeno_bind_skin is inlined (and it is
> the other way around, it is the if branch that goes in a helper
> function, the unlikely branch in fact).

One of the first things I tried was commenting out xeno_bind_skin, and
the problem unfortunately remained. There are two more spots in
__init_xeno_interface: around fork_handler_registered and error handling
of pthread_atfork. In fact, the latter code is what is factored out into
a separate function here.

> So, if the native skin
> initialization is the only one to be problematic, then it fixes the
> issue. If the native skin initialization is not the only one to be
> problematic, then your patch is unsufficient. It is also unsufficient
> because it does not guarantee that the compiler will not inline
> __init_xeno_interface in __init_wrapper when we use other more
> aggressive compilation options, at minimum __attribute__((noinline))
> would be needed, and not only for the native skin. So, I nack this patch.
> 
> So, since we know that this is a broken compiler and that there are
> other versions that work, I propose to detect it in the configure script
> and abort compilation when we find this compiler.
> 
> Yet another solution would be to suppress the automatic binding with
> __attribute__((constructor)) and bind the skin on first use of the
> "muxid", with a static inline function using a static pthread_once_t.

I would prefer limiting the workaround to init code, leaving runtime
paths alone.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/14/2013 11:44 AM, Stephan Kappertz wrote:

> 
> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
> 
>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>
>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>
>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>
>>>>>
>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>
>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>
>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>
>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>
>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>
>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>>                                                           Gilles.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>
>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could you:
>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>>                                                            Gilles.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>
>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>> Using built-in specs.
>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>> ib
>>>>>>
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>
>>>>>>>> Binutils are 2.22:
>>>>>>>>
>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>
>>>>>>>>
>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>
>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>
>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>
>>>>>>>> -- Stephan
>>>>>>>>
>>>>>>>
>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>
>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>> Using built-in specs.
>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>> ws
>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>>>>>
>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>
>>>>>>
>>>>>> Hi Stefan,
>>>>>>
>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>
>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>> startup:
>>>>>> frame_dummy
>>>>>> __init_xeno_interface
>>>>>> __init_native_tskey
>>>>>>
>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>> .init_array section:
>>>>>> 0x2458
>>>>>> 0x2254
>>>>>> 0x22b8
>>>>>> 0x2308
>>>>>>
>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>
>>>>>>  22b8:	e92d4008 	push	{r3, lr}
>>>>>>  22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>>>>>  22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>>>>>  22c4:	e08f3003 	add	r3, pc, r3
>>>>>>  22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>>>>>  22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>>>>>  22d0:	e7930000 	ldr	r0, [r3, r0]
>>>>>>  22d4:	e08f1001 	add	r1, pc, r1
>>>>>>  22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>>>>>  22dc:	e08f2002 	add	r2, pc, r2
>>>>>>  22e0:	e08f3003 	add	r3, pc, r3
>>>>>>  22e4:	e5900000 	ldr	r0, [r0]
>>>>>>  22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>>>>>  22ec:	e3a00001 	mov	r0, #1
>>>>>>  22f0:	ebffff99 	bl	215c <exit@plt>
>>>>>>
>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>
>>>>>> So, questions now:
>>>>>> - what commit in xenomai git are you using?
>>>>>> - could you try another toolchain ?
>>>>>>
>>>>>> Regards.
>>>>>> -- 
>>>>>>                                                              Gilles.
>>>>>>
>>>>>
>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>
>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>
>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>
>>>>>   native: avoid calling copy_from_user with hard irqs off
>>>>>
>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>
>>>>
>>>> Could you try git bisect to see which commit causes it?
>>>>
>>>> -- 
>>>>                                                               Gilles.
>>>>
>>>
>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>
>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>
>>>    Remove mlockall alert handler
>>>
>>>    The probability of such errors is negligible now because we lock
>>>    unconditionally. So we can remove the machinery that used to report such
>>>    bugs to the user. The nucleus will still raise a signal if userspace
>>>    willingly unlocked the memory - it will get what it deserves (an
>>>    untranslated signal).
>>>
>>>    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M	include
>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M	src
>>>
>>
>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 
>>
>> We just started carrying this workaround locally, still undecided what
>> to do upstream.
>>
>>
>> native: Work around gcc-2.6
>>
>> This avoid that gcc bug 56712 lets the initialization of the native skin
>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>> background. Affects in particular Ubuntu 12.4 LTS.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>> src/skins/native/init.c |    8 ++++++--
>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>> index e380ca6..8e77e1c 100644
>> --- a/src/skins/native/init.c
>> +++ b/src/skins/native/init.c
>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>> }
>> #endif /* !HAVE___THREAD */
>>
>> -static __attribute__ ((constructor))
>> -void __init_xeno_interface(void)
>> +static void __init_xeno_interface(void)
>> {
>> 	int err;
>>
>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>> 	}
>> 	fork_handler_registered = 1;
>> }
>> +
>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>> +{
>> +	__init_xeno_interface();
>> +}
>>
>>
>> Jan
>>
>> -- 
>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> Corporate Competence Center Embedded Linux
>>
> 
> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.


Hi Stefan,

can you try whether Jan's latest patch avoids the problem for you?

http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=571bbe773cd8ba494435c98cec830449aaeaa210

Regards.
-- 
                                                                Gilles.

Re: [Xenomai] Raspberry and Beaglebone patches

[Stephan Kappertz]

Am 14.05.2013 um 20:30 schrieb Gilles Chanteperdrix:

> On 05/14/2013 11:44 AM, Stephan Kappertz wrote:
> 
>> 
>> Am 14.05.2013 um 11:20 schrieb Jan Kiszka:
>> 
>>> On 2013-05-14 11:11, Stephan Kappertz wrote:
>>>> 
>>>> Am 14.05.2013 um 09:53 schrieb Gilles Chanteperdrix:
>>>> 
>>>>> On 05/14/2013 09:33 AM, Stephan Kappertz wrote:
>>>>> 
>>>>>> 
>>>>>> Am 14.05.2013 um 08:41 schrieb Gilles Chanteperdrix:
>>>>>> 
>>>>>>> On 05/13/2013 01:20 PM, Stephan Kappertz wrote:
>>>>>>> 
>>>>>>>> Am 13.05.2013 um 12:37 schrieb Stephan Kappertz:
>>>>>>>> 
>>>>>>>>> Am 10.05.2013 um 19:02 schrieb Gilles Chanteperdrix:
>>>>>>>>> 
>>>>>>>>>> On 05/10/2013 06:48 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> 
>>>>>>>>>>> On 05/10/2013 06:40 PM, Stephan Kappertz wrote:
>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm using your git repository directly. Applied my post.patch and
>>>>>>>>>>>>>> compiled the kernel. So this is 3.8.0. Looks like my Xenomai user
>>>>>>>>>>>>>> space compile was broken. Still working on fixing it.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What options did you pass to the configure script?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>                                                          Gilles.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> ../configure --target=arm-buildroot-linux-uclibcgnueabi --host=arm-buildroot-linux-uclibcgnueabi --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix="" --enable-static --enable-shared  CFLAGS="-march=armv7-a -mfpu=vfp3" LDFLAGS="-march=armv7-a -mfpu=vfp3" --includedir=/usr/include/xenomai/
>>>>>>>>>>>> 
>>>>>>>>>>>> This is a buildroot build.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Could you:
>>>>>>>>>>> - tell me what version of gcc, binutils, etc... you use?
>>>>>>>>>>> - show me a disassembly of the xeno_bind_skip_opt function in libxenomai.so?
>>>>>>>>>>> - instrument the function xeno_sigill_handler in
>>>>>>>>>>> src/skins/common/bind.c to see if you are indeed taking the SIGILL signal?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Sorry, you do not take the SIGILL handler, please instrument
>>>>>>>>>> xeno_bind_skin_opt to print the value of "muxid" returned by the
>>>>>>>>>> XENOMAI_SYSBIND system call.
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>>                                                           Gilles.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Ok, here's the compiler spec:
>>>>>>>>> 
>>>>>>>>> $ arm-linux-gnueabi-gcc -v
>>>>>>>>> Using built-in specs.
>>>>>>>>> COLLECT_GCC=arm-linux-gnueabi-gcc
>>>>>>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>>>>>>>> Target: arm-linux-gnueabi
>>>>>>>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gn
>>>> u --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/l
>>>>> ib
>>>>>>> 
>>>>>>>>> Thread model: posix
>>>>>>>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>>>>>>>>> 
>>>>>>>>> Binutils are 2.22:
>>>>>>>>> 
>>>>>>>>> arm-linux-gnueabi-as -v
>>>>>>>>> GNU assembler version 2.22 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.22
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Now what's interesting is: as soon as I am adding an instrumentation "fprintf(stdout, "Xenomai: xeno_bind_skin_opt muxid = %d\n", muxid);" to "static inline int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)", binding succeeds and all xeno-test pass. The other option to get it work was:  declaring "int xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module);" in bind.h and defining it in bind.c.
>>>>>>>>> 
>>>>>>>>> If I'm only instrumenting xeno_bind_skin_opt(), I see that it never gets called in the original code.
>>>>>>>>> 
>>>>>>>>> Do you still want to see the disassembly?
>>>>>>>>> 
>>>>>>>>> -- Stephan
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Oops, sent you the wrong compiler spec. Xenomai libraries & tests are compiled with:
>>>>>>>> 
>>>>>>>> $ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -v
>>>>>>>> Using built-in specs.
>>>>>>>> COLLECT_GCC=host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc
>>>>>>>> COLLECT_LTO_WRAPPER=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper
>>>>>>>> Target: arm-buildroot-linux-uclibcgnueabi
>>>>>>>> Configured with: /home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/toolchain/gcc-4.6.3/configure --prefix=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c --with-sysroot=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot --with-build-time-tools=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr/arm-buildroot-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --with-gmp=/home/stepha
>>>> n/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpfr=/home/stephan/dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --with-mpc=/home/stephan/dev.
>>>>> ws
>>>>>>> .Centaurus_skappert/embedded/products/Carbon/AM335x/host/usr --disable-nls --enable-threads --disable-decimal-float --with-float=soft --with-abi=aapcs-linux --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile --with-pkgversion='Buildroot 2013.02' --with-bugurl=http://bugs.buildroot.net/
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.6.3 (Buildroot 2013.02) 
>>>>>>>> 
>>>>>>>> /dev.ws.Centaurus_skappert/embedded/products/Carbon/AM335x$ host/usr/bin/arm-buildroot-linux-uclibcgnueabi-as -v
>>>>>>>> GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Stefan,
>>>>>>> 
>>>>>>> I have no other explanation than that the combination of the toolchain
>>>>>>> you use with Xenomai code you use produces broken code.
>>>>>>> 
>>>>>>> The version of libnative.so generated with a similar toolchain
>>>>>>> (codesourcery 2012.03) has three pointers in its .init_array section,
>>>>>>> these are the pointers to the functions which are invoked upon library
>>>>>>> startup:
>>>>>>> frame_dummy
>>>>>>> __init_xeno_interface
>>>>>>> __init_native_tskey
>>>>>>> 
>>>>>>> The version of libnative.so you sent me has four pointers in its
>>>>>>> .init_array section:
>>>>>>> 0x2458
>>>>>>> 0x2254
>>>>>>> 0x22b8
>>>>>>> 0x2308
>>>>>>> 
>>>>>>> I do not have the function names, I believe, because the binary you sent
>>>>>>> me is stripped. However, 0x2308 looks like __init_xeno_interface, 0x2254
>>>>>>> looks like __init_native_tskey, and 0x22b8 has the following disassembly:
>>>>>>> 
>>>>>>> 22b8:	e92d4008 	push	{r3, lr}
>>>>>>> 22bc:	e59f3030 	ldr	r3, [pc, #48]	; 22f4 <free@plt+0x108>
>>>>>>> 22c0:	e59f0030 	ldr	r0, [pc, #48]	; 22f8 <free@plt+0x10c>
>>>>>>> 22c4:	e08f3003 	add	r3, pc, r3
>>>>>>> 22c8:	e59f102c 	ldr	r1, [pc, #44]	; 22fc <free@plt+0x110>
>>>>>>> 22cc:	e59f202c 	ldr	r2, [pc, #44]	; 2300 <free@plt+0x114>
>>>>>>> 22d0:	e7930000 	ldr	r0, [r3, r0]
>>>>>>> 22d4:	e08f1001 	add	r1, pc, r1
>>>>>>> 22d8:	e59f3024 	ldr	r3, [pc, #36]	; 2304 <free@plt+0x118>
>>>>>>> 22dc:	e08f2002 	add	r2, pc, r2
>>>>>>> 22e0:	e08f3003 	add	r3, pc, r3
>>>>>>> 22e4:	e5900000 	ldr	r0, [r0]
>>>>>>> 22e8:	ebffff5f 	bl	206c <fprintf@plt>
>>>>>>> 22ec:	e3a00001 	mov	r0, #1
>>>>>>> 22f0:	ebffff99 	bl	215c <exit@plt>
>>>>>>> 
>>>>>>> Which means that it calls directly fprintf and exit, without even
>>>>>>> calling xeno_bind_skin_opt. So, it looks like an "optimized" version of
>>>>>>> __init_xeno_interface, assuming xeno_bind_skin_opt always return -1.
>>>>>>> 
>>>>>>> So, questions now:
>>>>>>> - what commit in xenomai git are you using?
>>>>>>> - could you try another toolchain ?
>>>>>>> 
>>>>>>> Regards.
>>>>>>> -- 
>>>>>>>                                                             Gilles.
>>>>>>> 
>>>>>> 
>>>>>> Yes, you are correct. I'm seeing that with the libraries compiled with -g and unstripped I just sent you.
>>>>>> 
>>>>>> I'm using http://git.xenomai.org/xenomai-2.6.git @ master, last commit:
>>>>>> 
>>>>>> commit 9b645b0fbf5fe6068358f4bbc25469ebd24b822f
>>>>>> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>>>>>> Date:   Fri May 10 15:27:38 2013 +0200
>>>>>> 
>>>>>>  native: avoid calling copy_from_user with hard irqs off
>>>>>> 
>>>>>> I also tried 2.6.2.1 release and that version does work (compile) correctly.
>>>>> 
>>>>> 
>>>>> Could you try git bisect to see which commit causes it?
>>>>> 
>>>>> -- 
>>>>>                                                              Gilles.
>>>>> 
>>>> 
>>>> Similar to the printf instrumentation making it working, it starts to fail after the commit removing the extra code from xeno_bind_skin:
>>>> 
>>>> a9aa9557f1df4f515791f42b8cf7bb301b31365a is the first bad commit
>>>> commit a9aa9557f1df4f515791f42b8cf7bb301b31365a
>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>> Date:   Tue Apr 23 14:32:01 2013 +0200
>>>> 
>>>>   Remove mlockall alert handler
>>>> 
>>>>   The probability of such errors is negligible now because we lock
>>>>   unconditionally. So we can remove the machinery that used to report such
>>>>   bugs to the user. The nucleus will still raise a signal if userspace
>>>>   willingly unlocked the memory - it will get what it deserves (an
>>>>   untranslated signal).
>>>> 
>>>>   Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> 
>>>> :040000 040000 72a70a220c9760bcbe39e3325a18a7deab1058ca 7db151f89a86e5f40112695fb21480803f51c64c M	include
>>>> :040000 040000 3587a708c726f968bc5d8eb9ab85b2717eb8c4d0 f327044f164ab16487d5d4c5efdea1bda7101f80 M	src
>>>> 
>>> 
>>> Oh, you ran into an ugly gcc bug that won't be fixed for that version
>>> anymore: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 
>>> 
>>> We just started carrying this workaround locally, still undecided what
>>> to do upstream.
>>> 
>>> 
>>> native: Work around gcc-2.6
>>> 
>>> This avoid that gcc bug 56712 lets the initialization of the native skin
>>> fail. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 for the
>>> background. Affects in particular Ubuntu 12.4 LTS.
>>> 
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>> src/skins/native/init.c |    8 ++++++--
>>> 1 files changed, 6 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/src/skins/native/init.c b/src/skins/native/init.c
>>> index e380ca6..8e77e1c 100644
>>> --- a/src/skins/native/init.c
>>> +++ b/src/skins/native/init.c
>>> @@ -50,8 +50,7 @@ void __init_native_tskey(void)
>>> }
>>> #endif /* !HAVE___THREAD */
>>> 
>>> -static __attribute__ ((constructor))
>>> -void __init_xeno_interface(void)
>>> +static void __init_xeno_interface(void)
>>> {
>>> 	int err;
>>> 
>>> @@ -71,3 +70,8 @@ void __init_xeno_interface(void)
>>> 	}
>>> 	fork_handler_registered = 1;
>>> }
>>> +
>>> +static __attribute__ ((constructor)) void __init_wrapper(void)
>>> +{
>>> +	__init_xeno_interface();
>>> +}
>>> 
>>> 
>>> Jan
>>> 
>>> -- 
>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>> Corporate Competence Center Embedded Linux
>>> 
>> 
>> Ah, thanks for the info. I can confirm that xeno-test succeeds with gcc 4.6.3 after applying your patch.
> 
> 
> Hi Stefan,
> 
> can you try whether Jan's latest patch avoids the problem for you?
> 
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=571bbe773cd8ba494435c98cec830449aaeaa210
> 
> Regards.
> -- 
>                                                                Gilles.
> 

Yes, that patch works for me. Thanks Jan and Gilles!

- Stephan

Re: [Xenomai] Raspberry and Beaglebone patches

[Gilles Chanteperdrix]

On 05/10/2013 01:53 PM, Stephan Kappertz wrote:

> Sorry for the delay, here it is. Tested against pipe-gch for-core-3.8. Xenomai is successfully starting on the beagleBone:


This patch has been merged, thanks.

-- 
                                                                Gilles.