[Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

Hello!

I am having a little problem with some programs from the Xenomai test
suite. The clocktest, cyclictest and switchtest crashes with "Illegal
instruction":

~ # /usr/xenomai/bin/clocktest 
== Tested clock: 0 (CLOCK_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------- --------------
  0                  0.0            0.000          0            0.0
Illegal instruction


When I turn the debug.exception-trace kernel option on,
and run the clocktest, I have got the following kernel message:

clocktest[243]: unhandled signal 4 at 0fdf4e74 nip 0fdf4e74 lr 0ffd8af8
code 30001

I have read in a previous messages on this list, that the
CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
unfortunately this did not help.

I am using the following versions:
Linux kernel: 3.8.13
Xenomai: 2.6.3
Toolchain: ELDK-5.4

Significant kernel options:
$ cat .config | egrep '_XENO_|_IPIPE_' | grep -v ^\#
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_SHIRQ=y
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
CONFIG_XENO_OPT_TIMER_LIST=y
CONFIG_XENO_HW_FPU=y
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_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_SHM=y
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
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_DRIVERS_CAN=m
CONFIG_XENO_DRIVERS_CAN_DEBUG=y
CONFIG_XENO_DRIVERS_CAN_LOOPBACK=y
CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE=1024
CONFIG_XENO_DRIVERS_CAN_MAX_DEVICES=4
CONFIG_XENO_DRIVERS_CAN_MAX_RECEIVERS=16
CONFIG_XENO_DRIVERS_CAN_VIRT=m
CONFIG_XENO_DRIVERS_CAN_MSCAN=m
CONFIG_XENO_DRIVERS_RTIPC=m
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
CONFIG_IPIPE_HAVE_PREEMPTIBLE_SWITCH=y

Am I using something wrong? Any suggestion would be highly appreciated!

Thank you in advance!

-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131128/1f6360dd/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Gilles Chanteperdrix]

On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> Hello!
> 
> I am having a little problem with some programs from the Xenomai test
> suite. The clocktest, cyclictest and switchtest crashes with "Illegal
> instruction":

What about the latency test? If it fails with the same error, you could 
try the following patch for powerpc SPE:

https://git.xenomai.org/xenomai-2.6.git/commit/?id=d09932cfd0ca422989b3c3a9d736236d74590ade

-- 
                                                                Gilles.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Gilles Chanteperdrix]

On 11/28/2013 09:17 PM, Gilles Chanteperdrix wrote:
> On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
>> Hello!
>>
>> I am having a little problem with some programs from the Xenomai test
>> suite. The clocktest, cyclictest and switchtest crashes with "Illegal
>> instruction":
> 
> What about the latency test? If it fails with the same error, you could 
> try the following patch for powerpc SPE:
> 
> https://git.xenomai.org/xenomai-2.6.git/commit/?id=d09932cfd0ca422989b3c3a9d736236d74590ade
> 

The patch is needed to get switchtest working, but otherwise, you simply
need to disable CONFIG_XENO_HW_FPU and the other tests should work
without the patch.

-- 
                                                                Gilles.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

I have turned off the Xenomai FPU support:

$ cat src/Kernel/build/.config | grep FPU
CONFIG_PPC_FPU=y
# CONFIG_XENO_HW_FPU is not set

I have got the following results:
 - No regression in latency test.
 - Trivial posix skin test still does not work.
 - Switchtest does not work. It crash with the following messages:
~ # /usr/xenomai/bin/switchtest 
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
r8: 1 != 2
r9: 1 != 2
r10: 1 != 2
r11: 1 != 2
r12: 1 != 2
r13: 1 != 2
r14: 1 != 2
r15: 1 != 2
r16: 1 != 2
r17: 1 != 2
r18: 1 != 2
r19: 1 != 2
r20: 1 != 2
r21: 1 != 2
r22: 1 != 2
r23: 1 != 2
r24: 1 != 2
r25: 1 != 2
r26: 1 != 2
r27: 1 != 2
r28: 1 != 2
r29: 1 != 2
r30: 1 != 2
r31: 1 != 2
== FPU check routines: OK.
sem_wait FAILED (38)
pthread_create: Resource temporarily unavailable
== Threads: sleeper_ufps-0 rtk-1 rtk-2 rtk_fp-3 rtk_fp-4 rtk_fp_ufpp-5 rtk_fp_ufpp-6RTT|  00:06:54
RTH|ctx switches|-------total
Illegal instruction

 - Clocktest does not work. It crash with the following messages:
~ # /usr/xenomai/bin/clocktest 
== Tested clock: 0 (CLOCK_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------- --------------
  0                  0.0            0.000          0            0.0
Illegal instruction



On Thu, 28 Nov 2013 21:30:24 +0100
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> On 11/28/2013 09:17 PM, Gilles Chanteperdrix wrote:
> > On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> >> Hello!
> >>
> >> I am having a little problem with some programs from the Xenomai
> >> test suite. The clocktest, cyclictest and switchtest crashes with
> >> "Illegal instruction":
> > 
> > What about the latency test? If it fails with the same error, you
> > could try the following patch for powerpc SPE:
> > 
> > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d09932cfd0ca422989b3c3a9d736236d74590ade
> > 
> 
> The patch is needed to get switchtest working, but otherwise, you
> simply need to disable CONFIG_XENO_HW_FPU and the other tests should
> work without the patch.
> 



-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/df1f9f3d/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

The latency test works well for user task, kernel task and timer IRQ,
too. Does it make a sense to try the patch in this case?

I have done some trivial test with the native and posix skins, by the
time: Create a realtime task with appropriate scheduling policy and
priority, and increase a static integer variable in it.
With the native skin it works well, however, with the posix skin it
crashes with the following message:

pthread_create: 11 Resource temporarily unavailable
Trace/breakpoint trap

Before the creation of the pthread, the stacksize is set to
PTHREAD_STACK_MIN (128 Kib)
Corresponding kernel option:
CONFIG_XENO_OPT_SYS_HEAPSZ = 4096.

This issue probably related to the original one.

On Thu, 28 Nov 2013 21:17:39 +0100
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> > Hello!
> > 
> > I am having a little problem with some programs from the Xenomai
> > test suite. The clocktest, cyclictest and switchtest crashes with
> > "Illegal instruction":
> 
> What about the latency test? If it fails with the same error, you
> could try the following patch for powerpc SPE:
> 
> https://git.xenomai.org/xenomai-2.6.git/commit/?id=d09932cfd0ca422989b3c3a9d736236d74590ade
> 



-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/038c502f/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> Hello!
>
> I am having a little problem with some programs from the Xenomai test
> suite. The clocktest, cyclictest and switchtest crashes with "Illegal
> instruction":
>
> ~ # /usr/xenomai/bin/clocktest
> == Tested clock: 0 (CLOCK_REALTIME)
> CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
> --- -------------------- ---------------- ---------- --------------
>    0                  0.0            0.000          0            0.0
> Illegal instruction
>
>

Please make sure you are using a compiler for the 6xx processor family, 
for building the user-space programs for an icecube/lite52xx/tqm5200 board.

If the issue is still there, you should run the failing test over gdb, 
then paste the backtrace output ("bt" command) obtained after the fault 
to this list.

> When I turn the debug.exception-trace kernel option on,
> and run the clocktest, I have got the following kernel message:
>
> clocktest[243]: unhandled signal 4 at 0fdf4e74 nip 0fdf4e74 lr 0ffd8af8
> code 30001
>

gdb will give you the faulty location in symbolic form.

> I have read in a previous messages on this list, that the
> CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
> unfortunately this did not help.
>

Unlocked switching is no more an issue with 3.8.13 and beyond.

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Thu, 28 Nov 2013 23:01:20 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> > Hello!
> >
> > I am having a little problem with some programs from the Xenomai
> > test suite. The clocktest, cyclictest and switchtest crashes with
> > "Illegal instruction":
> >
> > ~ # /usr/xenomai/bin/clocktest
> > == Tested clock: 0 (CLOCK_REALTIME)
> > CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
> > --- -------------------- ---------------- ---------- --------------
> >    0                  0.0            0.000          0            0.0
> > Illegal instruction
> >
> >
> 
> Please make sure you are using a compiler for the 6xx processor
> family, for building the user-space programs for an
> icecube/lite52xx/tqm5200 board.
I use eldk-switch in this way:
$ eldk-switch -r 5.4 gccb
[ gccb is using MPC5200 ]
Setup for powerpc (using ELDK 5.4)

with the following modification on the eldk-map.dat:
gccb            MPC5200

(GCCB is our custom MPC5200 based board)

$ echo $CC
powerpc-linux-gcc -m32 -mhard-float --sysroot=/opt/eldk-5.4/powerpc/sysroots/powerpc-linux
$ echo $CFLAGS 
-O2 -pipe -g -feliminate-unused-debug-types

$ powerpc-linux-gcc -dumpspecs | grep 603
...  %{mcpu=603: -mppc} %{mcpu=603e: -mppc} ...

I set the -mcpu=603e compilation flag on the trivial posix test, but this did not help.

> 
> If the issue is still there, you should run the failing test over
> gdb, then paste the backtrace output ("bt" command) obtained after
> the fault to this list.

Because there is limited amount of memory in our embedded system (32 MiB), I did the following:
On the target system:
~ # gdbserver 172.31.2.11:2001 /usr/xenomai/bin/clocktest

On the host system:
$ eldk-switch -r 5.4 gccb
[ gccb is using MPC5200 ]
Setup for powerpc (using ELDK 5.4)

$ powerpc-linux-gdb usr/xenomai/bin/clocktest
(gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux

(gdb) target remote 172.31.2.11:2001
Remote debugging using 172.31.2.11:2001
Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
done.
Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
_start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
32	../sysdeps/powerpc/powerpc32/dl-start.S: No such file or directory.

(gdb) cont
Continuing.
warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)
[New Thread 280]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 280]
0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6

(gdb) bt
#0  0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
#1  0x0ffd8af8 in sched_setconfig_np ()
   from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
#2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
#3  0x4802ff18 in _rtld_global_ro () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
Backtrace stopped: frame did not save the PC

As you can see, I have some problems with the GDB search paths, but the significant information is conspicuous.

> 
> > When I turn the debug.exception-trace kernel option on,
> > and run the clocktest, I have got the following kernel message:
> >
> > clocktest[243]: unhandled signal 4 at 0fdf4e74 nip 0fdf4e74 lr
> > 0ffd8af8 code 30001
> >
> 
> gdb will give you the faulty location in symbolic form.
If you can suggest, please, how I can override loaded libraries in gdb, then I will repeat the tests.
> 
> > I have read in a previous messages on this list, that the
> > CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
> > unfortunately this did not help.
> >
> 
> Unlocked switching is no more an issue with 3.8.13 and beyond.
Then I will turn it on again.
> 


-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/f275e740/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Thu, 28 Nov 2013 23:01:20 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 11/28/2013 02:31 PM, Bukuli Norbert wrote:
> > Hello!
> >
> > I am having a little problem with some programs from the Xenomai
> > test suite. The clocktest, cyclictest and switchtest crashes with
> > "Illegal instruction":
> >
> > ~ # /usr/xenomai/bin/clocktest
> > == Tested clock: 0 (CLOCK_REALTIME)
> > CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
> > --- -------------------- ---------------- ---------- --------------
> >    0                  0.0            0.000          0            0.0
> > Illegal instruction
> >
> >
> 
> Please make sure you are using a compiler for the 6xx processor
> family, for building the user-space programs for an
> icecube/lite52xx/tqm5200 board.
I use eldk-switch in this way:
$ eldk-switch -r 5.4 gccb
[ gccb is using MPC5200 ]
Setup for powerpc (using ELDK 5.4)

