[Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Xenomai] xenomai-2.6.0 instrumentation commands not executing

[ali hagigat]

I have installed xenomai-2.6.0. None of the instrumentation commands
work except latency. What can i do?

/root> switchbench
bash: switchbench: command not found
/root> switchtest
Xenomai Posix skin init: pthread_setschedparam: Function not implemented
/root> cyclictest
Xenomai Posix skin init: pthread_setschedparam: Function not implemented
/root> latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds

/root> xeno-test
Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
/usr/xenomai/bin/xeno-test
++ echo 0
++ /usr/xenomai/bin/arith
mul: 0x79364d93, shft: 26
integ: 30, frac: 0x4d9364d9364d9364

signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000

signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000

unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected 1/10000
++ /usr/xenomai/bin/clocktest -T 30
Xenomai Posix skin init: pthread_setschedparam: Function not implemented


Only latency seems working.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 09:40 AM, ali hagigat wrote:
> I have installed xenomai-2.6.0. None of the instrumentation commands
> work except latency. What can i do?
>

Likely fix your Kconfig. Enable the Xenomai POSIX skin.

> /root>  switchbench
> bash: switchbench: command not found
> /root>  switchtest
> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
> /root>  cyclictest
> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
> /root>  latency
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
>
> /root>  xeno-test
> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
> /usr/xenomai/bin/xeno-test
> ++ echo 0
> ++ /usr/xenomai/bin/arith
> mul: 0x79364d93, shft: 26
> integ: 30, frac: 0x4d9364d9364d9364
>
> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000
>
> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000
>
> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected 1/10000
> ++ /usr/xenomai/bin/clocktest -T 30
> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>
>
> Only latency seems working.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[ali hagigat]

Thank you, Philippe, for the reply.

How can i enable posix skin? should i do , make menuconfig, for the
kernel? Or i should change scripts/defconfig.frag?

It seems that both places have the correct values already but i still
have the error:

defconfig.frag:
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y

#
# Native interface options
#
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y

and in the kernel:
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
CONFIG_XENO_OPT_NATIVE_INTR=y
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_SHM=y
CONFIG_XENO_OPT_POSIX_INTR=y
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
CONFIG_XENO_SKIN_VXWORKS=y
CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
CONFIG_XENO_OPT_DEBUG_VXWORKS=y
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y


On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>
>> I have installed xenomai-2.6.0. None of the instrumentation commands
>> work except latency. What can i do?
>>
>
> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>
>> /root>  switchbench
>> bash: switchbench: command not found
>> /root>  switchtest
>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>> /root>  cyclictest
>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>> /root>  latency
>> == Sampling period: 100 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>>
>> /root>  xeno-test
>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>> /usr/xenomai/bin/xeno-test
>> ++ echo 0
>> ++ /usr/xenomai/bin/arith
>> mul: 0x79364d93, shft: 26
>> integ: 30, frac: 0x4d9364d9364d9364
>>
>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000
>>
>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000
>>
>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected 1/10000
>> ++ /usr/xenomai/bin/clocktest -T 30
>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>
>>
>> Only latency seems working.
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
>
> --
> Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 11:06 AM, ali hagigat wrote:
> Thank you, Philippe, for the reply.
>
> How can i enable posix skin? should i do , make menuconfig, for the
> kernel? Or i should change scripts/defconfig.frag?
>
> It seems that both places have the correct values already but i still
> have the error:

The POSIX skin is indeed enabled. What is the output of the command below?

# ldd <your-executable>

>
> defconfig.frag:
> #
> # Interfaces
> #
> CONFIG_XENO_SKIN_NATIVE=y
>
> #
> # Native interface options
> #
> CONFIG_XENO_OPT_NATIVE_PERIOD=0
> CONFIG_XENO_OPT_NATIVE_PIPE=y
> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
> CONFIG_XENO_OPT_NATIVE_SEM=y
> CONFIG_XENO_OPT_NATIVE_EVENT=y
> CONFIG_XENO_OPT_NATIVE_MUTEX=y
> CONFIG_XENO_OPT_NATIVE_COND=y
> CONFIG_XENO_OPT_NATIVE_QUEUE=y
> CONFIG_XENO_OPT_NATIVE_HEAP=y
> CONFIG_XENO_OPT_NATIVE_ALARM=y
> CONFIG_XENO_OPT_NATIVE_MPS=y
> # CONFIG_XENO_OPT_NATIVE_INTR is not set
> CONFIG_XENO_SKIN_POSIX=y
>
> and in the kernel:
> # Interfaces
> #
> CONFIG_XENO_SKIN_NATIVE=y
> CONFIG_XENO_OPT_NATIVE_PERIOD=0
> CONFIG_XENO_OPT_NATIVE_PIPE=y
> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
> CONFIG_XENO_OPT_NATIVE_SEM=y
> CONFIG_XENO_OPT_NATIVE_EVENT=y
> CONFIG_XENO_OPT_NATIVE_MUTEX=y
> CONFIG_XENO_OPT_NATIVE_COND=y
> CONFIG_XENO_OPT_NATIVE_QUEUE=y
> CONFIG_XENO_OPT_NATIVE_BUFFER=y
> CONFIG_XENO_OPT_NATIVE_HEAP=y
> CONFIG_XENO_OPT_NATIVE_ALARM=y
> CONFIG_XENO_OPT_NATIVE_MPS=y
> CONFIG_XENO_OPT_NATIVE_INTR=y
> CONFIG_XENO_OPT_DEBUG_NATIVE=y
> CONFIG_XENO_SKIN_POSIX=y
> CONFIG_XENO_OPT_POSIX_PERIOD=0
> CONFIG_XENO_OPT_POSIX_SHM=y
> CONFIG_XENO_OPT_POSIX_INTR=y
> CONFIG_XENO_OPT_POSIX_SELECT=y
> CONFIG_XENO_OPT_DEBUG_POSIX=y
> # CONFIG_XENO_SKIN_PSOS is not set
> # CONFIG_XENO_SKIN_UITRON is not set
> # CONFIG_XENO_SKIN_VRTX is not set
> CONFIG_XENO_SKIN_VXWORKS=y
> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
> CONFIG_XENO_SKIN_RTDM=y
> CONFIG_XENO_OPT_RTDM_PERIOD=0
> CONFIG_XENO_OPT_RTDM_FILDES=128
> CONFIG_XENO_OPT_RTDM_SELECT=y
> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>
>
> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>
>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>> work except latency. What can i do?
>>>
>>
>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>
>>> /root>    switchbench
>>> bash: switchbench: command not found
>>> /root>    switchtest
>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>> /root>    cyclictest
>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>> /root>    latency
>>> == Sampling period: 100 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>>
>>> /root>    xeno-test
>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>> /usr/xenomai/bin/xeno-test
>>> ++ echo 0
>>> ++ /usr/xenomai/bin/arith
>>> mul: 0x79364d93, shft: 26
>>> integ: 30, frac: 0x4d9364d9364d9364
>>>
>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000
>>>
>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000
>>>
>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected 1/10000
>>> ++ /usr/xenomai/bin/clocktest -T 30
>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>
>>>
>>> Only latency seems working.
>>>
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>
>>
>>
>> --
>> Philippe.
>


-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[ali hagigat]

Much appreciate for the reply, Mr. Gerum. Here is the result of ldd command:

/usr/xenomai/bin> ldd switchtest
	linux-gate.so.1 =>  (0xb786c000)
	libpthread_rt.so.1 => /usr/xenomai/lib/libpthread_rt.so.1 (0xb785f000)
	libxenomai.so.0 => /usr/xenomai/lib/libxenomai.so.0 (0xb7859000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0058e000)
	librt.so.1 => /lib/librt.so.1 (0x005c3000)
	libc.so.6 => /lib/libc.so.6 (0x003cd000)
	/lib/ld-linux.so.2 (0x003a7000)
/usr/xenomai/bin> ldd switchbench
ldd: ./switchbench: No such file or directory
/usr/xenomai/bin> cd /root
/root> ldd switchtest
ldd: ./switchtest: No such file or directory


On Wed, Jun 6, 2012 at 1:41 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 06/06/2012 11:06 AM, ali hagigat wrote:
>>
>> Thank you, Philippe, for the reply.
>>
>> How can i enable posix skin? should i do , make menuconfig, for the
>> kernel? Or i should change scripts/defconfig.frag?
>>
>> It seems that both places have the correct values already but i still
>> have the error:
>
>
> The POSIX skin is indeed enabled. What is the output of the command below?
>
> # ldd <your-executable>
>
>
>>
>> defconfig.frag:
>> #
>> # Interfaces
>> #
>> CONFIG_XENO_SKIN_NATIVE=y
>>
>> #
>> # Native interface options
>> #
>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>> CONFIG_XENO_OPT_NATIVE_SEM=y
>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>> CONFIG_XENO_OPT_NATIVE_COND=y
>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>> CONFIG_XENO_OPT_NATIVE_MPS=y
>> # CONFIG_XENO_OPT_NATIVE_INTR is not set
>> CONFIG_XENO_SKIN_POSIX=y
>>
>> and in the kernel:
>> # Interfaces
>> #
>> CONFIG_XENO_SKIN_NATIVE=y
>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
>> CONFIG_XENO_OPT_NATIVE_SEM=y
>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>> CONFIG_XENO_OPT_NATIVE_COND=y
>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>> CONFIG_XENO_OPT_NATIVE_BUFFER=y
>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>> CONFIG_XENO_OPT_NATIVE_MPS=y
>> CONFIG_XENO_OPT_NATIVE_INTR=y
>> CONFIG_XENO_OPT_DEBUG_NATIVE=y
>> CONFIG_XENO_SKIN_POSIX=y
>> CONFIG_XENO_OPT_POSIX_PERIOD=0
>> CONFIG_XENO_OPT_POSIX_SHM=y
>> CONFIG_XENO_OPT_POSIX_INTR=y
>> CONFIG_XENO_OPT_POSIX_SELECT=y
>> CONFIG_XENO_OPT_DEBUG_POSIX=y
>> # CONFIG_XENO_SKIN_PSOS is not set
>> # CONFIG_XENO_SKIN_UITRON is not set
>> # CONFIG_XENO_SKIN_VRTX is not set
>> CONFIG_XENO_SKIN_VXWORKS=y
>> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
>> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
>> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
>> CONFIG_XENO_SKIN_RTDM=y
>> CONFIG_XENO_OPT_RTDM_PERIOD=0
>> CONFIG_XENO_OPT_RTDM_FILDES=128
>> CONFIG_XENO_OPT_RTDM_SELECT=y
>> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
>> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>>
>>
>> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>>>
>>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>>
>>>>
>>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>>> work except latency. What can i do?
>>>>
>>>
>>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>>
>>>> /root>    switchbench
>>>> bash: switchbench: command not found
>>>> /root>    switchtest
>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>> /root>    cyclictest
>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>> /root>    latency
>>>> == Sampling period: 100 us
>>>> == Test mode: periodic user-mode task
>>>> == All results in microseconds
>>>>
>>>> /root>    xeno-test
>>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>>> /usr/xenomai/bin/xeno-test
>>>> ++ echo 0
>>>> ++ /usr/xenomai/bin/arith
>>>> mul: 0x79364d93, shft: 26
>>>> integ: 30, frac: 0x4d9364d9364d9364
>>>>
>>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
>>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000
>>>>
>>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
>>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000
>>>>
>>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
>>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected
>>>> 1/10000
>>>> ++ /usr/xenomai/bin/clocktest -T 30
>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>>
>>>>
>>>> Only latency seems working.
>>>>
>>>> _______________________________________________
>>>> Xenomai mailing list
>>>> Xenomai@xenomai.org
>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>
>>>
>>>
>>> --
>>> Philippe.
>>
>>
>
>
> --
> Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 11:18 AM, ali hagigat wrote:
> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd command:
>

http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html

