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

[Philippe Gerum <rpm@xenomai.org>]

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.