with the following modification on the eldk-map.dat:
gccb            MPC5200

(GCCB is our custom MPC5200 based board)

$ echo $CC
powerpc-linux-gcc -m32 -mhard-float --sysroot=/opt/eldk-5.4/powerpc/sysroots/powerpc-linux
$ echo $CFLAGS 
-O2 -pipe -g -feliminate-unused-debug-types

$ powerpc-linux-gcc -dumpspecs | grep 603
...  %{mcpu=603: -mppc} %{mcpu=603e: -mppc} ...

I set the -mcpu=603e compilation flag on the trivial posix test, but this did not help.

> 
> If the issue is still there, you should run the failing test over
> gdb, then paste the backtrace output ("bt" command) obtained after
> the fault to this list.

Because there is limited amount of memory in our embedded system (32 MiB), I did the following:
On the target system:
~ # gdbserver 172.31.2.11:2001 /usr/xenomai/bin/clocktest

On the host system:
$ eldk-switch -r 5.4 gccb
[ gccb is using MPC5200 ]
Setup for powerpc (using ELDK 5.4)

$ powerpc-linux-gdb usr/xenomai/bin/clocktest
(gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux

(gdb) target remote 172.31.2.11:2001
Remote debugging using 172.31.2.11:2001
Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
done.
Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
_start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
32	../sysdeps/powerpc/powerpc32/dl-start.S: No such file or directory.

(gdb) cont
Continuing.
warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)
[New Thread 280]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 280]
0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6

(gdb) bt
#0  0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
#1  0x0ffd8af8 in sched_setconfig_np ()
   from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
#2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
#3  0x4802ff18 in _rtld_global_ro () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
Backtrace stopped: frame did not save the PC

As you can see, I have some problems with the GDB search paths, but the significant information is conspicuous.

> 
> > When I turn the debug.exception-trace kernel option on,
> > and run the clocktest, I have got the following kernel message:
> >
> > clocktest[243]: unhandled signal 4 at 0fdf4e74 nip 0fdf4e74 lr
> > 0ffd8af8 code 30001
> >
> 
> gdb will give you the faulty location in symbolic form.
If you can suggest, please, how I can override loaded libraries in gdb, then I will repeat the tests.
> 
> > I have read in a previous messages on this list, that the
> > CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
> > unfortunately this did not help.
> >
> 
> Unlocked switching is no more an issue with 3.8.13 and beyond.
Then I will turn it on again.
> 


-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/1634a7b5/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> (gdb) cont
> Continuing.
> warning: Could not load shared library symbols for linux-vdso32.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
> warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)

These warnings may trigger with recent broken gdbserver releases, let's 
ignore them.
https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html

> [New Thread 280]
>
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 280]
> 0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
>

(gdb) disass $pc-64 $pc+20

would help at this point.

> (gdb) bt
> #0  0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> #1  0x0ffd8af8 in sched_setconfig_np ()
>     from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313

Is sched_setconfig_np() really the start routine given to 
pthread_create() in your application, I guess not. Or could this weird 
backtrace reveal a stack overflow?

>> gdb will give you the faulty location in symbolic form.
> If you can suggest, please, how I can override loaded libraries in gdb, then I will repeat the tests.

You could set solib-search-path appropriately or load them manually 
using file (-readnow), but I don't think this would help in 
understanding this particular issue. It somewhat behaves as if broken 
Xenomai syscall code was output by the compiler - this is something we 
faced a couple of times already on arm and ppc in the past years. 
Checking the disassembled code surrounding the fault location may help 
figuring this out.

>>
>>> I have read in a previous messages on this list, that the
>>> CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
>>> unfortunately this did not help.
>>>
>>
>> Unlocked switching is no more an issue with 3.8.13 and beyond.
> Then I will turn it on again.

You can also leave it off. On architectures with sane caches (e.g. not 
armv5 and its aliasing issues), it basically depends on whether shorter 
(real-time) interrupt latencies [on] are preferred over shorter task 
scheduling latencies [off]. The difference will likely only amount for a 
couple of micro-seconds max on most platforms though, however both 
options are available with 3.8+ pipelines.

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 11/29/2013 10:29 AM, Philippe Gerum wrote:
> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
>> (gdb) cont
>> Continuing.
>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> warning: .dynamic section for
>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
>> is not at the expected address (wrong library or version mismatch?)
>> warning: .dynamic section for
>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
>> is not at the expected address (wrong library or version mismatch?)
>
> These warnings may trigger with recent broken gdbserver releases, let's
> ignore them.
> https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html
>
>> [New Thread 280]
>>
>> Program received signal SIGILL, Illegal instruction.
>> [Switching to Thread 280]
>> 0x0fdf4e74 in ?? () from
>> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
>>
>
> (gdb) disass $pc-64 $pc+20
>
> would help at this point.
>
>> (gdb) bt
>> #0  0x0fdf4e74 in ?? () from
>> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
>> #1  0x0ffd8af8 in sched_setconfig_np ()
>>     from
>> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
>>
>> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
>
> Is sched_setconfig_np() really the start routine given to
> pthread_create() in your application, I guess not. Or could this weird
> backtrace reveal a stack overflow?

Or maybe just too much frame information is optimized out, too 
aggressively. You may want to turn on debug symbols for building the 
Xenomai libraries, using --enable-debug.

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Fri, 29 Nov 2013 10:34:55 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 11/29/2013 10:29 AM, Philippe Gerum wrote:
> > On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> >> (gdb) cont
> >> Continuing.
> >> warning: Could not load shared library symbols for
> >> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> >> sysroot"? warning: .dynamic section for
> >> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> >> is not at the expected address (wrong library or version mismatch?)
> >> warning: .dynamic section for
> >> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> >> is not at the expected address (wrong library or version mismatch?)
> >
> > These warnings may trigger with recent broken gdbserver releases,
> > let's ignore them.
> > https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html
> >
> >> [New Thread 280]
> >>
> >> Program received signal SIGILL, Illegal instruction.
> >> [Switching to Thread 280]
> >> 0x0fdf4e74 in ?? () from
> >> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> >>
> >
> > (gdb) disass $pc-64 $pc+20
> >
> > would help at this point.
> >
> >> (gdb) bt
> >> #0  0x0fdf4e74 in ?? () from
> >> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> >> #1  0x0ffd8af8 in sched_setconfig_np ()
> >>     from
> >> /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> >>
> >> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at
> >> pthread_create.c:313
> >
> > Is sched_setconfig_np() really the start routine given to
> > pthread_create() in your application, I guess not. Or could this
> > weird backtrace reveal a stack overflow?
> 
> Or maybe just too much frame information is optimized out, too 
> aggressively. You may want to turn on debug symbols for building the 
> Xenomai libraries, using --enable-debug.
> 

Recompiled xenomai with --enable-debug. Backtrace of clocktest is now:
(gdb) bt 
#0  0x0fdf4e74 in ?? () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
#1  0x0ffd8af8 in sched_setconfig_np ()
   from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
#2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
#3  0x4802ff18 in _rtld_global_ro () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
Backtrace stopped: frame did not save the PC


Unfortunately it does not matter if I load the proper libxenoma.so and
libpthread_rt.so before I continue the application:
(gdb) info sharedlibrary
>From        To          Syms Read   Shared Object Library
0x48001ff0  0x4801b014  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
                        No          linux-vdso32.so.1
0x0ffd7b1c  0x0ffdeab0  Yes (*)     /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
0x0ffaf588  0x0ffb2bb8  Yes (*)     /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0
0x0ff78b84  0x0ff873fc  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libpthread.so.0
0x0fe0a5c0  0x0ff1d844  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
0x0fdc3a94  0x0fdc799c  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/librt.so.1
(*): Shared library is missing debugging information.

Disassembly of the section:
(gdb) disass $pc-64,$pc+20
Dump of assembler code from 0xfdf4e34 to 0xfdf4e88:
   0x0fdf4e34:	.long 0x3894
   0x0fdf4e38:	.long 0x12b8a4
   0x0fdf4e3c:	.long 0x80
   0x0fdf4e40:	vaddfp  v16,v0,v0
   0x0fdf4e44:	.long 0x19fb
   0x0fdf4e48:	.long 0xe99c8
   0x0fdf4e4c:	.long 0xa0
   0x0fdf4e50:	vaddfp  v16,v0,v0
   0x0fdf4e54:	.long 0x2742
   0x0fdf4e58:	.long 0xe375c
   0x0fdf4e5c:	.long 0x4c
   0x0fdf4e60:	subfic  r16,r0,10
   0x0fdf4e64:	.long 0x378a
   0x0fdf4e68:	.long 0xf834c
   0x0fdf4e6c:	.long 0x58
   0x0fdf4e70:	vaddfp  v16,v0,v0
=> 0x0fdf4e74:	.long 0x5a3e
   0x0fdf4e78:	.long 0xe286c
   0x0fdf4e7c:	.long 0x68
   0x0fdf4e80:	vaddfp  v16,v0,v0
   0x0fdf4e84:	.long 0x80e
End of assembler dump.

Shall I turn off FPU support from the kernel entirely?
(In our application FPU is needed.)

-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/8bdf9359/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Fri, 29 Nov 2013 10:29:56 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> > (gdb) cont
> > Continuing.
> > warning: Could not load shared library symbols for
> > linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> > sysroot"? warning: .dynamic section for
> > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> > is not at the expected address (wrong library or version mismatch?)
> > warning: .dynamic section for
> > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> > is not at the expected address (wrong library or version mismatch?)
> 
> These warnings may trigger with recent broken gdbserver releases,
> let's ignore them.
> https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html
OK

> 
> > [New Thread 280]
> >
> > Program received signal SIGILL, Illegal instruction.
> > [Switching to Thread 280]
> > 0x0fdf4e74 in ?? ()
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> >
> 
> (gdb) disass $pc-64 $pc+20
(gdb) disass $pc-64,$pc+20
Dump of assembler code from 0xfdf4e34 to 0xfdf4e88:
   0x0fdf4e34:	.long 0x3894
   0x0fdf4e38:	.long 0x12b8a4
   0x0fdf4e3c:	.long 0x80
   0x0fdf4e40:	vaddfp  v16,v0,v0
   0x0fdf4e44:	.long 0x19fb
   0x0fdf4e48:	.long 0xe99c8
   0x0fdf4e4c:	.long 0xa0
   0x0fdf4e50:	vaddfp  v16,v0,v0
   0x0fdf4e54:	.long 0x2742
   0x0fdf4e58:	.long 0xe375c
   0x0fdf4e5c:	.long 0x4c
   0x0fdf4e60:	subfic  r16,r0,10
   0x0fdf4e64:	.long 0x378a
   0x0fdf4e68:	.long 0xf834c
   0x0fdf4e6c:	.long 0x58
   0x0fdf4e70:	vaddfp  v16,v0,v0
=> 0x0fdf4e74:	.long 0x5a3e
   0x0fdf4e78:	.long 0xe286c
   0x0fdf4e7c:	.long 0x68
   0x0fdf4e80:	vaddfp  v16,v0,v0
   0x0fdf4e84:	.long 0x80e
End of assembler dump

> 
> would help at this point.
> 
> > (gdb) bt
> > #0  0x0fdf4e74 in ?? ()
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6 #1
> > 0x0ffd8af8 in sched_setconfig_np ()
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> > #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at
> > pthread_create.c:313
> 
> Is sched_setconfig_np() really the start routine given to 
> pthread_create() in your application, I guess not. Or could this
> weird backtrace reveal a stack overflow?
This is the clocktest, not my trivial posix skin test. The start
routine in that is "cpu_thread()" in clocktest.c:196 in xenomai-2.6.3.