> /usr/xenomai/bin>  ldd switchtest
> 	linux-gate.so.1 =>   (0xb786c000)
> 	libpthread_rt.so.1 =>  /usr/xenomai/lib/libpthread_rt.so.1 (0xb785f000)
> 	libxenomai.so.0 =>  /usr/xenomai/lib/libxenomai.so.0 (0xb7859000)
> 	libpthread.so.0 =>  /lib/libpthread.so.0 (0x0058e000)
> 	librt.so.1 =>  /lib/librt.so.1 (0x005c3000)
> 	libc.so.6 =>  /lib/libc.so.6 (0x003cd000)
> 	/lib/ld-linux.so.2 (0x003a7000)
> /usr/xenomai/bin>  ldd switchbench
> ldd: ./switchbench: No such file or directory
> /usr/xenomai/bin>  cd /root
> /root>  ldd switchtest
> ldd: ./switchtest: No such file or directory
>
>
> On Wed, Jun 6, 2012 at 1:41 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 06/06/2012 11:06 AM, ali hagigat wrote:
>>>
>>> Thank you, Philippe, for the reply.
>>>
>>> How can i enable posix skin? should i do , make menuconfig, for the
>>> kernel? Or i should change scripts/defconfig.frag?
>>>
>>> It seems that both places have the correct values already but i still
>>> have the error:
>>
>>
>> The POSIX skin is indeed enabled. What is the output of the command below?
>>
>> # ldd<your-executable>
>>
>>
>>>
>>> defconfig.frag:
>>> #
>>> # Interfaces
>>> #
>>> CONFIG_XENO_SKIN_NATIVE=y
>>>
>>> #
>>> # Native interface options
>>> #
>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>> # CONFIG_XENO_OPT_NATIVE_INTR is not set
>>> CONFIG_XENO_SKIN_POSIX=y
>>>
>>> and in the kernel:
>>> # Interfaces
>>> #
>>> CONFIG_XENO_SKIN_NATIVE=y
>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>> CONFIG_XENO_OPT_NATIVE_BUFFER=y
>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>> CONFIG_XENO_OPT_NATIVE_INTR=y
>>> CONFIG_XENO_OPT_DEBUG_NATIVE=y
>>> CONFIG_XENO_SKIN_POSIX=y
>>> CONFIG_XENO_OPT_POSIX_PERIOD=0
>>> CONFIG_XENO_OPT_POSIX_SHM=y
>>> CONFIG_XENO_OPT_POSIX_INTR=y
>>> CONFIG_XENO_OPT_POSIX_SELECT=y
>>> CONFIG_XENO_OPT_DEBUG_POSIX=y
>>> # CONFIG_XENO_SKIN_PSOS is not set
>>> # CONFIG_XENO_SKIN_UITRON is not set
>>> # CONFIG_XENO_SKIN_VRTX is not set
>>> CONFIG_XENO_SKIN_VXWORKS=y
>>> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
>>> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
>>> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
>>> CONFIG_XENO_SKIN_RTDM=y
>>> CONFIG_XENO_OPT_RTDM_PERIOD=0
>>> CONFIG_XENO_OPT_RTDM_FILDES=128
>>> CONFIG_XENO_OPT_RTDM_SELECT=y
>>> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
>>> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>>>
>>>
>>> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org>    wrote:
>>>>
>>>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>>>
>>>>>
>>>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>>>> work except latency. What can i do?
>>>>>
>>>>
>>>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>>>
>>>>> /root>      switchbench
>>>>> bash: switchbench: command not found
>>>>> /root>      switchtest
>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>>> /root>      cyclictest
>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>>> /root>      latency
>>>>> == Sampling period: 100 us
>>>>> == Test mode: periodic user-mode task
>>>>> == All results in microseconds
>>>>>
>>>>> /root>      xeno-test
>>>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>>>> /usr/xenomai/bin/xeno-test
>>>>> ++ echo 0
>>>>> ++ /usr/xenomai/bin/arith
>>>>> mul: 0x79364d93, shft: 26
>>>>> integ: 30, frac: 0x4d9364d9364d9364
>>>>>
>>>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 0/10000
>>>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 1/10000
>>>>>
>>>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 1/10000
>>>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>>>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 1/10000
>>>>>
>>>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 0/10000
>>>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected
>>>>> 1/10000
>>>>> ++ /usr/xenomai/bin/clocktest -T 30
>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not implemented
>>>>>
>>>>>
>>>>> Only latency seems working.
>>>>>
>>>>> _______________________________________________
>>>>> Xenomai mailing list
>>>>> Xenomai@xenomai.org
>>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>>
>>>>
>>>>
>>>> --
>>>> Philippe.
>>>
>>>
>>
>>
>> --
>> Philippe.
>


-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[ali hagigat]

I still have the problem:

/root/build/xenomai/xenomai-2.6.0> ./configure --enable-smp
CFLAGS=-fno-omit-frame-pointers
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/root/build/xenomai/xenomai-2.6.0':
configure: error: C compiler cannot create executables
See `config.log' for more details


On Wed, Jun 6, 2012 at 2:18 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>
>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>> command:
>>
>
> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>
>
>> /usr/xenomai/bin>  ldd switchtest
>>        linux-gate.so.1 =>   (0xb786c000)
>>        libpthread_rt.so.1 =>  /usr/xenomai/lib/libpthread_rt.so.1
>> (0xb785f000)
>>        libxenomai.so.0 =>  /usr/xenomai/lib/libxenomai.so.0 (0xb7859000)
>>        libpthread.so.0 =>  /lib/libpthread.so.0 (0x0058e000)
>>        librt.so.1 =>  /lib/librt.so.1 (0x005c3000)
>>        libc.so.6 =>  /lib/libc.so.6 (0x003cd000)
>>        /lib/ld-linux.so.2 (0x003a7000)
>> /usr/xenomai/bin>  ldd switchbench
>> ldd: ./switchbench: No such file or directory
>> /usr/xenomai/bin>  cd /root
>> /root>  ldd switchtest
>> ldd: ./switchtest: No such file or directory
>>
>>
>> On Wed, Jun 6, 2012 at 1:41 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>>>
>>> On 06/06/2012 11:06 AM, ali hagigat wrote:
>>>>
>>>>
>>>> Thank you, Philippe, for the reply.
>>>>
>>>> How can i enable posix skin? should i do , make menuconfig, for the
>>>> kernel? Or i should change scripts/defconfig.frag?
>>>>
>>>> It seems that both places have the correct values already but i still
>>>> have the error:
>>>
>>>
>>>
>>> The POSIX skin is indeed enabled. What is the output of the command
>>> below?
>>>
>>> # ldd<your-executable>
>>>
>>>
>>>>
>>>> defconfig.frag:
>>>> #
>>>> # Interfaces
>>>> #
>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>>
>>>> #
>>>> # Native interface options
>>>> #
>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>> # CONFIG_XENO_OPT_NATIVE_INTR is not set
>>>> CONFIG_XENO_SKIN_POSIX=y
>>>>
>>>> and in the kernel:
>>>> # Interfaces
>>>> #
>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>> CONFIG_XENO_OPT_NATIVE_BUFFER=y
>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>> CONFIG_XENO_OPT_NATIVE_INTR=y
>>>> CONFIG_XENO_OPT_DEBUG_NATIVE=y
>>>> CONFIG_XENO_SKIN_POSIX=y
>>>> CONFIG_XENO_OPT_POSIX_PERIOD=0
>>>> CONFIG_XENO_OPT_POSIX_SHM=y
>>>> CONFIG_XENO_OPT_POSIX_INTR=y
>>>> CONFIG_XENO_OPT_POSIX_SELECT=y
>>>> CONFIG_XENO_OPT_DEBUG_POSIX=y
>>>> # CONFIG_XENO_SKIN_PSOS is not set
>>>> # CONFIG_XENO_SKIN_UITRON is not set
>>>> # CONFIG_XENO_SKIN_VRTX is not set
>>>> CONFIG_XENO_SKIN_VXWORKS=y
>>>> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
>>>> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
>>>> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
>>>> CONFIG_XENO_SKIN_RTDM=y
>>>> CONFIG_XENO_OPT_RTDM_PERIOD=0
>>>> CONFIG_XENO_OPT_RTDM_FILDES=128
>>>> CONFIG_XENO_OPT_RTDM_SELECT=y
>>>> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
>>>> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>>>>
>>>>
>>>> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org>
>>>>  wrote:
>>>>>
>>>>>
>>>>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>>>>> work except latency. What can i do?
>>>>>>
>>>>>
>>>>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>>>>
>>>>>> /root>      switchbench
>>>>>> bash: switchbench: command not found
>>>>>> /root>      switchtest
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>> implemented
>>>>>> /root>      cyclictest
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>> implemented
>>>>>> /root>      latency
>>>>>> == Sampling period: 100 us
>>>>>> == Test mode: periodic user-mode task
>>>>>> == All results in microseconds
>>>>>>
>>>>>> /root>      xeno-test
>>>>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>>>>> /usr/xenomai/bin/xeno-test
>>>>>> ++ echo 0
>>>>>> ++ /usr/xenomai/bin/arith
>>>>>> mul: 0x79364d93, shft: 26
>>>>>> integ: 30, frac: 0x4d9364d9364d9364
>>>>>>
>>>>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>>>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>>>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>>>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected
>>>>>> 0/10000
>>>>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>>>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>>>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected
>>>>>> 1/10000
>>>>>>
>>>>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>>>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>>>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>>>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected
>>>>>> 1/10000
>>>>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>>>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>>>>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected
>>>>>> 1/10000
>>>>>>
>>>>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>>>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected
>>>>>> 0/10000
>>>>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected
>>>>>> 1/10000
>>>>>> ++ /usr/xenomai/bin/clocktest -T 30
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>> implemented
>>>>>>
>>>>>>
>>>>>> Only latency seems working.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xenomai mailing list
>>>>>> Xenomai@xenomai.org
>>>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Philippe.
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Philippe.
>>
>>
>
>
> --
> Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 12:47 PM, ali hagigat wrote:
> I still have the problem:
>

This is obviously not the same problem.

> /root/build/xenomai/xenomai-2.6.0>  ./configure --enable-smp
> CFLAGS=-fno-omit-frame-pointers
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/root/build/xenomai/xenomai-2.6.0':
> configure: error: C compiler cannot create executables
> See `config.log' for more details

What about doing what the tool recommends? config.log chokes on the 
option due to the extraneous 's'.

It's -fno-omit-frame-pointer.

