[email protected] wrote:
>>> I try to give some more information: In fact it is a library we are
>>> talking about (let´s call it shmlib). This library creates a shared
>>> memory and a (named) semaphore which should synchronise the
>> access to
>>> the shared memory. This library (shmlib) is linked with Xenomai
>>> posix-library, so all posix-calls within shmlib should be handled by
>>> Xenomai.
>> Well, not quite. Linking is not enough. To actually use Xenomai posix
>> library calls, you have to pass the bunch of -Wl,--wrap
>> options to gcc,
>> which you get when calling xeno-config --posix-ldflags. Is it what you
>> are doing.
>
> Not exactly, I wrap all posix calls in my library (shmlib) by hand:
> shm_open -> __wrap_shm_open
> So, when linking shmlib with an application the wrap-options for gcc
> don´t need to be provided (I hope. And the linker does not complain).
If shmlib is a shared lib, then wrapping when compiling/linking the lib
is all that is needed. Flags do not need to be passed to the application
using the lib. If it is a static lib, of course, things are different.
In any case, I still do not know if the calls to sem_open/sem_wait are
wrapped too ?
>>> Is trap 0 explicitly generated by Xenomay in some error
>> case or is it
>>> "just" a CPU error when executing an illegal instruction (but where
>>> should this illegal instruction/code come from ?) ?
>>>
>>> By the way: this error also happens with Xenoami 2.4.6.
>> No, Xenomai has no particular reason to voluntarily generate
>> a trap. And
>> this trap probably causes the calling thread to switch to secondary
>> mode, so this is bad news if it is a thread with actual real-time
>> activities. As Philippe told you, this trap may be due to
>> some Power PC
>> specific behaviour.
>
> No, it is not a real_time thread which causes the trap. It is just
> a Linux application which has been linked with my library and therefore
> becomes a Xenomai thread (but probably in secondary mode ?).
As indicated by Philippe, if the fault counter is incremented, the
Xenomai thread runs in primary mode at the time when the fault happens.
> Neverthelss, the problem(?) we are talking about is caused by
> sem_wait not by shared memory (as far as I can see).
> Is the problem worth to be further investigated (at the moment I
> don´t have any obvious drawbacks from trap 0). If so, do you have an idea what
I could do else to find out the reason for the trap 0 ?
Yes, of course, but if you use Xenomai's sem_wait, you could probably
switch to Linux' sem_wait. If you want to know why the fault happens,
then put a show_stack(NULL, NULL) at the point where the counter is
incremented.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