Debugging of the trivial posix skin test (my application):
(gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
(gdb) cont
The program is not being run.
(gdb) target remote 172.31.2.11:2001
Remote debugging using 172.31.2.11:2001
Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
done.
Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
_start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
32	../sysdeps/powerpc/powerpc32/dl-start.S: No such file or directory.
(gdb) cont
Continuing.
warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)
[New Thread 336]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 336]
0x480319f8 in ?? ()
(gdb) bt 
#0  0x480319f8 in ?? ()
#1  0x0ffd8af8 in sched_setconfig_np ()
   from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
#2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
#3  0x4802ff18 in _rtld_global_ro () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
Backtrace stopped: frame did not save the PC

(gdb) disass $pc-64,$pc+20
Dump of assembler code from 0x480319b8 to 0x48031a0c:
   0x480319b8:	.long 0x0
   0x480319bc:	.long 0x0
   0x480319c0:	.long 0x0
   0x480319c4:	.long 0x0
   0x480319c8:	.long 0x0
   0x480319cc:	.long 0x0
   0x480319d0:	cmpi    cr6,1,r21,29554
   0x480319d4:	cmpi    cr6,1,r24,25966
   0x480319d8:	xoris   r13,r27,24937
   0x480319dc:	cmpi    cr6,1,r12,26978
   0x480319e0:	cmpi    cr6,1,r12,26978
   0x480319e4:	andi.   r20,r3,26738
   0x480319e8:	oris    r1,r11,25695
   0x480319ec:	andi.   r20,r19,11891
   0x480319f0:	xoris   r14,r25,12544
   0x480319f4:	.long 0x0
=> 0x480319f8:	twi     31,r29,16384
   0x480319fc:	b       0x480633cc
   0x48031a00:	twi     31,r30,-3476
   0x48031a04:	b       0x480636cc
   0x48031a08:	b       0x48062e90
End of assembler dump.

(gdb) frame 1
#1  0x0ffd8af8 in sched_setconfig_np ()
   from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
(gdb) disass $pc-64,$pc+20
Dump of assembler code from 0xffd8ab8 to 0xffd8b0c:
   0x0ffd8ab8 <pthread_set_name_np+52>:	bl      0xffef720 <sigemptyset@plt>
   0x0ffd8abc <pthread_set_name_np+56>:	addi    r3,r31,20
   0x0ffd8ac0 <pthread_set_name_np+60>:	bl      0xffef540 <__real_sem_post@plt>
   0x0ffd8ac4 <pthread_set_name_np+64>:	lwz     r9,8(r1)
   0x0ffd8ac8 <pthread_set_name_np+68>:	cmpw    cr7,r9,r25
   0x0ffd8acc <pthread_set_name_np+72>:	beq-    cr7,0xffd8b38 <sched_setconfig_np+84>
   0x0ffd8ad0 <pthread_set_name_np+76>:	cmpwi   cr7,r28,0
   0x0ffd8ad4 <pthread_set_name_np+80>:	beq-    cr7,0xffd8aec <sched_setconfig_np+8>
   0x0ffd8ad8 <pthread_set_name_np+84>:	lis     r0,512
   0x0ffd8adc <pthread_set_name_np+88>:	li      r3,1
   0x0ffd8ae0:	ori     r0,r0,555
   0x0ffd8ae4 <sched_setconfig_np+0>:	sc      
   0x0ffd8ae8 <sched_setconfig_np+4>:	mfcr    r0
   0x0ffd8aec <sched_setconfig_np+8>:	mtctr   r27
   0x0ffd8af0 <sched_setconfig_np+12>:	mr      r3,r26
   0x0ffd8af4 <sched_setconfig_np+16>:	bctrl
=> 0x0ffd8af8 <sched_setconfig_np+20>:	li      r4,0
   0x0ffd8afc <sched_setconfig_np+24>:	mr      r31,r3
   0x0ffd8b00 <sched_setconfig_np+28>:	lis     r3,4
   0x0ffd8b04 <sched_setconfig_np+32>:	bl      0xffef5e0 <open@plt>
   0x0ffd8b08 <sched_setconfig_np+36>:	lwz     r0,68(r1)
End of assembler dump.

Please, note, that the file, in frame 1 in not equal to the actually used one, I do not use Xenomai provided by ELDK, I compiled it separately.

> 
> >> gdb will give you the faulty location in symbolic form.
> > If you can suggest, please, how I can override loaded libraries in
> > gdb, then I will repeat the tests.
> 
> You could set solib-search-path appropriately or load them manually 
> using file (-readnow), but I don't think this would help in 
> understanding this particular issue. It somewhat behaves as if broken 
> Xenomai syscall code was output by the compiler - this is something
> we faced a couple of times already on arm and ppc in the past years. 
> Checking the disassembled code surrounding the fault location may
> help figuring this out.

I see. Can I check somehow whether this happened?

> 
> >>
> >>> I have read in a previous messages on this list, that the
> >>> CONFIG_XENO_HW_UNLOCKED_SWITCH option should be turned off, but
> >>> unfortunately this did not help.
> >>>
> >>
> >> Unlocked switching is no more an issue with 3.8.13 and beyond.
> > Then I will turn it on again.
> 
> You can also leave it off. On architectures with sane caches (e.g.
> not armv5 and its aliasing issues), it basically depends on whether
> shorter (real-time) interrupt latencies [on] are preferred over
> shorter task scheduling latencies [off]. The difference will likely
> only amount for a couple of micro-seconds max on most platforms
> though, however both options are available with 3.8+ pipelines.
> 
I see. I left it off in the tests mentioned above.


-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131129/a062f4cc/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 11/29/2013 11:27 AM, Bukuli Norbert wrote:
>
>
> On Fri, 29 Nov 2013 10:29:56 +0100
> Philippe Gerum <rpm@xenomai.org> wrote:
>> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
>>> (gdb) cont
>>> Continuing.
>>> warning: Could not load shared library symbols for
>>> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
>>> sysroot"? warning: .dynamic section for
>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
>>> is not at the expected address (wrong library or version mismatch?)
>>> warning: .dynamic section for
>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
>>> is not at the expected address (wrong library or version mismatch?)
>>
>> These warnings may trigger with recent broken gdbserver releases,
>> let's ignore them.
>> https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html
> OK
>
>>
>>> [New Thread 280]
>>>
>>> Program received signal SIGILL, Illegal instruction.
>>> [Switching to Thread 280]
>>> 0x0fdf4e74 in ?? ()
>>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
>>>
>>
>> (gdb) disass $pc-64 $pc+20
> (gdb) disass $pc-64,$pc+20
> Dump of assembler code from 0xfdf4e34 to 0xfdf4e88:
>     0x0fdf4e34:	.long 0x3894
>     0x0fdf4e38:	.long 0x12b8a4
>     0x0fdf4e3c:	.long 0x80
>     0x0fdf4e40:	vaddfp  v16,v0,v0
>     0x0fdf4e44:	.long 0x19fb
>     0x0fdf4e48:	.long 0xe99c8
>     0x0fdf4e4c:	.long 0xa0
>     0x0fdf4e50:	vaddfp  v16,v0,v0
>     0x0fdf4e54:	.long 0x2742
>     0x0fdf4e58:	.long 0xe375c
>     0x0fdf4e5c:	.long 0x4c
>     0x0fdf4e60:	subfic  r16,r0,10
>     0x0fdf4e64:	.long 0x378a
>     0x0fdf4e68:	.long 0xf834c
>     0x0fdf4e6c:	.long 0x58
>     0x0fdf4e70:	vaddfp  v16,v0,v0
> => 0x0fdf4e74:	.long 0x5a3e
>     0x0fdf4e78:	.long 0xe286c
>     0x0fdf4e7c:	.long 0x68
>     0x0fdf4e80:	vaddfp  v16,v0,v0
>     0x0fdf4e84:	.long 0x80e
> End of assembler dump
>
>>
>> would help at this point.
>>
>>> (gdb) bt
>>> #0  0x0fdf4e74 in ?? ()
>>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6 #1
>>> 0x0ffd8af8 in sched_setconfig_np ()
>>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
>>> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at
>>> pthread_create.c:313
>>
>> Is sched_setconfig_np() really the start routine given to
>> pthread_create() in your application, I guess not. Or could this
>> weird backtrace reveal a stack overflow?
> This is the clocktest, not my trivial posix skin test. The start
> routine in that is "cpu_thread()" in clocktest.c:196 in xenomai-2.6.3.
>
> Debugging of the trivial posix skin test (my application):
> (gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
> (gdb) cont
> The program is not being run.
> (gdb) target remote 172.31.2.11:2001
> Remote debugging using 172.31.2.11:2001
> Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
> done.
> Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
> 32	../sysdeps/powerpc/powerpc32/dl-start.S: No such file or directory.
> (gdb) cont
> Continuing.
> warning: Could not load shared library symbols for linux-vdso32.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
> warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)
> [New Thread 336]
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 336]
> 0x480319f8 in ?? ()
> (gdb) bt
> #0  0x480319f8 in ?? ()
> #1  0x0ffd8af8 in sched_setconfig_np ()
>     from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at pthread_create.c:313
> #3  0x4802ff18 in _rtld_global_ro () from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> Backtrace stopped: frame did not save the PC
>
> (gdb) disass $pc-64,$pc+20
> Dump of assembler code from 0x480319b8 to 0x48031a0c:
>     0x480319b8:	.long 0x0
>     0x480319bc:	.long 0x0
>     0x480319c0:	.long 0x0
>     0x480319c4:	.long 0x0
>     0x480319c8:	.long 0x0
>     0x480319cc:	.long 0x0
>     0x480319d0:	cmpi    cr6,1,r21,29554
>     0x480319d4:	cmpi    cr6,1,r24,25966
>     0x480319d8:	xoris   r13,r27,24937
>     0x480319dc:	cmpi    cr6,1,r12,26978
>     0x480319e0:	cmpi    cr6,1,r12,26978
>     0x480319e4:	andi.   r20,r3,26738
>     0x480319e8:	oris    r1,r11,25695
>     0x480319ec:	andi.   r20,r19,11891
>     0x480319f0:	xoris   r14,r25,12544
>     0x480319f4:	.long 0x0
> => 0x480319f8:	twi     31,r29,16384
>     0x480319fc:	b       0x480633cc
>     0x48031a00:	twi     31,r30,-3476
>     0x48031a04:	b       0x480636cc
>     0x48031a08:	b       0x48062e90
> End of assembler dump.
>
> (gdb) frame 1
> #1  0x0ffd8af8 in sched_setconfig_np ()
>     from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> (gdb) disass $pc-64,$pc+20
> Dump of assembler code from 0xffd8ab8 to 0xffd8b0c:
>     0x0ffd8ab8 <pthread_set_name_np+52>:	bl      0xffef720 <sigemptyset@plt>
>     0x0ffd8abc <pthread_set_name_np+56>:	addi    r3,r31,20
>     0x0ffd8ac0 <pthread_set_name_np+60>:	bl      0xffef540 <__real_sem_post@plt>
>     0x0ffd8ac4 <pthread_set_name_np+64>:	lwz     r9,8(r1)
>     0x0ffd8ac8 <pthread_set_name_np+68>:	cmpw    cr7,r9,r25
>     0x0ffd8acc <pthread_set_name_np+72>:	beq-    cr7,0xffd8b38 <sched_setconfig_np+84>
>     0x0ffd8ad0 <pthread_set_name_np+76>:	cmpwi   cr7,r28,0
>     0x0ffd8ad4 <pthread_set_name_np+80>:	beq-    cr7,0xffd8aec <sched_setconfig_np+8>
>     0x0ffd8ad8 <pthread_set_name_np+84>:	lis     r0,512
>     0x0ffd8adc <pthread_set_name_np+88>:	li      r3,1
>     0x0ffd8ae0:	ori     r0,r0,555
>     0x0ffd8ae4 <sched_setconfig_np+0>:	sc
>     0x0ffd8ae8 <sched_setconfig_np+4>:	mfcr    r0
>     0x0ffd8aec <sched_setconfig_np+8>:	mtctr   r27
>     0x0ffd8af0 <sched_setconfig_np+12>:	mr      r3,r26
>     0x0ffd8af4 <sched_setconfig_np+16>:	bctrl
> => 0x0ffd8af8 <sched_setconfig_np+20>:	li      r4,0
>     0x0ffd8afc <sched_setconfig_np+24>:	mr      r31,r3
>     0x0ffd8b00 <sched_setconfig_np+28>:	lis     r3,4
>     0x0ffd8b04 <sched_setconfig_np+32>:	bl      0xffef5e0 <open@plt>
>     0x0ffd8b08 <sched_setconfig_np+36>:	lwz     r0,68(r1)
> End of assembler dump.
>
> Please, note, that the file, in frame 1 in not equal to the actually used one, I do not use Xenomai provided by ELDK, I compiled it separately.
>