>
> On Wed, Jun 6, 2012 at 2:18 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>
>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>> command:
>>>
>>
>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>
>>
>>> /usr/xenomai/bin>    ldd switchtest
>>>         linux-gate.so.1 =>     (0xb786c000)
>>>         libpthread_rt.so.1 =>    /usr/xenomai/lib/libpthread_rt.so.1
>>> (0xb785f000)
>>>         libxenomai.so.0 =>    /usr/xenomai/lib/libxenomai.so.0 (0xb7859000)
>>>         libpthread.so.0 =>    /lib/libpthread.so.0 (0x0058e000)
>>>         librt.so.1 =>    /lib/librt.so.1 (0x005c3000)
>>>         libc.so.6 =>    /lib/libc.so.6 (0x003cd000)
>>>         /lib/ld-linux.so.2 (0x003a7000)
>>> /usr/xenomai/bin>    ldd switchbench
>>> ldd: ./switchbench: No such file or directory
>>> /usr/xenomai/bin>    cd /root
>>> /root>    ldd switchtest
>>> ldd: ./switchtest: No such file or directory
>>>
>>>
>>> On Wed, Jun 6, 2012 at 1:41 PM, Philippe Gerum<rpm@xenomai.org>    wrote:
>>>>
>>>> On 06/06/2012 11:06 AM, ali hagigat wrote:
>>>>>
>>>>>
>>>>> Thank you, Philippe, for the reply.
>>>>>
>>>>> How can i enable posix skin? should i do , make menuconfig, for the
>>>>> kernel? Or i should change scripts/defconfig.frag?
>>>>>
>>>>> It seems that both places have the correct values already but i still
>>>>> have the error:
>>>>
>>>>
>>>>
>>>> The POSIX skin is indeed enabled. What is the output of the command
>>>> below?
>>>>
>>>> # ldd<your-executable>
>>>>
>>>>
>>>>>
>>>>> defconfig.frag:
>>>>> #
>>>>> # Interfaces
>>>>> #
>>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>>>
>>>>> #
>>>>> # Native interface options
>>>>> #
>>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>>> # CONFIG_XENO_OPT_NATIVE_INTR is not set
>>>>> CONFIG_XENO_SKIN_POSIX=y
>>>>>
>>>>> and in the kernel:
>>>>> # Interfaces
>>>>> #
>>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
>>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>>> CONFIG_XENO_OPT_NATIVE_BUFFER=y
>>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>>> CONFIG_XENO_OPT_NATIVE_INTR=y
>>>>> CONFIG_XENO_OPT_DEBUG_NATIVE=y
>>>>> CONFIG_XENO_SKIN_POSIX=y
>>>>> CONFIG_XENO_OPT_POSIX_PERIOD=0
>>>>> CONFIG_XENO_OPT_POSIX_SHM=y
>>>>> CONFIG_XENO_OPT_POSIX_INTR=y
>>>>> CONFIG_XENO_OPT_POSIX_SELECT=y
>>>>> CONFIG_XENO_OPT_DEBUG_POSIX=y
>>>>> # CONFIG_XENO_SKIN_PSOS is not set
>>>>> # CONFIG_XENO_SKIN_UITRON is not set
>>>>> # CONFIG_XENO_SKIN_VRTX is not set
>>>>> CONFIG_XENO_SKIN_VXWORKS=y
>>>>> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
>>>>> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
>>>>> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
>>>>> CONFIG_XENO_SKIN_RTDM=y
>>>>> CONFIG_XENO_OPT_RTDM_PERIOD=0
>>>>> CONFIG_XENO_OPT_RTDM_FILDES=128
>>>>> CONFIG_XENO_OPT_RTDM_SELECT=y
>>>>> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
>>>>> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>>>>>
>>>>>
>>>>> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org>
>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>>>>>> work except latency. What can i do?
>>>>>>>
>>>>>>
>>>>>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>>>>>
>>>>>>> /root>        switchbench
>>>>>>> bash: switchbench: command not found
>>>>>>> /root>        switchtest
>>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>>> implemented
>>>>>>> /root>        cyclictest
>>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>>> implemented
>>>>>>> /root>        latency
>>>>>>> == Sampling period: 100 us
>>>>>>> == Test mode: periodic user-mode task
>>>>>>> == All results in microseconds
>>>>>>>
>>>>>>> /root>        xeno-test
>>>>>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>>>>>> /usr/xenomai/bin/xeno-test
>>>>>>> ++ echo 0
>>>>>>> ++ /usr/xenomai/bin/arith
>>>>>>> mul: 0x79364d93, shft: 26
>>>>>>> integ: 30, frac: 0x4d9364d9364d9364
>>>>>>>
>>>>>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>>>>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>>>>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>>>>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>>>>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected
>>>>>>> 0/10000
>>>>>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>>>>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>>>>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected
>>>>>>> 1/10000
>>>>>>>
>>>>>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>>>>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>>>>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>>>>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>>>>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>>>>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected
>>>>>>> 1/10000
>>>>>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>>>>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 1/10000
>>>>>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected
>>>>>>> 1/10000
>>>>>>>
>>>>>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>>>>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>>>>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected
>>>>>>> 0/10000
>>>>>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected
>>>>>>> 1/10000
>>>>>>> ++ /usr/xenomai/bin/clocktest -T 30
>>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not
>>>>>>> implemented
>>>>>>>
>>>>>>>
>>>>>>> Only latency seems working.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xenomai mailing list
>>>>>>> Xenomai@xenomai.org
>>>>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Philippe.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Philippe.
>>>
>>>
>>
>>
>> --
>> Philippe.
>


-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 11:48 AM, Philippe Gerum wrote:
> On 06/06/2012 11:18 AM, ali hagigat wrote:
>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd 
>> command:
>>
> 
> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html

Alternatively, this patch may work as well (not tested, but this
looks like a former issue we had with aggressive optimizers):

diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
index 7a338a0..9c7849e 100644
--- a/src/skins/posix/init.c
+++ b/src/skins/posix/init.c
@@ -43,6 +43,7 @@ void pse51_clock_init(int);
 static __attribute__ ((constructor))
 void __init_posix_interface(void)
 {
+	volatile pthread_t tid = pthread_self();
 #ifndef CONFIG_XENO_LIBS_DLOPEN
 	struct sched_param parm;
 	int policy;
@@ -80,14 +81,14 @@ void __init_posix_interface(void)
 
 	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
 #ifndef CONFIG_XENO_LIBS_DLOPEN
-	err = __real_pthread_getschedparam(pthread_self(), &policy, &parm);
+	err = __real_pthread_getschedparam(tid, &policy, &parm);
 	if (err) {
 		fprintf(stderr, "Xenomai Posix skin init: "
 			"pthread_getschedparam: %s\n", strerror(err));
 		exit(EXIT_FAILURE);
 	}
 
-	err = __wrap_pthread_setschedparam(pthread_self(), policy, &parm);
+	err = __wrap_pthread_setschedparam(tid, policy, &parm);
 	if (err) {
 		fprintf(stderr, "Xenomai Posix skin init: "
 			"pthread_setschedparam: %s\n", strerror(err));
> 
>> /usr/xenomai/bin> ldd switchtest
>> linux-gate.so.1 => (0xb786c000)
>> libpthread_rt.so.1 => /usr/xenomai/lib/libpthread_rt.so.1 (0xb785f000)
>> libxenomai.so.0 => /usr/xenomai/lib/libxenomai.so.0 (0xb7859000)
>> libpthread.so.0 => /lib/libpthread.so.0 (0x0058e000)
>> librt.so.1 => /lib/librt.so.1 (0x005c3000)
>> libc.so.6 => /lib/libc.so.6 (0x003cd000)
>> /lib/ld-linux.so.2 (0x003a7000)
>> /usr/xenomai/bin> ldd switchbench
>> ldd: ./switchbench: No such file or directory
>> /usr/xenomai/bin> cd /root
>> /root> ldd switchtest
>> ldd: ./switchtest: No such file or directory
>>
>>
>> On Wed, Jun 6, 2012 at 1:41 PM, Philippe Gerum<rpm@xenomai.org> wrote:
>>> On 06/06/2012 11:06 AM, ali hagigat wrote:
>>>>
>>>> Thank you, Philippe, for the reply.
>>>>
>>>> How can i enable posix skin? should i do , make menuconfig, for the
>>>> kernel? Or i should change scripts/defconfig.frag?
>>>>
>>>> It seems that both places have the correct values already but i still
>>>> have the error:
>>>
>>>
>>> The POSIX skin is indeed enabled. What is the output of the command 
>>> below?
>>>
>>> # ldd<your-executable>
>>>
>>>
>>>>
>>>> defconfig.frag:
>>>> #
>>>> # Interfaces
>>>> #
>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>>
>>>> #
>>>> # Native interface options
>>>> #
>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>> # CONFIG_XENO_OPT_NATIVE_INTR is not set
>>>> CONFIG_XENO_SKIN_POSIX=y
>>>>
>>>> and in the kernel:
>>>> # Interfaces
>>>> #
>>>> CONFIG_XENO_SKIN_NATIVE=y
>>>> CONFIG_XENO_OPT_NATIVE_PERIOD=0
>>>> CONFIG_XENO_OPT_NATIVE_PIPE=y
>>>> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
>>>> CONFIG_XENO_OPT_NATIVE_SEM=y
>>>> CONFIG_XENO_OPT_NATIVE_EVENT=y
>>>> CONFIG_XENO_OPT_NATIVE_MUTEX=y
>>>> CONFIG_XENO_OPT_NATIVE_COND=y
>>>> CONFIG_XENO_OPT_NATIVE_QUEUE=y
>>>> CONFIG_XENO_OPT_NATIVE_BUFFER=y
>>>> CONFIG_XENO_OPT_NATIVE_HEAP=y
>>>> CONFIG_XENO_OPT_NATIVE_ALARM=y
>>>> CONFIG_XENO_OPT_NATIVE_MPS=y
>>>> CONFIG_XENO_OPT_NATIVE_INTR=y
>>>> CONFIG_XENO_OPT_DEBUG_NATIVE=y
>>>> CONFIG_XENO_SKIN_POSIX=y
>>>> CONFIG_XENO_OPT_POSIX_PERIOD=0
>>>> CONFIG_XENO_OPT_POSIX_SHM=y
>>>> CONFIG_XENO_OPT_POSIX_INTR=y
>>>> CONFIG_XENO_OPT_POSIX_SELECT=y
>>>> CONFIG_XENO_OPT_DEBUG_POSIX=y
>>>> # CONFIG_XENO_SKIN_PSOS is not set
>>>> # CONFIG_XENO_SKIN_UITRON is not set
>>>> # CONFIG_XENO_SKIN_VRTX is not set
>>>> CONFIG_XENO_SKIN_VXWORKS=y
>>>> CONFIG_XENO_OPT_VXWORKS_PERIOD=1000
>>>> CONFIG_XENO_OPT_DEBUG_VXWORKS=y
>>>> # CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
>>>> CONFIG_XENO_SKIN_RTDM=y
>>>> CONFIG_XENO_OPT_RTDM_PERIOD=0
>>>> CONFIG_XENO_OPT_RTDM_FILDES=128
>>>> CONFIG_XENO_OPT_RTDM_SELECT=y
>>>> # CONFIG_XENO_OPT_DEBUG_RTDM is not set
>>>> CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
>>>>
>>>>
>>>> On Wed, Jun 6, 2012 at 1:00 PM, Philippe Gerum<rpm@xenomai.org> wrote:
>>>>>
>>>>> On 06/06/2012 09:40 AM, ali hagigat wrote:
>>>>>>
>>>>>>
>>>>>> I have installed xenomai-2.6.0. None of the instrumentation commands
>>>>>> work except latency. What can i do?
>>>>>>
>>>>>
>>>>> Likely fix your Kconfig. Enable the Xenomai POSIX skin.
>>>>>
>>>>>> /root> switchbench
>>>>>> bash: switchbench: command not found
>>>>>> /root> switchtest
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not 
>>>>>> implemented
>>>>>> /root> cyclictest
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not 
>>>>>> implemented
>>>>>> /root> latency
>>>>>> == Sampling period: 100 us
>>>>>> == Test mode: periodic user-mode task
>>>>>> == All results in microseconds
>>>>>>
>>>>>> /root> xeno-test
>>>>>> Started child 7172: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper
>>>>>> /usr/xenomai/bin/xeno-test
>>>>>> ++ echo 0
>>>>>> ++ /usr/xenomai/bin/arith
>>>>>> mul: 0x79364d93, shft: 26
>>>>>> integ: 30, frac: 0x4d9364d9364d9364
>>>>>>
>>>>>> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 28.751 ns, rejected 1/10000
>>>>>> inlined llimd: 0x79364d9364d9362f: 41.292 ns, rejected 1/10000
>>>>>> inlined llmulshft: 0x79364d92ffffffe1: 5.007 ns, rejected 0/10000
>>>>>> inlined nodiv_llimd: 0x79364d9364d9362f: 11.323 ns, rejected 1/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.003 ns, rejected 
>>>>>> 0/10000
>>>>>> out of line llimd: 0x79364d9364d9362f: 46.075 ns, rejected 1/10000
>>>>>> out of line llmulshft: 0x79364d92ffffffe1: 7.800 ns, rejected 1/10000
>>>>>> out of line nodiv_llimd: 0x79364d9364d9362f: 16.683 ns, rejected 
>>>>>> 1/10000
>>>>>>
>>>>>> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 29.298 ns, rejected 1/10000
>>>>>> inlined llimd: 0x86c9b26c9b26c9d1: 39.658 ns, rejected 1/10000
>>>>>> inlined llmulshft: 0x86c9b26d0000001e: 4.059 ns, rejected 0/10000
>>>>>> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 16.976 ns, rejected 0/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.002 ns, rejected 
>>>>>> 1/10000
>>>>>> out of line llimd: 0x86c9b26c9b26c9d1: 48.757 ns, rejected 0/10000
>>>>>> out of line llmulshft: 0x86c9b26d0000001e: 11.085 ns, rejected 
>>>>>> 1/10000
>>>>>> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 17.770 ns, rejected 
>>>>>> 1/10000
>>>>>>
>>>>>> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
>>>>>> inline calibration: 0x0000000000000000: 28.749 ns, rejected 1/10000
>>>>>> inlined nodiv_ullimd: 0x79364d9364d9362f: 16.264 ns, rejected 0/10000
>>>>>> out of line calibration: 0x0000000000000000: 30.001 ns, rejected 
>>>>>> 0/10000
>>>>>> out of line nodiv_ullimd: 0x79364d9364d9362f: 20.463 ns, rejected
>>>>>> 1/10000
>>>>>> ++ /usr/xenomai/bin/clocktest -T 30
>>>>>> Xenomai Posix skin init: pthread_setschedparam: Function not 
>>>>>> implemented
>>>>>>
>>>>>>
>>>>>> Only latency seems working.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xenomai mailing list
>>>>>> Xenomai@xenomai.org
>>>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Philippe.
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Philippe.
>>
> 
> 


-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 02:28 PM, Philippe Gerum wrote:
> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd 
>>> command:
>>>
>>
>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
> 
> Alternatively, this patch may work as well (not tested, but this
> looks like a former issue we had with aggressive optimizers):
> 
> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
> index 7a338a0..9c7849e 100644
> --- a/src/skins/posix/init.c
> +++ b/src/skins/posix/init.c
> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>  static __attribute__ ((constructor))
>  void __init_posix_interface(void)
>  {
> +	volatile pthread_t tid = pthread_self();
>  #ifndef CONFIG_XENO_LIBS_DLOPEN
>  	struct sched_param parm;
>  	int policy;
> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>  
>  	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>  #ifndef CONFIG_XENO_LIBS_DLOPEN
> -	err = __real_pthread_getschedparam(pthread_self(), &policy, &parm);
> +	err = __real_pthread_getschedparam(tid, &policy, &parm);
>  	if (err) {
>  		fprintf(stderr, "Xenomai Posix skin init: "
>  			"pthread_getschedparam: %s\n", strerror(err));
>  		exit(EXIT_FAILURE);
>  	}
>  
> -	err = __wrap_pthread_setschedparam(pthread_self(), policy, &parm);
> +	err = __wrap_pthread_setschedparam(tid, policy, &parm);
>  	if (err) {
>  		fprintf(stderr, "Xenomai Posix skin init: "
>  			"pthread_setschedparam: %s\n", strerror(err));

There should not be any issue here, as the pthread_self() is passed as
an argument to the called functions, the syscall is not inlined directly.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>> command:
>>>>
>>>
>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>
>> Alternatively, this patch may work as well (not tested, but this
>> looks like a former issue we had with aggressive optimizers):
>>
>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>> index 7a338a0..9c7849e 100644
>> --- a/src/skins/posix/init.c
>> +++ b/src/skins/posix/init.c
>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>   static __attribute__ ((constructor))
>>   void __init_posix_interface(void)
>>   {
>> +	volatile pthread_t tid = pthread_self();
>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>>   	struct sched_param parm;
>>   	int policy;
>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>
>>   	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>   	if (err) {
>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>   			"pthread_getschedparam: %s\n", strerror(err));
>>   		exit(EXIT_FAILURE);
>>   	}
>>
>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>   	if (err) {
>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>   			"pthread_setschedparam: %s\n", strerror(err));
>
> There should not be any issue here, as the pthread_self() is passed as
> an argument to the called functions, the syscall is not inlined directly.
>

Did you get any disassembly of the faulty code when suggesting 
-fno-omit-frame-pointer last time you did?

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 03:25 PM, Philippe Gerum wrote:
> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>> command:
>>>>>
>>>>
>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>
>>> Alternatively, this patch may work as well (not tested, but this
>>> looks like a former issue we had with aggressive optimizers):
>>>
>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>> index 7a338a0..9c7849e 100644
>>> --- a/src/skins/posix/init.c
>>> +++ b/src/skins/posix/init.c
>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>   static __attribute__ ((constructor))
>>>   void __init_posix_interface(void)
>>>   {
>>> +	volatile pthread_t tid = pthread_self();
>>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>   	struct sched_param parm;
>>>   	int policy;
>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>
>>>   	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>   	if (err) {
>>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>>   			"pthread_getschedparam: %s\n", strerror(err));
>>>   		exit(EXIT_FAILURE);
>>>   	}
>>>
>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>   	if (err) {
>>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>>   			"pthread_setschedparam: %s\n", strerror(err));
>>
>> There should not be any issue here, as the pthread_self() is passed as
>> an argument to the called functions, the syscall is not inlined directly.
>>
> 
> Did you get any disassembly of the faulty code when suggesting 
> -fno-omit-frame-pointer last time you did?
> 
No, but I had experienced the problem first hand.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>> command:
>>>>>>
>>>>>
>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>
>>>> Alternatively, this patch may work as well (not tested, but this
>>>> looks like a former issue we had with aggressive optimizers):
>>>>
>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>> index 7a338a0..9c7849e 100644
>>>> --- a/src/skins/posix/init.c
>>>> +++ b/src/skins/posix/init.c
>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>    static __attribute__ ((constructor))
>>>>    void __init_posix_interface(void)
>>>>    {
>>>> +	volatile pthread_t tid = pthread_self();
>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>    	struct sched_param parm;
>>>>    	int policy;
>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>
>>>>    	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>    	if (err) {
>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>    			"pthread_getschedparam: %s\n", strerror(err));
>>>>    		exit(EXIT_FAILURE);
>>>>    	}
>>>>
>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>    	if (err) {
>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>    			"pthread_setschedparam: %s\n", strerror(err));
>>>
>>> There should not be any issue here, as the pthread_self() is passed as
>>> an argument to the called functions, the syscall is not inlined directly.
>>>
>>
>> Did you get any disassembly of the faulty code when suggesting
>> -fno-omit-frame-pointer last time you did?
>>
> No, but I had experienced the problem first hand.
>

It would be interesting to know why we have to force a frame pointer in 
there. I'm not comfortable with voodoo fixing, that bug might bite later 
on as gcc's optimizer is unlikely to become less aggressive over time.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 03:53 PM, Philippe Gerum wrote:
> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>> command:
>>>>>>>
>>>>>>
>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>
>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>
>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>> index 7a338a0..9c7849e 100644
>>>>> --- a/src/skins/posix/init.c
>>>>> +++ b/src/skins/posix/init.c
>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>    static __attribute__ ((constructor))
>>>>>    void __init_posix_interface(void)
>>>>>    {
>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>    	struct sched_param parm;
>>>>>    	int policy;
>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>
>>>>>    	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>    	if (err) {
>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>    			"pthread_getschedparam: %s\n", strerror(err));
>>>>>    		exit(EXIT_FAILURE);
>>>>>    	}
>>>>>
>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>    	if (err) {
>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>    			"pthread_setschedparam: %s\n", strerror(err));
>>>>
>>>> There should not be any issue here, as the pthread_self() is passed as
>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>
>>>
>>> Did you get any disassembly of the faulty code when suggesting
>>> -fno-omit-frame-pointer last time you did?
>>>
>> No, but I had experienced the problem first hand.
>>
> 
> It would be interesting to know why we have to force a frame pointer in 
> there. I'm not comfortable with voodoo fixing, that bug might bite later 
> on as gcc's optimizer is unlikely to become less aggressive over time.
> 
Ah this, I know. I have posted a mail where I explained the problem. I
am a bit in a short schedule here, will post the link tonight.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>> command:
>>>>>>>>
>>>>>>>
>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>
>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>
>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>> index 7a338a0..9c7849e 100644
>>>>>> --- a/src/skins/posix/init.c
>>>>>> +++ b/src/skins/posix/init.c
>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>    static __attribute__ ((constructor))
>>>>>>    void __init_posix_interface(void)
>>>>>>    {
>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>    	struct sched_param parm;
>>>>>>    	int policy;
>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>
>>>>>>    	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>    	if (err) {
>>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>    			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>    		exit(EXIT_FAILURE);
>>>>>>    	}
>>>>>>
>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>    	if (err) {
>>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>    			"pthread_setschedparam: %s\n", strerror(err));
>>>>>
>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>
>>>>
>>>> Did you get any disassembly of the faulty code when suggesting
>>>> -fno-omit-frame-pointer last time you did?
>>>>
>>> No, but I had experienced the problem first hand.
>>>
>>
>> It would be interesting to know why we have to force a frame pointer in 
>> there. I'm not comfortable with voodoo fixing, that bug might bite later 
>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>
> Ah this, I know. I have posted a mail where I explained the problem. I
> am a bit in a short schedule here, will post the link tonight.
> 
http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>> command:
>>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>
>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>
>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>> --- a/src/skins/posix/init.c
>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>    static __attribute__ ((constructor))
>>>>>>>    void __init_posix_interface(void)
>>>>>>>    {
>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>    	struct sched_param parm;
>>>>>>>    	int policy;
>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>
>>>>>>>    	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>    #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>    	if (err) {
>>>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>    			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>    		exit(EXIT_FAILURE);
>>>>>>>    	}
>>>>>>>
>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>    	if (err) {
>>>>>>>    		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>    			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>
>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>
>>>>>
>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>> -fno-omit-frame-pointer last time you did?
>>>>>
>>>> No, but I had experienced the problem first hand.
>>>>
>>>
>>> It would be interesting to know why we have to force a frame pointer in 
>>> there. I'm not comfortable with voodoo fixing, that bug might bite later 
>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>
>> Ah this, I know. I have posted a mail where I explained the problem. I
>> am a bit in a short schedule here, will post the link tonight.
>>
> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
> 

In the mails following this one, I found how to fix the assembly to work
in the omit-frame-pointer case. The real problem is that, at compilation
time, we have no command-line #defined variable telling us whether
compiling with frame pointers enabled. And it does not seem easy to
write a configure test script, which tests whether frame pointers are
enabled or not.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>> command:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>
>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>
>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>     static __attribute__ ((constructor))
>>>>>>>>     void __init_posix_interface(void)
>>>>>>>>     {
>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>     	struct sched_param parm;
>>>>>>>>     	int policy;
>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>
>>>>>>>>     	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>     	if (err) {
>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>     			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>     		exit(EXIT_FAILURE);
>>>>>>>>     	}
>>>>>>>>
>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>     	if (err) {
>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>     			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>
>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>
>>>>>>
>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>
>>>>> No, but I had experienced the problem first hand.
>>>>>
>>>>
>>>> It would be interesting to know why we have to force a frame pointer in
>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>
>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>> am a bit in a short schedule here, will post the link tonight.
>>>
>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>
>
> In the mails following this one, I found how to fix the assembly to work
> in the omit-frame-pointer case. The real problem is that, at compilation
> time, we have no command-line #defined variable telling us whether
> compiling with frame pointers enabled. And it does not seem easy to
> write a configure test script, which tests whether frame pointers are
> enabled or not.
>

has_bp= && echo "void whee(void) { }" | gcc -fno-omit-frame-pointer -S 
-xc - -o - | grep -q "push[lq]\?.*%[er]bp" && echo has_bp=y

?

Yeah, ok...

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>> command:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>
>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>
>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>     static __attribute__ ((constructor))
>>>>>>>>     void __init_posix_interface(void)
>>>>>>>>     {
>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>     	struct sched_param parm;
>>>>>>>>     	int policy;
>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>
>>>>>>>>     	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>     	if (err) {
>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>     			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>     		exit(EXIT_FAILURE);
>>>>>>>>     	}
>>>>>>>>
>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>     	if (err) {
>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>     			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>
>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>
>>>>>>
>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>
>>>>> No, but I had experienced the problem first hand.
>>>>>
>>>>
>>>> It would be interesting to know why we have to force a frame pointer in
>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>
>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>> am a bit in a short schedule here, will post the link tonight.
>>>
>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>
>
> In the mails following this one, I found how to fix the assembly to work
> in the omit-frame-pointer case. The real problem is that, at compilation
> time, we have no command-line #defined variable telling us whether
> compiling with frame pointers enabled. And it does not seem easy to
> write a configure test script, which tests whether frame pointers are
> enabled or not.
>

I'd suggest that at some point, we move all the syscall trampolines out 
of line, and specifically build the resulting file forcing 
-fno-omit-frame-pointer. Such inlining will always be fragile until we 
actually control the way that compilation unit is built, regardless of 
the general settings for CFLAGS.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 05:03 PM, Philippe Gerum wrote:
> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>> command:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>
>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>
>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>     static __attribute__ ((constructor))
>>>>>>>>>     void __init_posix_interface(void)
>>>>>>>>>     {
>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>     	struct sched_param parm;
>>>>>>>>>     	int policy;
>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>
>>>>>>>>>     	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>     #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>     	if (err) {
>>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>     			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>     		exit(EXIT_FAILURE);
>>>>>>>>>     	}
>>>>>>>>>
>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>     	if (err) {
>>>>>>>>>     		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>     			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>
>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>
>>>>>>>
>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>
>>>>>> No, but I had experienced the problem first hand.
>>>>>>
>>>>>
>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>
>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>> am a bit in a short schedule here, will post the link tonight.
>>>>
>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>
>>
>> In the mails following this one, I found how to fix the assembly to work
>> in the omit-frame-pointer case. The real problem is that, at compilation
>> time, we have no command-line #defined variable telling us whether
>> compiling with frame pointers enabled. And it does not seem easy to
>> write a configure test script, which tests whether frame pointers are
>> enabled or not.
>>
> 
> I'd suggest that at some point, we move all the syscall trampolines out 
> of line, and specifically build the resulting file forcing 
> -fno-omit-frame-pointer. Such inlining will always be fragile until we 
> actually control the way that compilation unit is built, regardless of 
> the general settings for CFLAGS.
> 
In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>> command:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>
>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>
>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>      static __attribute__ ((constructor))
>>>>>>>>>>      void __init_posix_interface(void)
>>>>>>>>>>      {
>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>      	struct sched_param parm;
>>>>>>>>>>      	int policy;
>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>
>>>>>>>>>>      	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>      	if (err) {
>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>      			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>      		exit(EXIT_FAILURE);
>>>>>>>>>>      	}
>>>>>>>>>>
>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>      	if (err) {
>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>      			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>
>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>
>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>
>>>>>>
>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>
>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>
>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>
>>>
>>> In the mails following this one, I found how to fix the assembly to work
>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>> time, we have no command-line #defined variable telling us whether
>>> compiling with frame pointers enabled. And it does not seem easy to
>>> write a configure test script, which tests whether frame pointers are
>>> enabled or not.
>>>
>>
>> I'd suggest that at some point, we move all the syscall trampolines out
>> of line, and specifically build the resulting file forcing
>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>> actually control the way that compilation unit is built, regardless of
>> the general settings for CFLAGS.
>>
> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>

Yes, but that is crappy. The point is that we don't want to force this 
for all userland bits. We'd only need this for syscall trampolines.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 05:21 PM, Philippe Gerum wrote:
> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>>> command:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>
>>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>      static __attribute__ ((constructor))
>>>>>>>>>>>      void __init_posix_interface(void)
>>>>>>>>>>>      {
>>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>      	struct sched_param parm;
>>>>>>>>>>>      	int policy;
>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>
>>>>>>>>>>>      	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>      	if (err) {
>>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>      			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>      		exit(EXIT_FAILURE);
>>>>>>>>>>>      	}
>>>>>>>>>>>
>>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>      	if (err) {
>>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>      			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>
>>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>
>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>
>>>>>>>
>>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>>
>>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>
>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>
>>>>
>>>> In the mails following this one, I found how to fix the assembly to work
>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>> time, we have no command-line #defined variable telling us whether
>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>> write a configure test script, which tests whether frame pointers are
>>>> enabled or not.
>>>>
>>>
>>> I'd suggest that at some point, we move all the syscall trampolines out
>>> of line, and specifically build the resulting file forcing
>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>> actually control the way that compilation unit is built, regardless of
>>> the general settings for CFLAGS.
>>>
>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>
> 
> Yes, but that is crappy. The point is that we don't want to force this 
> for all userland bits. We'd only need this for syscall trampolines.
> 
We currently have different flags for compiling xenomai than for passing
to the applications (via xeno-config). The problem is that I am not sure
it will not break for instance calling "backtrace" in gdb when breaking
inside a xenomai function.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>
>>>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>      static __attribute__ ((constructor))
>>>>>>>>>>>>      void __init_posix_interface(void)
>>>>>>>>>>>>      {
>>>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>      	struct sched_param parm;
>>>>>>>>>>>>      	int policy;
>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>
>>>>>>>>>>>>      	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>>>      #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>      	if (err) {
>>>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>      			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>      		exit(EXIT_FAILURE);
>>>>>>>>>>>>      	}
>>>>>>>>>>>>
>>>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>      	if (err) {
>>>>>>>>>>>>      		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>      			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>
>>>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>
>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>>>
>>>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>
>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>
>>>>>
>>>>> In the mails following this one, I found how to fix the assembly to work
>>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>>> time, we have no command-line #defined variable telling us whether
>>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>>> write a configure test script, which tests whether frame pointers are
>>>>> enabled or not.
>>>>>
>>>>
>>>> I'd suggest that at some point, we move all the syscall trampolines out
>>>> of line, and specifically build the resulting file forcing
>>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>>> actually control the way that compilation unit is built, regardless of
>>>> the general settings for CFLAGS.
>>>>
>>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>>
>>
>> Yes, but that is crappy. The point is that we don't want to force this 
>> for all userland bits. We'd only need this for syscall trampolines.
>>
> We currently have different flags for compiling xenomai than for passing
> to the applications (via xeno-config). The problem is that I am not sure
> it will not break for instance calling "backtrace" in gdb when breaking
> inside a xenomai function.
> 
(mixing code compiled without frame pointers with code compiled with
frame pointers I mean).

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>       static __attribute__ ((constructor))
>>>>>>>>>>>>>       void __init_posix_interface(void)
>>>>>>>>>>>>>       {
>>>>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>       #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>       	struct sched_param parm;
>>>>>>>>>>>>>       	int policy;
>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>
>>>>>>>>>>>>>       	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>>>>       #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>       	if (err) {
>>>>>>>>>>>>>       		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>       			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>       		exit(EXIT_FAILURE);
>>>>>>>>>>>>>       	}
>>>>>>>>>>>>>
>>>>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>       	if (err) {
>>>>>>>>>>>>>       		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>       			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>
>>>>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>
>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>>>>
>>>>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>
>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>
>>>>>>
>>>>>> In the mails following this one, I found how to fix the assembly to work
>>>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>>>> write a configure test script, which tests whether frame pointers are
>>>>>> enabled or not.
>>>>>>
>>>>>
>>>>> I'd suggest that at some point, we move all the syscall trampolines out
>>>>> of line, and specifically build the resulting file forcing
>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>>>> actually control the way that compilation unit is built, regardless of
>>>>> the general settings for CFLAGS.
>>>>>
>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>>>
>>>
>>> Yes, but that is crappy. The point is that we don't want to force this
>>> for all userland bits. We'd only need this for syscall trampolines.
>>>
>> We currently have different flags for compiling xenomai than for passing
>> to the applications (via xeno-config). The problem is that I am not sure
>> it will not break for instance calling "backtrace" in gdb when breaking
>> inside a xenomai function.
>>
> (mixing code compiled without frame pointers with code compiled with
> frame pointers I mean).
>

The only issue is with frame elimination starting with -O2 and above, 
otherwise the backtraces are clean over gdb (just checked), at least 
there does not seem to be any additional problem introduced by mixing bp 
and no-bp. At any rate, -O0 -g is recommended to get clean and detailed 
(back)traces anyway, and this is what we pick when --enable-debug is given.

We should move each existing inline XENOMAI_SYS/SKINCALL macro into its 
own C trampoline, group all trampolines into separate compilation units, 
and build each of these units with -fno-omit-frame-pointer unconditionally.

-forge is a good candidate for this, since the number of syscall 
trampolines shrunk dramatically compared to 2.x. If any issue would be 
easily detected based on the output of the new "slackspot" tracer we 
have there.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/08/2012 11:20 AM, Philippe Gerum wrote:
> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>>       static __attribute__ ((constructor))
>>>>>>>>>>>>>>       void __init_posix_interface(void)
>>>>>>>>>>>>>>       {
>>>>>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>>       #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>       	struct sched_param parm;
>>>>>>>>>>>>>>       	int policy;
>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>       	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>>>>>       #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>>       	if (err) {
>>>>>>>>>>>>>>       		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>       			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>       		exit(EXIT_FAILURE);
>>>>>>>>>>>>>>       	}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>>       	if (err) {
>>>>>>>>>>>>>>       		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>       			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>
>>>>>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>>
>>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>>>>>
>>>>>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>>
>>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>>
>>>>>>>
>>>>>>> In the mails following this one, I found how to fix the assembly to work
>>>>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>>>>> write a configure test script, which tests whether frame pointers are
>>>>>>> enabled or not.
>>>>>>>
>>>>>>
>>>>>> I'd suggest that at some point, we move all the syscall trampolines out
>>>>>> of line, and specifically build the resulting file forcing
>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>>>>> actually control the way that compilation unit is built, regardless of
>>>>>> the general settings for CFLAGS.
>>>>>>
>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>>>>
>>>>
>>>> Yes, but that is crappy. The point is that we don't want to force this
>>>> for all userland bits. We'd only need this for syscall trampolines.
>>>>
>>> We currently have different flags for compiling xenomai than for passing
>>> to the applications (via xeno-config). The problem is that I am not sure
>>> it will not break for instance calling "backtrace" in gdb when breaking
>>> inside a xenomai function.
>>>
>> (mixing code compiled without frame pointers with code compiled with
>> frame pointers I mean).
>>
> 
> The only issue is with frame elimination starting with -O2 and above, 
> otherwise the backtraces are clean over gdb (just checked), at least 
> there does not seem to be any additional problem introduced by mixing bp 
> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed 
> (back)traces anyway, and this is what we pick when --enable-debug is given.
> 
> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its 
> own C trampoline, group all trampolines into separate compilation units, 
> and build each of these units with -fno-omit-frame-pointer unconditionally.
> 
> -forge is a good candidate for this, since the number of syscall 
> trampolines shrunk dramatically compared to 2.x. If any issue would be 
> easily detected based on the output of the new "slackspot" tracer we 
> have there.
> 
It looks to me like we can simply build xenomai libraries with
-fno-omit-frame-pointer, and compile the rest without this option. After
all, implementation of xenomai services are little more than syscall
trampolines.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote:
> On 06/08/2012 11:20 AM, Philippe Gerum wrote:
>> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested, but this
>>>>>>>>>>>>>>> looks like a former issue we had with aggressive optimizers):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>>>        static __attribute__ ((constructor))
>>>>>>>>>>>>>>>        void __init_posix_interface(void)
>>>>>>>>>>>>>>>        {
>>>>>>>>>>>>>>> +	volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>>>        #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>        	struct sched_param parm;
>>>>>>>>>>>>>>>        	int policy;
>>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>>>>>>>>>>>>>        #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>>>        	if (err) {
>>>>>>>>>>>>>>>        		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>        			"pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>        		exit(EXIT_FAILURE);
>>>>>>>>>>>>>>>        	}
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>>>>>>>>>>>>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>>>        	if (err) {
>>>>>>>>>>>>>>>        		fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>        			"pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There should not be any issue here, as the pthread_self() is passed as
>>>>>>>>>>>>>> an argument to the called functions, the syscall is not inlined directly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you get any disassembly of the faulty code when suggesting
>>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>>>
>>>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It would be interesting to know why we have to force a frame pointer in
>>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug might bite later
>>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive over time.
>>>>>>>>>>>
>>>>>>>>>> Ah this, I know. I have posted a mail where I explained the problem. I
>>>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>>>
>>>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>>>
>>>>>>>>
>>>>>>>> In the mails following this one, I found how to fix the assembly to work
>>>>>>>> in the omit-frame-pointer case. The real problem is that, at compilation
>>>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>>>> compiling with frame pointers enabled. And it does not seem easy to
>>>>>>>> write a configure test script, which tests whether frame pointers are
>>>>>>>> enabled or not.
>>>>>>>>
>>>>>>>
>>>>>>> I'd suggest that at some point, we move all the syscall trampolines out
>>>>>>> of line, and specifically build the resulting file forcing
>>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile until we
>>>>>>> actually control the way that compilation unit is built, regardless of
>>>>>>> the general settings for CFLAGS.
>>>>>>>
>>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer on x86_32.
>>>>>>
>>>>>
>>>>> Yes, but that is crappy. The point is that we don't want to force this
>>>>> for all userland bits. We'd only need this for syscall trampolines.
>>>>>
>>>> We currently have different flags for compiling xenomai than for passing
>>>> to the applications (via xeno-config). The problem is that I am not sure
>>>> it will not break for instance calling "backtrace" in gdb when breaking
>>>> inside a xenomai function.
>>>>
>>> (mixing code compiled without frame pointers with code compiled with
>>> frame pointers I mean).
>>>
>>
>> The only issue is with frame elimination starting with -O2 and above,
>> otherwise the backtraces are clean over gdb (just checked), at least
>> there does not seem to be any additional problem introduced by mixing bp
>> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed
>> (back)traces anyway, and this is what we pick when --enable-debug is given.
>>
>> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its
>> own C trampoline, group all trampolines into separate compilation units,
>> and build each of these units with -fno-omit-frame-pointer unconditionally.
>>
>> -forge is a good candidate for this, since the number of syscall
>> trampolines shrunk dramatically compared to 2.x. If any issue would be
>> easily detected based on the output of the new "slackspot" tracer we
>> have there.
>>
> It looks to me like we can simply build xenomai libraries with
> -fno-omit-frame-pointer, and compile the rest without this option. After
> all, implementation of xenomai services are little more than syscall
> trampolines.
>

This is true for 2.x, however -forge will need the other approach.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Philippe Gerum]

On 06/08/2012 11:29 AM, Philippe Gerum wrote:
> On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote:
>> On 06/08/2012 11:20 AM, Philippe Gerum wrote:
>>> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>>>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the
>>>>>>>>>>>>>>>>>> result of ldd
>>>>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested,
>>>>>>>>>>>>>>>> but this
>>>>>>>>>>>>>>>> looks like a former issue we had with aggressive
>>>>>>>>>>>>>>>> optimizers):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c
>>>>>>>>>>>>>>>> b/src/skins/posix/init.c
>>>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>>>> static __attribute__ ((constructor))
>>>>>>>>>>>>>>>> void __init_posix_interface(void)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> + volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>> struct sched_param parm;
>>>>>>>>>>>>>>>> int policy;
>>>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /* Don't use auto-shadowing if we are likely invoked
>>>>>>>>>>>>>>>> from dlopen. */
>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>> - err =
>>>>>>>>>>>>>>>> __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>>>>> + err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>> "pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>> exit(EXIT_FAILURE);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - err = __wrap_pthread_setschedparam(pthread_self(),
>>>>>>>>>>>>>>>> policy,&parm);
>>>>>>>>>>>>>>>> + err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>> "pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There should not be any issue here, as the pthread_self()
>>>>>>>>>>>>>>> is passed as
>>>>>>>>>>>>>>> an argument to the called functions, the syscall is not
>>>>>>>>>>>>>>> inlined directly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you get any disassembly of the faulty code when
>>>>>>>>>>>>>> suggesting
>>>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It would be interesting to know why we have to force a frame
>>>>>>>>>>>> pointer in
>>>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug
>>>>>>>>>>>> might bite later
>>>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive
>>>>>>>>>>>> over time.
>>>>>>>>>>>>
>>>>>>>>>>> Ah this, I know. I have posted a mail where I explained the
>>>>>>>>>>> problem. I
>>>>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>>>>
>>>>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In the mails following this one, I found how to fix the
>>>>>>>>> assembly to work
>>>>>>>>> in the omit-frame-pointer case. The real problem is that, at
>>>>>>>>> compilation
>>>>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>>>>> compiling with frame pointers enabled. And it does not seem
>>>>>>>>> easy to
>>>>>>>>> write a configure test script, which tests whether frame
>>>>>>>>> pointers are
>>>>>>>>> enabled or not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'd suggest that at some point, we move all the syscall
>>>>>>>> trampolines out
>>>>>>>> of line, and specifically build the resulting file forcing
>>>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile
>>>>>>>> until we
>>>>>>>> actually control the way that compilation unit is built,
>>>>>>>> regardless of
>>>>>>>> the general settings for CFLAGS.
>>>>>>>>
>>>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer
>>>>>>> on x86_32.
>>>>>>>
>>>>>>
>>>>>> Yes, but that is crappy. The point is that we don't want to force
>>>>>> this
>>>>>> for all userland bits. We'd only need this for syscall trampolines.
>>>>>>
>>>>> We currently have different flags for compiling xenomai than for
>>>>> passing
>>>>> to the applications (via xeno-config). The problem is that I am not
>>>>> sure
>>>>> it will not break for instance calling "backtrace" in gdb when
>>>>> breaking
>>>>> inside a xenomai function.
>>>>>
>>>> (mixing code compiled without frame pointers with code compiled with
>>>> frame pointers I mean).
>>>>
>>>
>>> The only issue is with frame elimination starting with -O2 and above,
>>> otherwise the backtraces are clean over gdb (just checked), at least
>>> there does not seem to be any additional problem introduced by mixing bp
>>> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed
>>> (back)traces anyway, and this is what we pick when --enable-debug is
>>> given.
>>>
>>> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its
>>> own C trampoline, group all trampolines into separate compilation units,
>>> and build each of these units with -fno-omit-frame-pointer
>>> unconditionally.
>>>
>>> -forge is a good candidate for this, since the number of syscall
>>> trampolines shrunk dramatically compared to 2.x. If any issue would be
>>> easily detected based on the output of the new "slackspot" tracer we
>>> have there.
>>>
>> It looks to me like we can simply build xenomai libraries with
>> -fno-omit-frame-pointer, and compile the rest without this option. After
>> all, implementation of xenomai services are little more than syscall
>> trampolines.
>>
>
> This is true for 2.x, however -forge will need the other approach.
>

Unless you only mean lib/cobalt for 3.x, in which case I would agree.

-- 
Philippe.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 06/08/2012 11:31 AM, Philippe Gerum wrote:
> On 06/08/2012 11:29 AM, Philippe Gerum wrote:
>> On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote:
>>> On 06/08/2012 11:20 AM, Philippe Gerum wrote:
>>>> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>>>>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>>>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the
>>>>>>>>>>>>>>>>>>> result of ldd
>>>>>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested,
>>>>>>>>>>>>>>>>> but this
>>>>>>>>>>>>>>>>> looks like a former issue we had with aggressive
>>>>>>>>>>>>>>>>> optimizers):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c
>>>>>>>>>>>>>>>>> b/src/skins/posix/init.c
>>>>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>>>>> static __attribute__ ((constructor))
>>>>>>>>>>>>>>>>> void __init_posix_interface(void)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> + volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>>> struct sched_param parm;
>>>>>>>>>>>>>>>>> int policy;
>>>>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /* Don't use auto-shadowing if we are likely invoked
>>>>>>>>>>>>>>>>> from dlopen. */
>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>>> - err =
>>>>>>>>>>>>>>>>> __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>>>>>> + err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>>> "pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>>> exit(EXIT_FAILURE);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - err = __wrap_pthread_setschedparam(pthread_self(),
>>>>>>>>>>>>>>>>> policy,&parm);
>>>>>>>>>>>>>>>>> + err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>>> "pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There should not be any issue here, as the pthread_self()
>>>>>>>>>>>>>>>> is passed as
>>>>>>>>>>>>>>>> an argument to the called functions, the syscall is not
>>>>>>>>>>>>>>>> inlined directly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Did you get any disassembly of the faulty code when
>>>>>>>>>>>>>>> suggesting
>>>>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It would be interesting to know why we have to force a frame
>>>>>>>>>>>>> pointer in
>>>>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug
>>>>>>>>>>>>> might bite later
>>>>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive
>>>>>>>>>>>>> over time.
>>>>>>>>>>>>>
>>>>>>>>>>>> Ah this, I know. I have posted a mail where I explained the
>>>>>>>>>>>> problem. I
>>>>>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>>>>>
>>>>>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the mails following this one, I found how to fix the
>>>>>>>>>> assembly to work
>>>>>>>>>> in the omit-frame-pointer case. The real problem is that, at
>>>>>>>>>> compilation
>>>>>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>>>>>> compiling with frame pointers enabled. And it does not seem
>>>>>>>>>> easy to
>>>>>>>>>> write a configure test script, which tests whether frame
>>>>>>>>>> pointers are
>>>>>>>>>> enabled or not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'd suggest that at some point, we move all the syscall
>>>>>>>>> trampolines out
>>>>>>>>> of line, and specifically build the resulting file forcing
>>>>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile
>>>>>>>>> until we
>>>>>>>>> actually control the way that compilation unit is built,
>>>>>>>>> regardless of
>>>>>>>>> the general settings for CFLAGS.
>>>>>>>>>
>>>>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer
>>>>>>>> on x86_32.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, but that is crappy. The point is that we don't want to force
>>>>>>> this
>>>>>>> for all userland bits. We'd only need this for syscall trampolines.
>>>>>>>
>>>>>> We currently have different flags for compiling xenomai than for
>>>>>> passing
>>>>>> to the applications (via xeno-config). The problem is that I am not
>>>>>> sure
>>>>>> it will not break for instance calling "backtrace" in gdb when
>>>>>> breaking
>>>>>> inside a xenomai function.
>>>>>>
>>>>> (mixing code compiled without frame pointers with code compiled with
>>>>> frame pointers I mean).
>>>>>
>>>>
>>>> The only issue is with frame elimination starting with -O2 and above,
>>>> otherwise the backtraces are clean over gdb (just checked), at least
>>>> there does not seem to be any additional problem introduced by mixing bp
>>>> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed
>>>> (back)traces anyway, and this is what we pick when --enable-debug is
>>>> given.
>>>>
>>>> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its
>>>> own C trampoline, group all trampolines into separate compilation units,
>>>> and build each of these units with -fno-omit-frame-pointer
>>>> unconditionally.
>>>>
>>>> -forge is a good candidate for this, since the number of syscall
>>>> trampolines shrunk dramatically compared to 2.x. If any issue would be
>>>> easily detected based on the output of the new "slackspot" tracer we
>>>> have there.
>>>>
>>> It looks to me like we can simply build xenomai libraries with
>>> -fno-omit-frame-pointer, and compile the rest without this option. After
>>> all, implementation of xenomai services are little more than syscall
>>> trampolines.
>>>
>>
>> This is true for 2.x, however -forge will need the other approach.
>>
> 
> Unless you only mean lib/cobalt for 3.x, in which case I would agree.
> 
I was thinking 2.x. But yes, we can do the same with lib/cobalt.

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[ali hagigat]

I did "make clean" for building the Xenomai user space components and
now every thing seems OK.
Xenomai version is 2.6.0.

Thank you.

On Fri, Jun 8, 2012 at 2:05 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 06/08/2012 11:31 AM, Philippe Gerum wrote:
>> On 06/08/2012 11:29 AM, Philippe Gerum wrote:
>>> On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote:
>>>> On 06/08/2012 11:20 AM, Philippe Gerum wrote:
>>>>> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
>>>>>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
>>>>>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
>>>>>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
>>>>>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>>>>>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>>>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the
>>>>>>>>>>>>>>>>>>>> result of ldd
>>>>>>>>>>>>>>>>>>>> command:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested,
>>>>>>>>>>>>>>>>>> but this
>>>>>>>>>>>>>>>>>> looks like a former issue we had with aggressive
>>>>>>>>>>>>>>>>>> optimizers):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c
>>>>>>>>>>>>>>>>>> b/src/skins/posix/init.c
>>>>>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
>>>>>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
>>>>>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
>>>>>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>>>>>>>>>>>>>>>> static __attribute__ ((constructor))
>>>>>>>>>>>>>>>>>> void __init_posix_interface(void)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> + volatile pthread_t tid = pthread_self();
>>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>>>> struct sched_param parm;
>>>>>>>>>>>>>>>>>> int policy;
>>>>>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /* Don't use auto-shadowing if we are likely invoked
>>>>>>>>>>>>>>>>>> from dlopen. */
>>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>>>>>>>>>>>>>>>> - err =
>>>>>>>>>>>>>>>>>> __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>>>>>>>>>>>>>>>>> + err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>>>> "pthread_getschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>>>> exit(EXIT_FAILURE);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - err = __wrap_pthread_setschedparam(pthread_self(),
>>>>>>>>>>>>>>>>>> policy,&parm);
>>>>>>>>>>>>>>>>>> + err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>>>>>>>>>>>>>>>> if (err) {
>>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
>>>>>>>>>>>>>>>>>> "pthread_setschedparam: %s\n", strerror(err));
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There should not be any issue here, as the pthread_self()
>>>>>>>>>>>>>>>>> is passed as
>>>>>>>>>>>>>>>>> an argument to the called functions, the syscall is not
>>>>>>>>>>>>>>>>> inlined directly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Did you get any disassembly of the faulty code when
>>>>>>>>>>>>>>>> suggesting
>>>>>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, but I had experienced the problem first hand.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would be interesting to know why we have to force a frame
>>>>>>>>>>>>>> pointer in
>>>>>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug
>>>>>>>>>>>>>> might bite later
>>>>>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive
>>>>>>>>>>>>>> over time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Ah this, I know. I have posted a mail where I explained the
>>>>>>>>>>>>> problem. I
>>>>>>>>>>>>> am a bit in a short schedule here, will post the link tonight.
>>>>>>>>>>>>>
>>>>>>>>>>>> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In the mails following this one, I found how to fix the
>>>>>>>>>>> assembly to work
>>>>>>>>>>> in the omit-frame-pointer case. The real problem is that, at
>>>>>>>>>>> compilation
>>>>>>>>>>> time, we have no command-line #defined variable telling us whether
>>>>>>>>>>> compiling with frame pointers enabled. And it does not seem
>>>>>>>>>>> easy to
>>>>>>>>>>> write a configure test script, which tests whether frame
>>>>>>>>>>> pointers are
>>>>>>>>>>> enabled or not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd suggest that at some point, we move all the syscall
>>>>>>>>>> trampolines out
>>>>>>>>>> of line, and specifically build the resulting file forcing
>>>>>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile
>>>>>>>>>> until we
>>>>>>>>>> actually control the way that compilation unit is built,
>>>>>>>>>> regardless of
>>>>>>>>>> the general settings for CFLAGS.
>>>>>>>>>>
>>>>>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer
>>>>>>>>> on x86_32.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, but that is crappy. The point is that we don't want to force
>>>>>>>> this
>>>>>>>> for all userland bits. We'd only need this for syscall trampolines.
>>>>>>>>
>>>>>>> We currently have different flags for compiling xenomai than for
>>>>>>> passing
>>>>>>> to the applications (via xeno-config). The problem is that I am not
>>>>>>> sure
>>>>>>> it will not break for instance calling "backtrace" in gdb when
>>>>>>> breaking
>>>>>>> inside a xenomai function.
>>>>>>>
>>>>>> (mixing code compiled without frame pointers with code compiled with
>>>>>> frame pointers I mean).
>>>>>>
>>>>>
>>>>> The only issue is with frame elimination starting with -O2 and above,
>>>>> otherwise the backtraces are clean over gdb (just checked), at least
>>>>> there does not seem to be any additional problem introduced by mixing bp
>>>>> and no-bp. At any rate, -O0 -g is recommended to get clean and detailed
>>>>> (back)traces anyway, and this is what we pick when --enable-debug is
>>>>> given.
>>>>>
>>>>> We should move each existing inline XENOMAI_SYS/SKINCALL macro into its
>>>>> own C trampoline, group all trampolines into separate compilation units,
>>>>> and build each of these units with -fno-omit-frame-pointer
>>>>> unconditionally.
>>>>>
>>>>> -forge is a good candidate for this, since the number of syscall
>>>>> trampolines shrunk dramatically compared to 2.x. If any issue would be
>>>>> easily detected based on the output of the new "slackspot" tracer we
>>>>> have there.
>>>>>
>>>> It looks to me like we can simply build xenomai libraries with
>>>> -fno-omit-frame-pointer, and compile the rest without this option. After
>>>> all, implementation of xenomai services are little more than syscall
>>>> trampolines.
>>>>
>>>
>>> This is true for 2.x, however -forge will need the other approach.
>>>
>>
>> Unless you only mean lib/cobalt for 3.x, in which case I would agree.
>>
> I was thinking 2.x. But yes, we can do the same with lib/cobalt.
>
> --
>                                            Gilles.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Marcin Kuśka]

I will continue this topic since my problem looks similar.

I'm using linux kernel from *http://git.xenomai.org/ipipe-gch.git/* (ipipe
core-3.2 ) and xenomai 2.6 branch head. Compiling for versatile express
cortex-a9.
I tried to cross-compile a simple program bound_task (can be found in
documentation as example) but i received this:

*arm-unknown-linux-gnueabi-gcc -I/usr/xenomai/include -D_GNU_SOURCE
-D_REENTRANT -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread
-lrt -lrtdk bound_task.c -o bound_task_VEXPRESS
In file included from /usr/xenomai/include/nucleus/trace.h:52,
                 from /usr/xenomai/include/nucleus/system.h:27,
                 from /usr/xenomai/include/asm/xenomai/system_64.h:137,
                 from /usr/xenomai/include/asm/xenomai/system.h:4,
                 from /usr/xenomai/include/nucleus/types.h:36,
                 from /usr/xenomai/include/nucleus/thread.h:25,
                 from /usr/xenomai/include/nucleus/sched.h:31,
                 from /usr/xenomai/include/native/task.h:25,
                 from bound_task.c:2:
/usr/xenomai/include/asm/xenomai/syscall.h: In function '__xn_rdtsc':
/usr/xenomai/include/asm/xenomai/syscall.h:327: warning: left shift count
>= width of type
/usr/xenomai/lib/libnative.so: file not recognized: File format not
recognized
collect2: ld returned 1 exit status
make: *** [bound_task] Error 1*

And as far as I'm concerned that means (the underlined line) that my
xenomai libraries are not cross-compiled for ARM (which now I assume have
to be) as well. I know that they are not, cause i omitted the
README.INSTALL of xenomai and run common *./configure* (which I assume
compiles xenomai for x86 or smth) instead of *./configure CFLAGS="...."
LDFLAGS="....." --build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi *or
something similar. So I run the proper configure according to
README.INSTALL for ARM and this is what i receive:

*# ./configure CFLAGS="-march=armv7-a -mfpu=vfp3 *" LDFLAGS="-march=armv4t"
--build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi

checking build system type... i686-pc-linux-gnu
checking host system type... arm-unknown-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-unknown-linux-gnueabi-gcc... arm-unknown-linux-gnueabi-gcc
checking whether the C compiler works... no
configure: error: in `/home/marcin/arm/tarballs/xenomai-2.6-5942064':
configure: error: C compiler cannot create executables
See `config.log' for more details*
*
*I've already tried the *-fno-omit-frame-pointer *option and the result is
the same.

As I mentioned I'm compiling for cortex-a9 so the *CFLAGS *should be set as
omap4 setting? as long there is no cortex-a9 setting described...
*(CFLAGS="-march=armv7-a
-mfpu=vfp3 *")

*Any suggestions?

Thank you in advantage!

2012/6/9 ali hagigat <hagigatali@gmail.com>

> I did "make clean" for building the Xenomai user space components and
> now every thing seems OK.
> Xenomai version is 2.6.0.
>
> Thank you.
>
> On Fri, Jun 8, 2012 at 2:05 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On 06/08/2012 11:31 AM, Philippe Gerum wrote:
> >> On 06/08/2012 11:29 AM, Philippe Gerum wrote:
> >>> On 06/08/2012 11:25 AM, Gilles Chanteperdrix wrote:
> >>>> On 06/08/2012 11:20 AM, Philippe Gerum wrote:
> >>>>> On 06/06/2012 08:00 PM, Gilles Chanteperdrix wrote:
> >>>>>> On 06/06/2012 07:57 PM, Gilles Chanteperdrix wrote:
> >>>>>>> On 06/06/2012 05:21 PM, Philippe Gerum wrote:
> >>>>>>>> On 06/06/2012 05:15 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>> On 06/06/2012 05:03 PM, Philippe Gerum wrote:
> >>>>>>>>>> On 06/06/2012 04:27 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>>>> On 06/06/2012 04:02 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>> On 06/06/2012 03:55 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>>> On 06/06/2012 03:53 PM, Philippe Gerum wrote:
> >>>>>>>>>>>>>> On 06/06/2012 03:41 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>>>>> On 06/06/2012 03:25 PM, Philippe Gerum wrote:
> >>>>>>>>>>>>>>>> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
> >>>>>>>>>>>>>>>>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
> >>>>>>>>>>>>>>>>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
> >>>>>>>>>>>>>>>>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
> >>>>>>>>>>>>>>>>>>>> Much appreciate for the reply, Mr. Gerum. Here is the
> >>>>>>>>>>>>>>>>>>>> result of ldd
> >>>>>>>>>>>>>>>>>>>> command:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Alternatively, this patch may work as well (not tested,
> >>>>>>>>>>>>>>>>>> but this
> >>>>>>>>>>>>>>>>>> looks like a former issue we had with aggressive
> >>>>>>>>>>>>>>>>>> optimizers):
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> diff --git a/src/skins/posix/init.c
> >>>>>>>>>>>>>>>>>> b/src/skins/posix/init.c
> >>>>>>>>>>>>>>>>>> index 7a338a0..9c7849e 100644
> >>>>>>>>>>>>>>>>>> --- a/src/skins/posix/init.c
> >>>>>>>>>>>>>>>>>> +++ b/src/skins/posix/init.c
> >>>>>>>>>>>>>>>>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
> >>>>>>>>>>>>>>>>>> static __attribute__ ((constructor))
> >>>>>>>>>>>>>>>>>> void __init_posix_interface(void)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> + volatile pthread_t tid = pthread_self();
> >>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
> >>>>>>>>>>>>>>>>>> struct sched_param parm;
> >>>>>>>>>>>>>>>>>> int policy;
> >>>>>>>>>>>>>>>>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> /* Don't use auto-shadowing if we are likely invoked
> >>>>>>>>>>>>>>>>>> from dlopen. */
> >>>>>>>>>>>>>>>>>> #ifndef CONFIG_XENO_LIBS_DLOPEN
> >>>>>>>>>>>>>>>>>> - err =
> >>>>>>>>>>>>>>>>>>
> __real_pthread_getschedparam(pthread_self(),&policy,&parm);
> >>>>>>>>>>>>>>>>>> + err = __real_pthread_getschedparam(tid,&policy,&parm);
> >>>>>>>>>>>>>>>>>> if (err) {
> >>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
> >>>>>>>>>>>>>>>>>> "pthread_getschedparam: %s\n", strerror(err));
> >>>>>>>>>>>>>>>>>> exit(EXIT_FAILURE);
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> - err = __wrap_pthread_setschedparam(pthread_self(),
> >>>>>>>>>>>>>>>>>> policy,&parm);
> >>>>>>>>>>>>>>>>>> + err = __wrap_pthread_setschedparam(tid, policy,&parm);
> >>>>>>>>>>>>>>>>>> if (err) {
> >>>>>>>>>>>>>>>>>> fprintf(stderr, "Xenomai Posix skin init: "
> >>>>>>>>>>>>>>>>>> "pthread_setschedparam: %s\n", strerror(err));
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There should not be any issue here, as the pthread_self()
> >>>>>>>>>>>>>>>>> is passed as
> >>>>>>>>>>>>>>>>> an argument to the called functions, the syscall is not
> >>>>>>>>>>>>>>>>> inlined directly.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Did you get any disassembly of the faulty code when
> >>>>>>>>>>>>>>>> suggesting
> >>>>>>>>>>>>>>>> -fno-omit-frame-pointer last time you did?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No, but I had experienced the problem first hand.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It would be interesting to know why we have to force a frame
> >>>>>>>>>>>>>> pointer in
> >>>>>>>>>>>>>> there. I'm not comfortable with voodoo fixing, that bug
> >>>>>>>>>>>>>> might bite later
> >>>>>>>>>>>>>> on as gcc's optimizer is unlikely to become less aggressive
> >>>>>>>>>>>>>> over time.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Ah this, I know. I have posted a mail where I explained the
> >>>>>>>>>>>>> problem. I
> >>>>>>>>>>>>> am a bit in a short schedule here, will post the link
> tonight.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> http://xenomai.org/pipermail/xenomai-core/2011-08/msg00029.html
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> In the mails following this one, I found how to fix the
> >>>>>>>>>>> assembly to work
> >>>>>>>>>>> in the omit-frame-pointer case. The real problem is that, at
> >>>>>>>>>>> compilation
> >>>>>>>>>>> time, we have no command-line #defined variable telling us
> whether
> >>>>>>>>>>> compiling with frame pointers enabled. And it does not seem
> >>>>>>>>>>> easy to
> >>>>>>>>>>> write a configure test script, which tests whether frame
> >>>>>>>>>>> pointers are
> >>>>>>>>>>> enabled or not.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I'd suggest that at some point, we move all the syscall
> >>>>>>>>>> trampolines out
> >>>>>>>>>> of line, and specifically build the resulting file forcing
> >>>>>>>>>> -fno-omit-frame-pointer. Such inlining will always be fragile
> >>>>>>>>>> until we
> >>>>>>>>>> actually control the way that compilation unit is built,
> >>>>>>>>>> regardless of
> >>>>>>>>>> the general settings for CFLAGS.
> >>>>>>>>>>
> >>>>>>>>> In the current 2.6 repository, we force -fno-omit-frame-pointer
> >>>>>>>>> on x86_32.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Yes, but that is crappy. The point is that we don't want to force
> >>>>>>>> this
> >>>>>>>> for all userland bits. We'd only need this for syscall
> trampolines.
> >>>>>>>>
> >>>>>>> We currently have different flags for compiling xenomai than for
> >>>>>>> passing
> >>>>>>> to the applications (via xeno-config). The problem is that I am not
> >>>>>>> sure
> >>>>>>> it will not break for instance calling "backtrace" in gdb when
> >>>>>>> breaking
> >>>>>>> inside a xenomai function.
> >>>>>>>
> >>>>>> (mixing code compiled without frame pointers with code compiled with
> >>>>>> frame pointers I mean).
> >>>>>>
> >>>>>
> >>>>> The only issue is with frame elimination starting with -O2 and above,
> >>>>> otherwise the backtraces are clean over gdb (just checked), at least
> >>>>> there does not seem to be any additional problem introduced by
> mixing bp
> >>>>> and no-bp. At any rate, -O0 -g is recommended to get clean and
> detailed
> >>>>> (back)traces anyway, and this is what we pick when --enable-debug is
> >>>>> given.
> >>>>>
> >>>>> We should move each existing inline XENOMAI_SYS/SKINCALL macro into
> its
> >>>>> own C trampoline, group all trampolines into separate compilation
> units,
> >>>>> and build each of these units with -fno-omit-frame-pointer
> >>>>> unconditionally.
> >>>>>
> >>>>> -forge is a good candidate for this, since the number of syscall
> >>>>> trampolines shrunk dramatically compared to 2.x. If any issue would
> be
> >>>>> easily detected based on the output of the new "slackspot" tracer we
> >>>>> have there.
> >>>>>
> >>>> It looks to me like we can simply build xenomai libraries with
> >>>> -fno-omit-frame-pointer, and compile the rest without this option.
> After
> >>>> all, implementation of xenomai services are little more than syscall
> >>>> trampolines.
> >>>>
> >>>
> >>> This is true for 2.x, however -forge will need the other approach.
> >>>
> >>
> >> Unless you only mean lib/cobalt for 3.x, in which case I would agree.
> >>
> > I was thinking 2.x. But yes, we can do the same with lib/cobalt.
> >
> > --
> >                                            Gilles.
> >
> > _______________________________________________
> > Xenomai mailing list
> > Xenomai@xenomai.org
> > http://www.xenomai.org/mailman/listinfo/xenomai
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>



-- 
Marcin Kuśka

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 07/03/2012 06:01 PM, Marcin Kuśka wrote:
> I will continue this topic since my problem looks similar.
> 
> I'm using linux kernel from *http://git.xenomai.org/ipipe-gch.git/* (ipipe
> core-3.2 ) and xenomai 2.6 branch head. Compiling for versatile express
> cortex-a9.
> I tried to cross-compile a simple program bound_task (can be found in
> documentation as example) but i received this:
> 
> *arm-unknown-linux-gnueabi-gcc -I/usr/xenomai/include -D_GNU_SOURCE
> -D_REENTRANT -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread
> -lrt -lrtdk bound_task.c -o bound_task_VEXPRESS
> In file included from /usr/xenomai/include/nucleus/trace.h:52,
>                  from /usr/xenomai/include/nucleus/system.h:27,
>                  from /usr/xenomai/include/asm/xenomai/system_64.h:137,
>                  from /usr/xenomai/include/asm/xenomai/system.h:4,
>                  from /usr/xenomai/include/nucleus/types.h:36,
>                  from /usr/xenomai/include/nucleus/thread.h:25,
>                  from /usr/xenomai/include/nucleus/sched.h:31,
>                  from /usr/xenomai/include/native/task.h:25,
>                  from bound_task.c:2:
> /usr/xenomai/include/asm/xenomai/syscall.h: In function '__xn_rdtsc':
> /usr/xenomai/include/asm/xenomai/syscall.h:327: warning: left shift count
>> = width of type
> /usr/xenomai/lib/libnative.so: file not recognized: File format not
> recognized
> collect2: ld returned 1 exit status
> make: *** [bound_task] Error 1*

If you have xenomai compiled for x86 in /usr/xenomai/lib, that is 
logical. Normally, when you have compiled xenomai for ARM, you run:
make DESTDIR=/some/path install

Then the library directory is /some/path/usr/xenomai/lib

And in order to get the proper flag, you should run:

DESTDIR=/some/path /some/patch/usr/xenomai/bin/xeno-config --skin=native --cflags

same with ldflags for the ldflags.


> 
> And as far as I'm concerned that means (the underlined line) that my
> xenomai libraries are not cross-compiled for ARM (which now I assume have
> to be) as well. I know that they are not, cause i omitted the
> README.INSTALL of xenomai and run common *./configure* (which I assume
> compiles xenomai for x86 or smth) instead of *./configure CFLAGS="...."
> LDFLAGS="....." --build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi *or
> something similar. So I run the proper configure according to
> README.INSTALL for ARM and this is what i receive:
> 
> *# ./configure CFLAGS="-march=armv7-a -mfpu=vfp3 *" LDFLAGS="-march=armv4t"
> --build=i686-pc-linux-gnu --host=arm-unknown-linux-gnueabi

You are compiling with -march=armv7-a and linking with
-march=armv4t, are you sure this is supposed to work?

> 
> checking build system type... i686-pc-linux-gnu
> checking host system type... arm-unknown-linux-gnueabi
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for arm-unknown-linux-gnueabi-gcc... arm-unknown-linux-gnueabi-gcc
> checking whether the C compiler works... no
> configure: error: in `/home/marcin/arm/tarballs/xenomai-2.6-5942064':
> configure: error: C compiler cannot create executables
> See `config.log' for more details*

I guess compiling for armv7 and linking for armv4 is not supported...
Anyway, to understand what happens, you can do what is written,
look at config.log.

> *
> *I've already tried the *-fno-omit-frame-pointer *option and the result is
> the same.
> 
> As I mentioned I'm compiling for cortex-a9 so the *CFLAGS *should be set as
> omap4 setting? as long there is no cortex-a9 setting described...
> *(CFLAGS="-march=armv7-a
> -mfpu=vfp3 *")

Yes, but the problem is probably the LDFLAGS you added...

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Marcin Kuśka]

>
> You are compiling with -march=armv7-a and linking with
> -march=armv4t, are you sure this is supposed to work?
>
> I guess compiling for armv7 and linking for armv4 is not supported...
> Anyway, to understand what happens, you can do what is written,
> look at config.log.
>
>
Yes that was the problem. Many thanks!

Now i face another problem. I put the CFLAGS and LDFLAGS in busybox to
xeno-config --skin=native --cflags and xeno-config --skin=native --cflags
and imported NEEDED libraries to my/rootfilesystem/path/lib and got xenomai
error:

*Xenomai: /dev/rtheap is missing
*
*(chardev, major=10 minor=254)

*
I was surprised that i have to copy those devices by myself but I did it.
Now the problem sounds following:

*Xenomai init: open(/dev/mem): No such file or directory
Kernel panic - not syncing: Attempted to kill init!*

Seems to me I have omitted some important thing that's why errors are
occuring one after another?
Any suggestions?

Thank you in advantage!
-- 
Marcin Kuśka

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix]

On 07/06/2012 05:42 PM, Marcin Kuśka wrote:
>>
>> You are compiling with -march=armv7-a and linking with
>> -march=armv4t, are you sure this is supposed to work?
>>
>> I guess compiling for armv7 and linking for armv4 is not supported...
>> Anyway, to understand what happens, you can do what is written,
>> look at config.log.
>>
>>
> Yes that was the problem. Many thanks!
> 
> Now i face another problem. I put the CFLAGS and LDFLAGS in busybox to
> xeno-config --skin=native --cflags and xeno-config --skin=native --cflags

You do not need to compile busybox with xenomai native skin. You only
need to compile xenomai applications with xenomai native skin flags. In
fact, as long as you do not make your own xenomai application, you do
not need to compile anything with xenomai flags. You should just install
xenomai on an otherwise normal root filesystem and try running xenomai
testsuite programs, such as "latency".

> and imported NEEDED libraries to my/rootfilesystem/path/lib and got xenomai
> error:
> 
> *Xenomai: /dev/rtheap is missing
> *
> *(chardev, major=10 minor=254)
> 
> *
> I was surprised that i have to copy those devices by myself but I did it.

You are suppposed to run make DESTDIR=/my/rootfilesystem/path install,
and everything will be installed.

> Now the problem sounds following:
> 
> *Xenomai init: open(/dev/mem): No such file or directory
> Kernel panic - not syncing: Attempted to kill init!*

That is because you have compiled busybox with xenomai flag, which is
completely useless. And if your filesystem does not have /dev/mem, it is
seriously screwed.

Seriously, is README.INSTALL so hard to understand?

-- 
					    Gilles.

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Marcin Kuśka]

Obviously I misunderstood the way it installs itself. Anyway after the
proper installation (no xeno-flags for busybox and dest_dir as
$myfilesystem_root/) neither latency or xeno-test was working.

*/usr/xenomai/bin/xeno-test-run: error while loading shared libraries:
libpthread.so.0: cannot open shared object file: No such file or directory
/usr/xenomai/bin # ./latency
./latency: error while loading shared libraries: libpthread.so.0: cannot
open shared object file: No such file or directory
/usr/xenomai/bin #


*
So I run cmd:

*arm-unknown-linux-gnueabi-readelf -d latency*

and copied all the NEEDED libraries into /lib path of my rootfs. And again
i got this:

*/usr/xenomai/bin # ./latency
Xenomai init: open(/dev/mem): No such file or directory
*

Xenomai generated lots of devices (rtheap, rtp0 - rtp31) but no mem device.
Is it supposed to generate itself or should I use mdev in script or smth?

Sorry to be so problemative but I'm quite determined to run this system
which I believe is nearly ready.

regards,
Marcin Kuśka

2012/7/6 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> On 07/06/2012 05:42 PM, Marcin Kuśka wrote:
> >>
> >> You are compiling with -march=armv7-a and linking with
> >> -march=armv4t, are you sure this is supposed to work?
> >>
> >> I guess compiling for armv7 and linking for armv4 is not supported...
> >> Anyway, to understand what happens, you can do what is written,
> >> look at config.log.
> >>
> >>
> > Yes that was the problem. Many thanks!
> >
> > Now i face another problem. I put the CFLAGS and LDFLAGS in busybox to
> > xeno-config --skin=native --cflags and xeno-config --skin=native --cflags
>
> You do not need to compile busybox with xenomai native skin. You only
> need to compile xenomai applications with xenomai native skin flags. In
> fact, as long as you do not make your own xenomai application, you do
> not need to compile anything with xenomai flags. You should just install
> xenomai on an otherwise normal root filesystem and try running xenomai
> testsuite programs, such as "latency".
>
> > and imported NEEDED libraries to my/rootfilesystem/path/lib and got
> xenomai
> > error:
> >
> > *Xenomai: /dev/rtheap is missing
> > *
> > *(chardev, major=10 minor=254)
> >
> > *
> > I was surprised that i have to copy those devices by myself but I did it.
>
> You are suppposed to run make DESTDIR=/my/rootfilesystem/path install,
> and everything will be installed.
>
> > Now the problem sounds following:
> >
> > *Xenomai init: open(/dev/mem): No such file or directory
> > Kernel panic - not syncing: Attempted to kill init!*
>
> That is because you have compiled busybox with xenomai flag, which is
> completely useless. And if your filesystem does not have /dev/mem, it is
> seriously screwed.
>
> Seriously, is README.INSTALL so hard to understand?
>
> --
>                                             Gilles.
>



-- 
Marcin Kuśka

Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Christophe Blaess]

On 09/07/2012 17:34, Marcin Kuśka wrote:
> i got this:
>
> */usr/xenomai/bin # ./latency
> Xenomai init: open(/dev/mem): No such file or directory
> *
>

You can create the device file manually with

     mknod /dev/mem c 1 1

Otherwise starting "mdev -s" in your /etc/init.d/rcS script will create it.