From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4A044EAE.8070408@domain.hid> Date: Fri, 08 May 2009 17:24:30 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <5D63919D95F87E4D9D34FF7748CE2C2A019C3523@domain.hid> In-Reply-To: <5D63919D95F87E4D9D34FF7748CE2C2A019C3523@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Xenomai-help] sem_wait increments fault counter List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: roderik.wildenburg@domain.hid Cc: xenomai@xenomai.org roderik.wildenburg@domain.hid wrote: >>> I try to give some more information: In fact it is a library we are >>> talking about (let=B4s call it shmlib). This library creates a shared= >>> memory and a (named) semaphore which should synchronise the=20 >> 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=20 >> options to gcc, >> which you get when calling xeno-config --posix-ldflags. Is it what you= >> are doing. >=20 > 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=B4t 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=20 >> 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=20 >> 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=20 >> some Power PC >> specific behaviour. >=20 > 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=B4t 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. --=20 Gilles.