Which explains why the symbol resolution in this disassembly does not 
make any sense. This is going to be quite hard to find out what goes 
wrong in your setup until we do know what code is running.

Step 1. Did you ever try running the Xenomai libraries as shipped in the 
eldk 5.4, keeping your kernel? Does clocktest runs fine there?

We need to know whether this is an issue with how your own Xenomai 
install is built, or if a library mismatch is at work on your setup.

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Fri, 29 Nov 2013 16:33:24 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 11/29/2013 11:27 AM, Bukuli Norbert wrote:
> >
> >
> > On Fri, 29 Nov 2013 10:29:56 +0100
> > Philippe Gerum <rpm@xenomai.org> wrote:
> >> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> >>> (gdb) cont
> >>> Continuing.
> >>> warning: Could not load shared library symbols for
> >>> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> >>> sysroot"? warning: .dynamic section for
> >>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> >>> is not at the expected address (wrong library or version
> >>> mismatch?) warning: .dynamic section for
> >>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> >>> is not at the expected address (wrong library or version
> >>> mismatch?)
> >>
> >> These warnings may trigger with recent broken gdbserver releases,
> >> let's ignore them.
> >> https://sourceware.org/ml/gdb-patches/2013-06/msg00054.html
> > OK
> >
> >>
> >>> [New Thread 280]
> >>>
> >>> Program received signal SIGILL, Illegal instruction.
> >>> [Switching to Thread 280]
> >>> 0x0fdf4e74 in ?? ()
> >>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> >>>
> >>
> >> (gdb) disass $pc-64 $pc+20
> > (gdb) disass $pc-64,$pc+20
> > Dump of assembler code from 0xfdf4e34 to 0xfdf4e88:
> >     0x0fdf4e34:	.long 0x3894
> >     0x0fdf4e38:	.long 0x12b8a4
> >     0x0fdf4e3c:	.long 0x80
> >     0x0fdf4e40:	vaddfp  v16,v0,v0
> >     0x0fdf4e44:	.long 0x19fb
> >     0x0fdf4e48:	.long 0xe99c8
> >     0x0fdf4e4c:	.long 0xa0
> >     0x0fdf4e50:	vaddfp  v16,v0,v0
> >     0x0fdf4e54:	.long 0x2742
> >     0x0fdf4e58:	.long 0xe375c
> >     0x0fdf4e5c:	.long 0x4c
> >     0x0fdf4e60:	subfic  r16,r0,10
> >     0x0fdf4e64:	.long 0x378a
> >     0x0fdf4e68:	.long 0xf834c
> >     0x0fdf4e6c:	.long 0x58
> >     0x0fdf4e70:	vaddfp  v16,v0,v0
> > => 0x0fdf4e74:	.long 0x5a3e
> >     0x0fdf4e78:	.long 0xe286c
> >     0x0fdf4e7c:	.long 0x68
> >     0x0fdf4e80:	vaddfp  v16,v0,v0
> >     0x0fdf4e84:	.long 0x80e
> > End of assembler dump
> >
> >>
> >> would help at this point.
> >>
> >>> (gdb) bt
> >>> #0  0x0fdf4e74 in ?? ()
> >>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6 #1
> >>> 0x0ffd8af8 in sched_setconfig_np ()
> >>> from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> >>> #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at
> >>> pthread_create.c:313
> >>
> >> Is sched_setconfig_np() really the start routine given to
> >> pthread_create() in your application, I guess not. Or could this
> >> weird backtrace reveal a stack overflow?
> > This is the clocktest, not my trivial posix skin test. The start
> > routine in that is "cpu_thread()" in clocktest.c:196 in
> > xenomai-2.6.3.
> >
> > Debugging of the trivial posix skin test (my application):
> > (gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
> > (gdb) cont
> > The program is not being run.
> > (gdb) target remote 172.31.2.11:2001
> > Remote debugging using 172.31.2.11:2001
> > Reading symbols
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading
> > symbols
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
> > done. Loaded symbols
> > for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1 _start
> > () at ../sysdeps/powerpc/powerpc32/dl-start.S:32
> > 32	../sysdeps/powerpc/powerpc32/dl-start.S: No such file or
> > directory. (gdb) cont Continuing. warning: Could not load shared
> > library symbols for linux-vdso32.so.1. Do you need "set
> > solib-search-path" or "set sysroot"? warning: .dynamic section for
> > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> > is not at the expected address (wrong library or version mismatch?)
> > warning: .dynamic section for
> > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> > is not at the expected address (wrong library or version mismatch?)
> > [New Thread 336]
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > [Switching to Thread 336]
> > 0x480319f8 in ?? ()
> > (gdb) bt
> > #0  0x480319f8 in ?? ()
> > #1  0x0ffd8af8 in sched_setconfig_np ()
> >     from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> > #2  0x0ff7ba68 in start_thread (arg=0xbffffdd0) at
> > pthread_create.c:313 #3  0x4802ff18 in _rtld_global_ro ()
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > Backtrace stopped: frame did not save the PC
> >
> > (gdb) disass $pc-64,$pc+20
> > Dump of assembler code from 0x480319b8 to 0x48031a0c:
> >     0x480319b8:	.long 0x0
> >     0x480319bc:	.long 0x0
> >     0x480319c0:	.long 0x0
> >     0x480319c4:	.long 0x0
> >     0x480319c8:	.long 0x0
> >     0x480319cc:	.long 0x0
> >     0x480319d0:	cmpi    cr6,1,r21,29554
> >     0x480319d4:	cmpi    cr6,1,r24,25966
> >     0x480319d8:	xoris   r13,r27,24937
> >     0x480319dc:	cmpi    cr6,1,r12,26978
> >     0x480319e0:	cmpi    cr6,1,r12,26978
> >     0x480319e4:	andi.   r20,r3,26738
> >     0x480319e8:	oris    r1,r11,25695
> >     0x480319ec:	andi.   r20,r19,11891
> >     0x480319f0:	xoris   r14,r25,12544
> >     0x480319f4:	.long 0x0
> > => 0x480319f8:	twi     31,r29,16384
> >     0x480319fc:	b       0x480633cc
> >     0x48031a00:	twi     31,r30,-3476
> >     0x48031a04:	b       0x480636cc
> >     0x48031a08:	b       0x48062e90
> > End of assembler dump.
> >
> > (gdb) frame 1
> > #1  0x0ffd8af8 in sched_setconfig_np ()
> >     from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> > (gdb) disass $pc-64,$pc+20
> > Dump of assembler code from 0xffd8ab8 to 0xffd8b0c:
> >     0x0ffd8ab8 <pthread_set_name_np+52>:	bl      0xffef720
> > <sigemptyset@plt> 0x0ffd8abc <pthread_set_name_np+56>:
> > addi    r3,r31,20 0x0ffd8ac0 <pthread_set_name_np+60>:
> > bl      0xffef540 <__real_sem_post@plt> 0x0ffd8ac4
> > <pthread_set_name_np+64>:	lwz     r9,8(r1) 0x0ffd8ac8
> > <pthread_set_name_np+68>:	cmpw    cr7,r9,r25 0x0ffd8acc
> > <pthread_set_name_np+72>:	beq-    cr7,0xffd8b38
> > <sched_setconfig_np+84> 0x0ffd8ad0 <pthread_set_name_np+76>:
> > cmpwi   cr7,r28,0 0x0ffd8ad4 <pthread_set_name_np+80>:
> > beq-    cr7,0xffd8aec <sched_setconfig_np+8> 0x0ffd8ad8
> > <pthread_set_name_np+84>:	lis     r0,512 0x0ffd8adc
> > <pthread_set_name_np+88>:	li      r3,1 0x0ffd8ae0:
> > ori     r0,r0,555 0x0ffd8ae4 <sched_setconfig_np+0>:	sc
> > 0x0ffd8ae8 <sched_setconfig_np+4>:	mfcr    r0 0x0ffd8aec
> > <sched_setconfig_np+8>:	mtctr   r27 0x0ffd8af0
> > <sched_setconfig_np+12>:	mr      r3,r26 0x0ffd8af4
> > <sched_setconfig_np+16>:	bctrl => 0x0ffd8af8
> > <sched_setconfig_np+20>:	li      r4,0 0x0ffd8afc
> > <sched_setconfig_np+24>:	mr      r31,r3 0x0ffd8b00
> > <sched_setconfig_np+28>:	lis     r3,4 0x0ffd8b04
> > <sched_setconfig_np+32>:	bl      0xffef5e0 <open@plt>
> > 0x0ffd8b08 <sched_setconfig_np+36>:	lwz     r0,68(r1) End of
> > assembler dump.
> >
> > Please, note, that the file, in frame 1 in not equal to the
> > actually used one, I do not use Xenomai provided by ELDK, I
> > compiled it separately.
> >
> 
> Which explains why the symbol resolution in this disassembly does not 
> make any sense. This is going to be quite hard to find out what goes 
> wrong in your setup until we do know what code is running.
I see. 

> 
> Step 1. Did you ever try running the Xenomai libraries as shipped in
> the eldk 5.4, keeping your kernel? Does clocktest runs fine there?
Yes, I have tried it. I kept the kernel and used the minimal-xenomai
image as NFS root. Unfortunately the clocktest crash in the same way:
# /usr/xenomai/bin/powerpc-linux-clocktest 
== Tested clock: 0 (CLOCK_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------Xenomai: Switching powerpc-linux-c to secondary mode after exception #1792 from user-space at 0x4800ce74 (pid 306)
- --------------
  0                  0.0            0.000          0            0.0
Illegal instruction


# cat /proc/xenomai/faults 
TRAP         CPU0
  0:            0    (Data or instruction access)
  1:            0    (Alignment)
  2:            0    (Altivec unavailable)
  3:            1    (Program check exception)
  4:            0    (Machine check exception)
  5:            0    (Unknown)
  6:            0    (Instruction breakpoint)
  7:            0    (Run mode exception)
  8:            0    (Single-step exception)
  9:            0    (Non-recoverable exception)
 10:            0    (Software emulation)
 11:            0    (Debug)
 12:            0    (SPE)
 13:            0    (Altivec assist)
 14:            0    (Cache-locking exception)
 15:            0    (Kernel FP unavailable)


> 
> We need to know whether this is an issue with how your own Xenomai 
> install is built, or if a library mismatch is at work on your setup.
> 

I do not know whether the problem exists in the kernel or in the libraries, but there is no problem with the native skin.
The problem occures only when I use posix skin. This means, the regression tests corresponding to the native skin run well.

Best regards:
Norbert Bukuli

-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131202/d475dc8d/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Wolfgang Denk]

Dear Philippe Gerum,

In message <52985E94.4070101@xenomai.org> you wrote:
> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> > (gdb) cont
> > Continuing.
> > warning: Could not load shared library symbols for linux-vdso32.so.1.
> > Do you need "set solib-search-path" or "set sysroot"?
> > warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1" is not at the expected address (wrong library or version mismatch?)
> > warning: .dynamic section for "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0" is not at the expected address (wrong library or version mismatch?)
> 
> These warnings may trigger with recent broken gdbserver releases, let's 
> ignore them.

I don't think this is a good idea.  The actual problem is in the
previous warning:

warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?

You must set solib-search-path.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
After Goliath's defeat, giants ceased to command respect.
- Freeman Dyson

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Fri, 29 Nov 2013 23:53:20 +0100
Wolfgang Denk <wd@denx.de> wrote:
> Dear Philippe Gerum,
> 
> In message <52985E94.4070101@xenomai.org> you wrote:
> > On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> > > (gdb) cont
> > > Continuing.
> > > warning: Could not load shared library symbols for
> > > linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> > > sysroot"? warning: .dynamic section for
> > > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> > > is not at the expected address (wrong library or version
> > > mismatch?) warning: .dynamic section for
> > > "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> > > is not at the expected address (wrong library or version
> > > mismatch?)
> > 
> > These warnings may trigger with recent broken gdbserver releases,
> > let's ignore them.
> 
> I don't think this is a good idea.  The actual problem is in the
> previous warning:
> 
> warning: Could not load shared library symbols for linux-vdso32.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> 
> You must set solib-search-path.

As Philippe Gerum asked it, I have used the Xenomai libraries provided
by the ELDK 5.4 and kept my kernel. In the following test I set the
solib-search path and the sysroot properly, however the
powerpc-linux-gdb was unable to find linux-vdso32.so.1. I installed it
from the kernel with vdso_install but it creates
only /lib/modules/3.8.13/vdso/vdso32.so file.

What is the proper way to make the gdb know the linux-vdso32.so.1 file?
Shall I create a simlink to the vdso32.so file?

Anyway, after I created the simlink on the target system like this :
root@generic-powerpc:/lib# ln -s /lib/modules/3.8.13/vdso/vdso32.so linux-vdso32

and on the host system like this:
# cd $(POWERPC-SYSROOT)/lib/modules/3.8.13/vdso
# ln -s vdso32.so linux-vdso32.so.1

gdb found all libraries. However, there is no debugging info in the shared libraries, but I think the disassembled code around the crash point will be sufficient.

GDB output (irrelevant parts are removed):
$ powerpc-linux-gdb usr/xenomai/bin/powerpc-linux-clocktest
...
Reading symbols from /srv/tftpboot/172.31.2.11/usr/xenomai/bin/powerpc-linux-clocktest...(nodebugging symbols found)...done.

(gdb) set solib-search-path "/srv/tftpboot/172.31.2.11/lib/:/srv/tftpboot/172.31.2.11/usr/lib/:/srv/tftpboot/172.31.2.11/usr/xenomai/lib/:/srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/
(gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux

(gdb) target remote 172.31.2.11:2001
Remote debugging using 172.31.2.11:2001
Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
done.
Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
0x0ffd76e8 in ?? ()

(gdb) cont
Continuing.
[New Thread 338]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 338]
0x4800ce74 in ?? ()

(gdb) bt
#0  0x4800ce74 in ?? ()
#1  0x0ff98534 in ?? ()
#2  0x0fe17a68 in ?? ()
#3  0x480eba4c in ?? ()

(gdb) info sharedlibrary
>From        To          Syms Read   Shared Object Library
0x00001ff0  0x0001b014  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
0x00100360  0x00100648  No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
0x0ff979b4  0x0ff9e948  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
0x0ff6fba0  0x0ff731d0  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0
0x0fe14b84  0x0fe233fc  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libpthread.so.0
0x480225c0  0x48135844  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
0x0fdf1a94  0x0fdf599c  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/librt.so.1

(gdb) disass $pc-64,$pc+20
Dump of assembler code from 0x4800ce34 to 0x4800ce88:
   0x4800ce34:	.long 0x3894
   0x4800ce38:	twi     31,r22,-18268
   0x4800ce3c:	.long 0x80
   0x4800ce40:	vaddfp  v16,v0,v0
   0x4800ce44:	.long 0x19fb
   0x4800ce48:	twi     31,r18,-26168
   0x4800ce4c:	.long 0xa0
   0x4800ce50:	vaddfp  v16,v0,v0
   0x4800ce54:	.long 0x2742
   0x4800ce58:	twi     31,r18,14172
   0x4800ce5c:	.long 0x4c
   0x4800ce60:	subfic  r16,r0,10
   0x4800ce64:	.long 0x378a
   0x4800ce68:	twi     31,r19,-31924
   0x4800ce6c:	.long 0x58
   0x4800ce70:	vaddfp  v16,v0,v0
=> 0x4800ce74:	.long 0x5a3e
   0x4800ce78:	twi     31,r18,10348
   0x4800ce7c:	.long 0x68
   0x4800ce80:	vaddfp  v16,v0,v0
   0x4800ce84:	.long 0x80e
End of assembler dump.

As far as I know the ".long 0x5a3e" is not a valid instruction, is it?
Can ths cause my problem?
How can I provide more information about this problem? I cannot find
any splitted debug information of the xenomai libraries neither in the
rootfs-minimal-xenomai, nor in the rootfs-qte-xenomai-sdk. By the way,
this later one probably use different compilation flags for the xenomai
libraries as the earlier one, thus the splitted debug infos may be
wrong.

Thank you for the kind answers in advance!

> 
> Best regards,
> 
> Wolfgang Denk
> 



-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131202/c40ec12a/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 12/02/2013 09:50 AM, Bukuli Norbert wrote:

> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 338]
> 0x4800ce74 in ?? ()
>
> (gdb) bt
> #0  0x4800ce74 in ?? ()
> #1  0x0ff98534 in ?? ()
> #2  0x0fe17a68 in ?? ()
> #3  0x480eba4c in ?? ()
>
> (gdb) info sharedlibrary
>  From        To          Syms Read   Shared Object Library
> 0x00001ff0  0x0001b014  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> 0x00100360  0x00100648  No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> 0x0ff979b4  0x0ff9e948  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1

For some reason, it looks like the program flow jumps to a weird 
location. Assuming this backtrace is right, the last location that would 
make sense seems to be frame #1 at 0x0ff98534 in libpthread_rt.so.1, 
which is Xenomai's POSIX interface library.

- could you please make a full disassembly of libpthread_rt.so.1 
accessible via pastebin?

- we already had these kinds of events a couple of times on different 
architectures with new gcc releases due to, either broken TLS code 
generation by gcc, or some weaknesses in our inline syscall trampoline 
code with respect to expressing constraints. Is --with-__thread enabled 
when configuring the Xenomai build for libaries and programs?

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Mon, 2 Dec 2013 10:15:22 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
> 
> > Program received signal SIGILL, Illegal instruction.
> > [Switching to Thread 338]
> > 0x4800ce74 in ?? ()
> >
> > (gdb) bt
> > #0  0x4800ce74 in ?? ()
> > #1  0x0ff98534 in ?? ()
> > #2  0x0fe17a68 in ?? ()
> > #3  0x480eba4c in ?? ()
> >
> > (gdb) info sharedlibrary
> >  From        To          Syms Read   Shared Object Library
> > 0x00001ff0  0x0001b014
> > Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > 0x00100360  0x00100648
> > No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> > 0x0ff979b4  0x0ff9e948
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> 
> For some reason, it looks like the program flow jumps to a weird 
> location. Assuming this backtrace is right, the last location that
> would make sense seems to be frame #1 at 0x0ff98534 in
> libpthread_rt.so.1, which is Xenomai's POSIX interface library.
> 
> - could you please make a full disassembly of libpthread_rt.so.1 
> accessible via pastebin?

Of course. You can find the output of
$ powerpc-linux-objdump -d libpthread_rt.so.1
here:
http://pastebin.com/uywTZGfg

> 
> - we already had these kinds of events a couple of times on different 
> architectures with new gcc releases due to, either broken TLS code 
> generation by gcc, or some weaknesses in our inline syscall
> trampoline code with respect to expressing constraints. Is
> --with-__thread enabled when configuring the Xenomai build for
> libaries and programs?
> 
Unfortunatelly I do not know exactly. The stock ELDK-5.4 version of
libpthread_rt.so.1 is used. I will check it up.



-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131202/f394c3b7/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 12/02/2013 10:24 AM, Bukuli Norbert wrote:
>
>
> On Mon, 2 Dec 2013 10:15:22 +0100
> Philippe Gerum <rpm@xenomai.org> wrote:
>> On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
>>
>>> Program received signal SIGILL, Illegal instruction.
>>> [Switching to Thread 338]
>>> 0x4800ce74 in ?? ()
>>>
>>> (gdb) bt
>>> #0  0x4800ce74 in ?? ()
>>> #1  0x0ff98534 in ?? ()
>>> #2  0x0fe17a68 in ?? ()
>>> #3  0x480eba4c in ?? ()
>>>
>>> (gdb) info sharedlibrary
>>>   From        To          Syms Read   Shared Object Library
>>> 0x00001ff0  0x0001b014
>>> Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
>>> 0x00100360  0x00100648
>>> No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
>>> 0x0ff979b4  0x0ff9e948
>>> No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
>>
>> For some reason, it looks like the program flow jumps to a weird
>> location. Assuming this backtrace is right, the last location that
>> would make sense seems to be frame #1 at 0x0ff98534 in
>> libpthread_rt.so.1, which is Xenomai's POSIX interface library.
>>
>> - could you please make a full disassembly of libpthread_rt.so.1
>> accessible via pastebin?
>
> Of course. You can find the output of
> $ powerpc-linux-objdump -d libpthread_rt.so.1
> here:
> http://pastebin.com/uywTZGfg
>

Ok, thanks. I will have a look.

>>
>> - we already had these kinds of events a couple of times on different
>> architectures with new gcc releases due to, either broken TLS code
>> generation by gcc, or some weaknesses in our inline syscall
>> trampoline code with respect to expressing constraints. Is
>> --with-__thread enabled when configuring the Xenomai build for
>> libaries and programs?
>>
> Unfortunatelly I do not know exactly. The stock ELDK-5.4 version of
> libpthread_rt.so.1 is used. I will check it up.
>

Please don't bother. From the disassembly you just sent, TLS support is 
not used (--with-__thread disabled).

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Mon, 2 Dec 2013 10:41:48 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 12/02/2013 10:24 AM, Bukuli Norbert wrote:
> >
> >
> > On Mon, 2 Dec 2013 10:15:22 +0100
> > Philippe Gerum <rpm@xenomai.org> wrote:
> >> On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
> >>
> >>> Program received signal SIGILL, Illegal instruction.
> >>> [Switching to Thread 338]
> >>> 0x4800ce74 in ?? ()
> >>>
> >>> (gdb) bt
> >>> #0  0x4800ce74 in ?? ()
> >>> #1  0x0ff98534 in ?? ()
> >>> #2  0x0fe17a68 in ?? ()
> >>> #3  0x480eba4c in ?? ()
> >>>
> >>> (gdb) info sharedlibrary
> >>>   From        To          Syms Read   Shared Object Library
> >>> 0x00001ff0  0x0001b014
> >>> Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> >>> 0x00100360  0x00100648
> >>> No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> >>> 0x0ff979b4  0x0ff9e948
> >>> No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> >>
> >> For some reason, it looks like the program flow jumps to a weird
> >> location. Assuming this backtrace is right, the last location that
> >> would make sense seems to be frame #1 at 0x0ff98534 in
> >> libpthread_rt.so.1, which is Xenomai's POSIX interface library.
> >>
> >> - could you please make a full disassembly of libpthread_rt.so.1
> >> accessible via pastebin?
> >
> > Of course. You can find the output of
> > $ powerpc-linux-objdump -d libpthread_rt.so.1
> > here:
> > http://pastebin.com/uywTZGfg
> >
> 
> Ok, thanks. I will have a look.

Thank you!

> 
> >>
> >> - we already had these kinds of events a couple of times on
> >> different architectures with new gcc releases due to, either
> >> broken TLS code generation by gcc, or some weaknesses in our
> >> inline syscall trampoline code with respect to expressing
> >> constraints. Is --with-__thread enabled when configuring the
> >> Xenomai build for libaries and programs?
> >>
> > Unfortunatelly I do not know exactly. The stock ELDK-5.4 version of
> > libpthread_rt.so.1 is used. I will check it up.
> >
> 
> Please don't bother. From the disassembly you just sent, TLS support
> is not used (--with-__thread disabled).
> 
All right.



-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131202/c0cee77d/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Philippe Gerum]

On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
>
>
> On Fri, 29 Nov 2013 23:53:20 +0100
> Wolfgang Denk <wd@denx.de> wrote:
>> Dear Philippe Gerum,
>>
>> In message <52985E94.4070101@xenomai.org> you wrote:
>>> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
>>>> (gdb) cont
>>>> Continuing.
>>>> warning: Could not load shared library symbols for
>>>> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
>>>> sysroot"? warning: .dynamic section for
>>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
>>>> is not at the expected address (wrong library or version
>>>> mismatch?) warning: .dynamic section for
>>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
>>>> is not at the expected address (wrong library or version
>>>> mismatch?)
>>>
>>> These warnings may trigger with recent broken gdbserver releases,
>>> let's ignore them.
>>
>> I don't think this is a good idea.  The actual problem is in the
>> previous warning:
>>
>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>>
>> You must set solib-search-path.
>
> As Philippe Gerum asked it, I have used the Xenomai libraries provided
> by the ELDK 5.4 and kept my kernel. In the following test I set the
> solib-search path and the sysroot properly, however the
> powerpc-linux-gdb was unable to find linux-vdso32.so.1. I installed it
> from the kernel with vdso_install but it creates
> only /lib/modules/3.8.13/vdso/vdso32.so file.
>
> What is the proper way to make the gdb know the linux-vdso32.so.1 file?
> Shall I create a simlink to the vdso32.so file?
>
> Anyway, after I created the simlink on the target system like this :
> root@generic-powerpc:/lib# ln -s /lib/modules/3.8.13/vdso/vdso32.so linux-vdso32
>
> and on the host system like this:
> # cd $(POWERPC-SYSROOT)/lib/modules/3.8.13/vdso
> # ln -s vdso32.so linux-vdso32.so.1
>
> gdb found all libraries. However, there is no debugging info in the shared libraries, but I think the disassembled code around the crash point will be sufficient.
>
> GDB output (irrelevant parts are removed):
> $ powerpc-linux-gdb usr/xenomai/bin/powerpc-linux-clocktest
> ...
> Reading symbols from /srv/tftpboot/172.31.2.11/usr/xenomai/bin/powerpc-linux-clocktest...(nodebugging symbols found)...done.
>
> (gdb) set solib-search-path "/srv/tftpboot/172.31.2.11/lib/:/srv/tftpboot/172.31.2.11/usr/lib/:/srv/tftpboot/172.31.2.11/usr/xenomai/lib/:/srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/
> (gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
>
> (gdb) target remote 172.31.2.11:2001
> Remote debugging using 172.31.2.11:2001
> Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading symbols from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
> done.
> Loaded symbols for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> 0x0ffd76e8 in ?? ()
>
> (gdb) cont
> Continuing.
> [New Thread 338]
>
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 338]
> 0x4800ce74 in ?? ()
>
> (gdb) bt
> #0  0x4800ce74 in ?? ()
> #1  0x0ff98534 in ?? ()
> #2  0x0fe17a68 in ?? ()
> #3  0x480eba4c in ?? ()
>
> (gdb) info sharedlibrary
>  From        To          Syms Read   Shared Object Library
> 0x00001ff0  0x0001b014  Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> 0x00100360  0x00100648  No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> 0x0ff979b4  0x0ff9e948  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> 0x0ff6fba0  0x0ff731d0  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0
> 0x0fe14b84  0x0fe233fc  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libpthread.so.0
> 0x480225c0  0x48135844  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> 0x0fdf1a94  0x0fdf599c  No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/librt.so.1
>
> (gdb) disass $pc-64,$pc+20
> Dump of assembler code from 0x4800ce34 to 0x4800ce88:
>     0x4800ce34:	.long 0x3894
>     0x4800ce38:	twi     31,r22,-18268
>     0x4800ce3c:	.long 0x80
>     0x4800ce40:	vaddfp  v16,v0,v0
>     0x4800ce44:	.long 0x19fb
>     0x4800ce48:	twi     31,r18,-26168
>     0x4800ce4c:	.long 0xa0
>     0x4800ce50:	vaddfp  v16,v0,v0
>     0x4800ce54:	.long 0x2742
>     0x4800ce58:	twi     31,r18,14172
>     0x4800ce5c:	.long 0x4c
>     0x4800ce60:	subfic  r16,r0,10
>     0x4800ce64:	.long 0x378a
>     0x4800ce68:	twi     31,r19,-31924
>     0x4800ce6c:	.long 0x58
>     0x4800ce70:	vaddfp  v16,v0,v0
> => 0x4800ce74:	.long 0x5a3e
>     0x4800ce78:	twi     31,r18,10348
>     0x4800ce7c:	.long 0x68
>     0x4800ce80:	vaddfp  v16,v0,v0
>     0x4800ce84:	.long 0x80e
> End of assembler dump.
>

While we are at it, could please you paste-bin a larger disassembly ( 
$pc-256, $pc + 256) of frame #1, just below this one? I'd like to see 
the call site.

Also, could you paste-bin the disassembly of libxenomai.so?

TIA,

-- 
Philippe.

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Mon, 2 Dec 2013 10:58:42 +0100
Philippe Gerum <rpm@xenomai.org> wrote:
> On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
> >
> >
> > On Fri, 29 Nov 2013 23:53:20 +0100
> > Wolfgang Denk <wd@denx.de> wrote:
> >> Dear Philippe Gerum,
> >>
> >> In message <52985E94.4070101@xenomai.org> you wrote:
> >>> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> >>>> (gdb) cont
> >>>> Continuing.
> >>>> warning: Could not load shared library symbols for
> >>>> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> >>>> sysroot"? warning: .dynamic section for
> >>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> >>>> is not at the expected address (wrong library or version
> >>>> mismatch?) warning: .dynamic section for
> >>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> >>>> is not at the expected address (wrong library or version
> >>>> mismatch?)
> >>>
> >>> These warnings may trigger with recent broken gdbserver releases,
> >>> let's ignore them.
> >>
> >> I don't think this is a good idea.  The actual problem is in the
> >> previous warning:
> >>
> >> warning: Could not load shared library symbols for
> >> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> >> sysroot"?
> >>
> >> You must set solib-search-path.
> >
> > As Philippe Gerum asked it, I have used the Xenomai libraries
> > provided by the ELDK 5.4 and kept my kernel. In the following test
> > I set the solib-search path and the sysroot properly, however the
> > powerpc-linux-gdb was unable to find linux-vdso32.so.1. I installed
> > it from the kernel with vdso_install but it creates
> > only /lib/modules/3.8.13/vdso/vdso32.so file.
> >
> > What is the proper way to make the gdb know the linux-vdso32.so.1
> > file? Shall I create a simlink to the vdso32.so file?
> >
> > Anyway, after I created the simlink on the target system like this :
> > root@generic-powerpc:/lib# ln -s /lib/modules/3.8.13/vdso/vdso32.so
> > linux-vdso32
> >
> > and on the host system like this:
> > # cd $(POWERPC-SYSROOT)/lib/modules/3.8.13/vdso
> > # ln -s vdso32.so linux-vdso32.so.1
> >
> > gdb found all libraries. However, there is no debugging info in the
> > shared libraries, but I think the disassembled code around the
> > crash point will be sufficient.
> >
> > GDB output (irrelevant parts are removed):
> > $ powerpc-linux-gdb usr/xenomai/bin/powerpc-linux-clocktest
> > ...
> > Reading symbols
> > from /srv/tftpboot/172.31.2.11/usr/xenomai/bin/powerpc-linux-clocktest...(nodebugging
> > symbols found)...done.
> >
> > (gdb) set solib-search-path
> > "/srv/tftpboot/172.31.2.11/lib/:/srv/tftpboot/172.31.2.11/usr/lib/:/srv/tftpboot/172.31.2.11/usr/xenomai/lib/:/srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/
> > (gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
> >
> > (gdb) target remote 172.31.2.11:2001
> > Remote debugging using 172.31.2.11:2001
> > Reading symbols
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading
> > symbols
> > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
> > done. Loaded symbols
> > for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > 0x0ffd76e8 in ?? ()
> >
> > (gdb) cont
> > Continuing.
> > [New Thread 338]
> >
> > Program received signal SIGILL, Illegal instruction.
> > [Switching to Thread 338]
> > 0x4800ce74 in ?? ()
> >
> > (gdb) bt
> > #0  0x4800ce74 in ?? ()
> > #1  0x0ff98534 in ?? ()
> > #2  0x0fe17a68 in ?? ()
> > #3  0x480eba4c in ?? ()
> >
> > (gdb) info sharedlibrary
> >  From        To          Syms Read   Shared Object Library
> > 0x00001ff0  0x0001b014
> > Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > 0x00100360  0x00100648
> > No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> > 0x0ff979b4  0x0ff9e948
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> > 0x0ff6fba0  0x0ff731d0
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0
> > 0x0fe14b84  0x0fe233fc
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libpthread.so.0
> > 0x480225c0  0x48135844
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> > 0x0fdf1a94  0x0fdf599c
> > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/librt.so.1
> >
> > (gdb) disass $pc-64,$pc+20
> > Dump of assembler code from 0x4800ce34 to 0x4800ce88:
> >     0x4800ce34:	.long 0x3894
> >     0x4800ce38:	twi     31,r22,-18268
> >     0x4800ce3c:	.long 0x80
> >     0x4800ce40:	vaddfp  v16,v0,v0
> >     0x4800ce44:	.long 0x19fb
> >     0x4800ce48:	twi     31,r18,-26168
> >     0x4800ce4c:	.long 0xa0
> >     0x4800ce50:	vaddfp  v16,v0,v0
> >     0x4800ce54:	.long 0x2742
> >     0x4800ce58:	twi     31,r18,14172
> >     0x4800ce5c:	.long 0x4c
> >     0x4800ce60:	subfic  r16,r0,10
> >     0x4800ce64:	.long 0x378a
> >     0x4800ce68:	twi     31,r19,-31924
> >     0x4800ce6c:	.long 0x58
> >     0x4800ce70:	vaddfp  v16,v0,v0
> > => 0x4800ce74:	.long 0x5a3e
> >     0x4800ce78:	twi     31,r18,10348
> >     0x4800ce7c:	.long 0x68
> >     0x4800ce80:	vaddfp  v16,v0,v0
> >     0x4800ce84:	.long 0x80e
> > End of assembler dump.
> >
> 
> While we are at it, could please you paste-bin a larger disassembly ( 
> $pc-256, $pc + 256) of frame #1, just below this one? I'd like to see 
> the call site.

This is the disassembly of frame #1
   0x0ff98434:	stw     r27,44(r1)
   0x0ff98438:	stw     r29,52(r1)
   0x0ff9843c:	bl      0xffaf2e0
   0x0ff98440:	stw     r3,16(r1)
   0x0ff98444:	stw     r3,24(r1)
   0x0ff98448:	bl      0xffaf278
   0x0ff9844c:	lwz     r9,16(r31)
   0x0ff98450:	mr      r5,r1
   0x0ff98454:	lwz     r28,8(r31)
   0x0ff98458:	stwu    r9,8(r5)
   0x0ff9845c:	lwz     r3,24(r1)
   0x0ff98460:	mr      r4,r28
   0x0ff98464:	lwz     r25,12(r31)
   0x0ff98468:	bl      0xffaf548
   0x0ff9846c:	lwz     r9,-32768(r30)
   0x0ff98470:	lwz     r3,16(r1)
   0x0ff98474:	addi    r6,r1,12
   0x0ff98478:	lwz     r0,0(r9)
   0x0ff9847c:	lwz     r4,8(r31)
   0x0ff98480:	ori     r0,r0,555
   0x0ff98484:	lwz     r5,16(r31)
   0x0ff98488:	sc      
   0x0ff9848c:	mfcr    r0
   0x0ff98490:	andis.  r9,r0,4096
   0x0ff98494:	beq-    0xff9849c
   0x0ff98498:	neg     r3,r3
   0x0ff9849c:	cmpwi   cr7,r3,0
   0x0ff984a0:	neg     r29,r3
   0x0ff984a4:	stw     r29,36(r31)
   0x0ff984a8:	lwz     r27,0(r31)
   0x0ff984ac:	lwz     r26,4(r31)
   0x0ff984b0:	beq-    cr7,0xff984ec
   0x0ff984b4:	addi    r3,r31,20
   0x0ff984b8:	bl      0xffaf3d8
   0x0ff984bc:	lwz     r0,68(r1)
   0x0ff984c0:	mr      r3,r29
   0x0ff984c4:	lwz     r25,36(r1)
   0x0ff984c8:	mtlr    r0
   0x0ff984cc:	lwz     r26,40(r1)
   0x0ff984d0:	lwz     r27,44(r1)
   0x0ff984d4:	lwz     r28,48(r1)
   0x0ff984d8:	lwz     r29,52(r1)
   0x0ff984dc:	lwz     r30,56(r1)
   0x0ff984e0:	lwz     r31,60(r1)
   0x0ff984e4:	addi    r1,r1,64
   0x0ff984e8:	blr
   0x0ff984ec:	bl      0xffaf488
   0x0ff984f0:	lwz     r3,12(r1)
   0x0ff984f4:	bl      0xffaf590
   0x0ff984f8:	addi    r3,r31,20
   0x0ff984fc:	bl      0xffaf3d8
   0x0ff98500:	lwz     r9,8(r1)
   0x0ff98504:	cmpw    cr7,r9,r25
   0x0ff98508:	beq-    cr7,0xff98560
   0x0ff9850c:	cmpwi   cr7,r28,0
   0x0ff98510:	beq-    cr7,0xff98528
   0x0ff98514:	lis     r0,512
   0x0ff98518:	li      r3,1
   0x0ff9851c:	ori     r0,r0,555
   0x0ff98520:	sc      
   0x0ff98524:	mfcr    r0
   0x0ff98528:	mr      r3,r26
   0x0ff9852c:	mtctr   r27
   0x0ff98530:	bctrl
=> 0x0ff98534:	lwz     r0,68(r1)
   0x0ff98538:	lwz     r25,36(r1)
   0x0ff9853c:	mtlr    r0
   0x0ff98540:	lwz     r26,40(r1)
   0x0ff98544:	lwz     r27,44(r1)
   0x0ff98548:	lwz     r28,48(r1)
   0x0ff9854c:	lwz     r29,52(r1)
   0x0ff98550:	lwz     r30,56(r1)
   0x0ff98554:	lwz     r31,60(r1)
   0x0ff98558:	addi    r1,r1,64
   0x0ff9855c:	blr
   0x0ff98560:	bl      0xffaf550
   0x0ff98564:	b       0xff9850c
   0x0ff98568:	b       0xffaf550
   0x0ff9856c:	.long 0x1eb0c
   0x0ff98570:	stwu    r1,-128(r1)
   0x0ff98574:	mflr    r0
   0x0ff98578:	bcl-    20,4*cr7+so,0xff9857c
   0x0ff9857c:	stw     r30,120(r1)
   0x0ff98580:	mflr    r30
   0x0ff98584:	stw     r29,116(r1)
   0x0ff98588:	mr.     r29,r4
   0x0ff9858c:	stw     r0,132(r1)
   0x0ff98590:	lwz     r0,-16(r30)
   0x0ff98594:	stw     r26,104(r1)
   0x0ff98598:	mr      r26,r3
   0x0ff9859c:	add     r30,r0,r30
   0x0ff985a0:	stw     r27,108(r1)
   0x0ff985a4:	stw     r28,112(r1)
   0x0ff985a8:	mr      r27,r5
   0x0ff985ac:	stw     r31,124(r1)
   0x0ff985b0:	mr      r28,r6
   0x0ff985b4:	lwz     r31,-32764(r30)
   0x0ff985b8:	beq-    0xff98778
   0x0ff985bc:	addi    r4,r1,92
   0x0ff985c0:	mr      r3,r29
   0x0ff985c4:	bl      0xffaf400
   0x0ff985c8:	bl      0xffaf2e0
   0x0ff985cc:	addi    r4,r1,16
   0x0ff985d0:	addi    r5,r1,96
   0x0ff985d4:	bl      0xffaf480
   0x0ff985d8:	lwz     r10,92(r1)
   0x0ff985dc:	lwz     r9,96(r1)
   0x0ff985e0:	cmpwi   cr7,r10,1
   0x0ff985e4:	stw     r9,20(r1)
   0x0ff985e8:	beq-    cr7,0xff987ac
   0x0ff985ec:	addi    r3,r1,48
   0x0ff985f0:	mr      r4,r29
   0x0ff985f4:	li      r5,36
   0x0ff985f8:	stw     r9,24(r1)
   0x0ff985fc:	bl      0xffaf2d8
   0x0ff98600:	lwz     r9,36(r31)
   0x0ff98604:	cmpwi   cr7,r9,0
   0x0ff98608:	beq-    cr7,0xff98618
   0x0ff9860c:	bl      0xffaf358
   0x0ff98610:	cmpwi   cr7,r3,0
   0x0ff98614:	bne-    cr7,0xff98748
   0x0ff98618:	addi    r3,r1,48
   0x0ff9861c:	li      r4,0
   0x0ff98620:	bl      0xffaf440
   0x0ff98624:	addi    r3,r1,48
   0x0ff98628:	addi    r4,r1,84
   0x0ff9862c:	bl      0xffaf4d8
   0x0ff98630:	lwz     r3,40(r31)

> 
> Also, could you paste-bin the disassembly of libxenomai.so?
You can find it here:
http://pastebin.com/YjUDZRMp

> 
> TIA,
> 
You are welcome!

TIA, too!


-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131202/91af35e9/attachment.sig>

Re: [Xenomai] test suite programs crash with Illegal instruction on MPC5200

[Bukuli Norbert]

On Mon, 2 Dec 2013 11:16:34 +0100
Bukuli Norbert <norbert.bukuli@mediso.hu> wrote:
> 
> 
> On Mon, 2 Dec 2013 10:58:42 +0100
> Philippe Gerum <rpm@xenomai.org> wrote:
> > On 12/02/2013 09:50 AM, Bukuli Norbert wrote:
> > >
> > >
> > > On Fri, 29 Nov 2013 23:53:20 +0100
> > > Wolfgang Denk <wd@denx.de> wrote:
> > >> Dear Philippe Gerum,
> > >>
> > >> In message <52985E94.4070101@xenomai.org> you wrote:
> > >>> On 11/29/2013 09:41 AM, Bukuli Norbert wrote:
> > >>>> (gdb) cont
> > >>>> Continuing.
> > >>>> warning: Could not load shared library symbols for
> > >>>> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> > >>>> sysroot"? warning: .dynamic section for
> > >>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1"
> > >>>> is not at the expected address (wrong library or version
> > >>>> mismatch?) warning: .dynamic section for
> > >>>> "/opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0"
> > >>>> is not at the expected address (wrong library or version
> > >>>> mismatch?)
> > >>>
> > >>> These warnings may trigger with recent broken gdbserver
> > >>> releases, let's ignore them.
> > >>
> > >> I don't think this is a good idea.  The actual problem is in the
> > >> previous warning:
> > >>
> > >> warning: Could not load shared library symbols for
> > >> linux-vdso32.so.1. Do you need "set solib-search-path" or "set
> > >> sysroot"?
> > >>
> > >> You must set solib-search-path.
> > >
> > > As Philippe Gerum asked it, I have used the Xenomai libraries
> > > provided by the ELDK 5.4 and kept my kernel. In the following test
> > > I set the solib-search path and the sysroot properly, however the
> > > powerpc-linux-gdb was unable to find linux-vdso32.so.1. I
> > > installed it from the kernel with vdso_install but it creates
> > > only /lib/modules/3.8.13/vdso/vdso32.so file.
> > >
> > > What is the proper way to make the gdb know the linux-vdso32.so.1
> > > file? Shall I create a simlink to the vdso32.so file?
> > >
> > > Anyway, after I created the simlink on the target system like
> > > this : root@generic-powerpc:/lib# ln
> > > -s /lib/modules/3.8.13/vdso/vdso32.so linux-vdso32
> > >
> > > and on the host system like this:
> > > # cd $(POWERPC-SYSROOT)/lib/modules/3.8.13/vdso
> > > # ln -s vdso32.so linux-vdso32.so.1
> > >
> > > gdb found all libraries. However, there is no debugging info in
> > > the shared libraries, but I think the disassembled code around the
> > > crash point will be sufficient.
> > >
> > > GDB output (irrelevant parts are removed):
> > > $ powerpc-linux-gdb usr/xenomai/bin/powerpc-linux-clocktest
> > > ...
> > > Reading symbols
> > > from /srv/tftpboot/172.31.2.11/usr/xenomai/bin/powerpc-linux-clocktest...(nodebugging
> > > symbols found)...done.
> > >
> > > (gdb) set solib-search-path
> > > "/srv/tftpboot/172.31.2.11/lib/:/srv/tftpboot/172.31.2.11/usr/lib/:/srv/tftpboot/172.31.2.11/usr/xenomai/lib/:/srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/
> > > (gdb) set sysroot /opt/eldk-5.4/powerpc/sysroots/powerpc-linux
> > >
> > > (gdb) target remote 172.31.2.11:2001
> > > Remote debugging using 172.31.2.11:2001
> > > Reading symbols
> > > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1...Reading
> > > symbols
> > > from /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/.debug/ld-2.17.so...done.
> > > done. Loaded symbols
> > > for /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > > 0x0ffd76e8 in ?? ()
> > >
> > > (gdb) cont
> > > Continuing.
> > > [New Thread 338]
> > >
> > > Program received signal SIGILL, Illegal instruction.
> > > [Switching to Thread 338]
> > > 0x4800ce74 in ?? ()
> > >
> > > (gdb) bt
> > > #0  0x4800ce74 in ?? ()
> > > #1  0x0ff98534 in ?? ()
> > > #2  0x0fe17a68 in ?? ()
> > > #3  0x480eba4c in ?? ()
> > >
> > > (gdb) info sharedlibrary
> > >  From        To          Syms Read   Shared Object Library
> > > 0x00001ff0  0x0001b014
> > > Yes         /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/ld.so.1
> > > 0x00100360  0x00100648
> > > No          /srv/tftpboot/172.31.2.11/lib/modules/3.8.13/vdso/linux-vdso32.so.1
> > > 0x0ff979b4  0x0ff9e948
> > > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libpthread_rt.so.1
> > > 0x0ff6fba0  0x0ff731d0
> > > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/usr/xenomai/lib/libxenomai.so.0
> > > 0x0fe14b84  0x0fe233fc
> > > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libpthread.so.0
> > > 0x480225c0  0x48135844
> > > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/libc.so.6
> > > 0x0fdf1a94  0x0fdf599c
> > > No          /opt/eldk-5.4/powerpc/sysroots/powerpc-linux/lib/librt.so.1
> > >
> > > (gdb) disass $pc-64,$pc+20
> > > Dump of assembler code from 0x4800ce34 to 0x4800ce88:
> > >     0x4800ce34:	.long 0x3894
> > >     0x4800ce38:	twi     31,r22,-18268
> > >     0x4800ce3c:	.long 0x80
> > >     0x4800ce40:	vaddfp  v16,v0,v0
> > >     0x4800ce44:	.long 0x19fb
> > >     0x4800ce48:	twi     31,r18,-26168
> > >     0x4800ce4c:	.long 0xa0
> > >     0x4800ce50:	vaddfp  v16,v0,v0
> > >     0x4800ce54:	.long 0x2742
> > >     0x4800ce58:	twi     31,r18,14172
> > >     0x4800ce5c:	.long 0x4c
> > >     0x4800ce60:	subfic  r16,r0,10
> > >     0x4800ce64:	.long 0x378a
> > >     0x4800ce68:	twi     31,r19,-31924
> > >     0x4800ce6c:	.long 0x58
> > >     0x4800ce70:	vaddfp  v16,v0,v0
> > > => 0x4800ce74:	.long 0x5a3e
> > >     0x4800ce78:	twi     31,r18,10348
> > >     0x4800ce7c:	.long 0x68
> > >     0x4800ce80:	vaddfp  v16,v0,v0
> > >     0x4800ce84:	.long 0x80e
> > > End of assembler dump.
> > >
> > 
> > While we are at it, could please you paste-bin a larger disassembly
> > ( $pc-256, $pc + 256) of frame #1, just below this one? I'd like to
> > see the call site.
> 
> This is the disassembly of frame #1
>    0x0ff98434:	stw     r27,44(r1)
>    0x0ff98438:	stw     r29,52(r1)
>    0x0ff9843c:	bl      0xffaf2e0
>    0x0ff98440:	stw     r3,16(r1)
>    0x0ff98444:	stw     r3,24(r1)
>    0x0ff98448:	bl      0xffaf278
>    0x0ff9844c:	lwz     r9,16(r31)
>    0x0ff98450:	mr      r5,r1
>    0x0ff98454:	lwz     r28,8(r31)
>    0x0ff98458:	stwu    r9,8(r5)
>    0x0ff9845c:	lwz     r3,24(r1)
>    0x0ff98460:	mr      r4,r28
>    0x0ff98464:	lwz     r25,12(r31)
>    0x0ff98468:	bl      0xffaf548
>    0x0ff9846c:	lwz     r9,-32768(r30)
>    0x0ff98470:	lwz     r3,16(r1)
>    0x0ff98474:	addi    r6,r1,12
>    0x0ff98478:	lwz     r0,0(r9)
>    0x0ff9847c:	lwz     r4,8(r31)
>    0x0ff98480:	ori     r0,r0,555
>    0x0ff98484:	lwz     r5,16(r31)
>    0x0ff98488:	sc      
>    0x0ff9848c:	mfcr    r0
>    0x0ff98490:	andis.  r9,r0,4096
>    0x0ff98494:	beq-    0xff9849c
>    0x0ff98498:	neg     r3,r3
>    0x0ff9849c:	cmpwi   cr7,r3,0
>    0x0ff984a0:	neg     r29,r3
>    0x0ff984a4:	stw     r29,36(r31)
>    0x0ff984a8:	lwz     r27,0(r31)
>    0x0ff984ac:	lwz     r26,4(r31)
>    0x0ff984b0:	beq-    cr7,0xff984ec
>    0x0ff984b4:	addi    r3,r31,20
>    0x0ff984b8:	bl      0xffaf3d8
>    0x0ff984bc:	lwz     r0,68(r1)
>    0x0ff984c0:	mr      r3,r29
>    0x0ff984c4:	lwz     r25,36(r1)
>    0x0ff984c8:	mtlr    r0
>    0x0ff984cc:	lwz     r26,40(r1)
>    0x0ff984d0:	lwz     r27,44(r1)
>    0x0ff984d4:	lwz     r28,48(r1)
>    0x0ff984d8:	lwz     r29,52(r1)
>    0x0ff984dc:	lwz     r30,56(r1)
>    0x0ff984e0:	lwz     r31,60(r1)
>    0x0ff984e4:	addi    r1,r1,64
>    0x0ff984e8:	blr
>    0x0ff984ec:	bl      0xffaf488
>    0x0ff984f0:	lwz     r3,12(r1)
>    0x0ff984f4:	bl      0xffaf590
>    0x0ff984f8:	addi    r3,r31,20
>    0x0ff984fc:	bl      0xffaf3d8
>    0x0ff98500:	lwz     r9,8(r1)
>    0x0ff98504:	cmpw    cr7,r9,r25
>    0x0ff98508:	beq-    cr7,0xff98560
>    0x0ff9850c:	cmpwi   cr7,r28,0
>    0x0ff98510:	beq-    cr7,0xff98528
>    0x0ff98514:	lis     r0,512
>    0x0ff98518:	li      r3,1
>    0x0ff9851c:	ori     r0,r0,555
>    0x0ff98520:	sc      
>    0x0ff98524:	mfcr    r0
>    0x0ff98528:	mr      r3,r26
>    0x0ff9852c:	mtctr   r27
>    0x0ff98530:	bctrl
> => 0x0ff98534:	lwz     r0,68(r1)
>    0x0ff98538:	lwz     r25,36(r1)
>    0x0ff9853c:	mtlr    r0
>    0x0ff98540:	lwz     r26,40(r1)
>    0x0ff98544:	lwz     r27,44(r1)
>    0x0ff98548:	lwz     r28,48(r1)
>    0x0ff9854c:	lwz     r29,52(r1)
>    0x0ff98550:	lwz     r30,56(r1)
>    0x0ff98554:	lwz     r31,60(r1)
>    0x0ff98558:	addi    r1,r1,64
>    0x0ff9855c:	blr
>    0x0ff98560:	bl      0xffaf550
>    0x0ff98564:	b       0xff9850c
>    0x0ff98568:	b       0xffaf550
>    0x0ff9856c:	.long 0x1eb0c
>    0x0ff98570:	stwu    r1,-128(r1)
>    0x0ff98574:	mflr    r0
>    0x0ff98578:	bcl-    20,4*cr7+so,0xff9857c
>    0x0ff9857c:	stw     r30,120(r1)
>    0x0ff98580:	mflr    r30
>    0x0ff98584:	stw     r29,116(r1)
>    0x0ff98588:	mr.     r29,r4
>    0x0ff9858c:	stw     r0,132(r1)
>    0x0ff98590:	lwz     r0,-16(r30)
>    0x0ff98594:	stw     r26,104(r1)
>    0x0ff98598:	mr      r26,r3
>    0x0ff9859c:	add     r30,r0,r30
>    0x0ff985a0:	stw     r27,108(r1)
>    0x0ff985a4:	stw     r28,112(r1)
>    0x0ff985a8:	mr      r27,r5
>    0x0ff985ac:	stw     r31,124(r1)
>    0x0ff985b0:	mr      r28,r6
>    0x0ff985b4:	lwz     r31,-32764(r30)
>    0x0ff985b8:	beq-    0xff98778
>    0x0ff985bc:	addi    r4,r1,92
>    0x0ff985c0:	mr      r3,r29
>    0x0ff985c4:	bl      0xffaf400
>    0x0ff985c8:	bl      0xffaf2e0
>    0x0ff985cc:	addi    r4,r1,16
>    0x0ff985d0:	addi    r5,r1,96
>    0x0ff985d4:	bl      0xffaf480
>    0x0ff985d8:	lwz     r10,92(r1)
>    0x0ff985dc:	lwz     r9,96(r1)
>    0x0ff985e0:	cmpwi   cr7,r10,1
>    0x0ff985e4:	stw     r9,20(r1)
>    0x0ff985e8:	beq-    cr7,0xff987ac
>    0x0ff985ec:	addi    r3,r1,48
>    0x0ff985f0:	mr      r4,r29
>    0x0ff985f4:	li      r5,36
>    0x0ff985f8:	stw     r9,24(r1)
>    0x0ff985fc:	bl      0xffaf2d8
>    0x0ff98600:	lwz     r9,36(r31)
>    0x0ff98604:	cmpwi   cr7,r9,0
>    0x0ff98608:	beq-    cr7,0xff98618
>    0x0ff9860c:	bl      0xffaf358
>    0x0ff98610:	cmpwi   cr7,r3,0
>    0x0ff98614:	bne-    cr7,0xff98748
>    0x0ff98618:	addi    r3,r1,48
>    0x0ff9861c:	li      r4,0
>    0x0ff98620:	bl      0xffaf440
>    0x0ff98624:	addi    r3,r1,48
>    0x0ff98628:	addi    r4,r1,84
>    0x0ff9862c:	bl      0xffaf4d8
>    0x0ff98630:	lwz     r3,40(r31)
> 
> > 
> > Also, could you paste-bin the disassembly of libxenomai.so?
> You can find it here:
> http://pastebin.com/YjUDZRMp
> 
> > 
> > TIA,
> > 
> You are welcome!
> 
> TIA, too!
> 
> 

With kind help of Mr. Philippe Gerum, Mr. Gilles Chanteperdrix and Mr.
Wolfgang Denk the issue is solved now. Thank you!

There was two related issues in my setup.

1. FUTEX support was disabled in my kernel configuration, thus all
FUTEX operations return with ENOSYS. When FUTEXes are enabled, the
clocktest pass, no illegal instruction was reported.

2. When FUTEX support is disabled, a fragility in the Xenomai POSIX
skin caused calling random code.

This second issue is fixed by Mr. Philippe Gerum in:
http://git.xenomai.org/xenomai-2.6.git/commit/?id=435f87958222c885b3dd94c9c7b2ef9c01efda7b

Thank you once aganin!

-- 
Norbert Bukuli
software engineer
embedded development

Mediso Ltd.
Tel.: +36 1 3993 030 Fax.: +36 1 3993 040
Mailing address: Hungary, H-1047 Budapest, Baross utca 91-95.
Billing address: Hungary, H-1022 Budapest, Alsotorokvesz 14.
norbert.bukuli@mediso.com
www.mediso.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20131209/ffd0ea0b/attachment.sig>