> Kolja Waschk wrote:
>>>> file cond-torture-posix
>>> Ok. On my side: I call set solib-absolute-prefix to where the debug
>>> binaries for the target filesystem are. And I call
>>> handle SIG34 nostop noprint pass.
>>>
>>> Coud you try and do the same?
>> Is SIG34 the same on blackfin? I do not remember ever having seen SIG34, only
>> SIG32 ("Real-time event 32")
>>
>> Independent of that, the result is always the same SEGV. I cannot use the absolute-prefix currently, as the directory layout is different on the target. So my script is now
>>
>> set solib-absolute-prefix notexistent
>> set solib-search-path /opt/uClinux/blackfin-linux-dist/staging/usr/lib:/opt/uClinux/bfin-linux-uclibc/bfin-linux-uclibc/runtime/lib
>> file cond-torture-posix
>> handle SIG34 nostop noprint pass
>> target remote 10.0.10.9:2222
>>
>> And regardless whether I add an "break main", the SEGV will occur immediately after telling gdb to "cont".
>>
>> Does my "try.c" always succeed (all errbits=0x0010) in your environment?
>
> Ok, I get the failure if I set up a breakpoint right after the call to
> pthread_cond_wait, as noted by Pierre. After some debugging, it appears
> that the syscall is restarted whereas it should return to user-spacce
> and let the user-space skin do its job. So, it seems that somehow, the
> behaviour is different for gdb signals than for usual signals.
>
> Working on it now, will tell you when we have a status.

The following patch seems to fix the issue, but I am not yet sure
whether it is really correct:

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index d27494c..717a8a0 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -770,7 +770,7 @@ static inline void request_syscall_restart(xnthread_t *thread,
if (__xn_interrupted_p(regs)) {
__xn_error_return(regs,
  (sysflags & __xn_exec_norestart) ?
-   -ERESTARTNOHAND : -ERESTARTSYS);
+   -EINTR : -ERESTARTSYS);
notify = !xnthread_test_state(thread, XNDEBUG);
}



--
                                                               Gilles.

Sorry but I'm a novice.

As I understand, your patch is a kernel patch and I need to rebuild the kernel package.
Where can I find the cond-torture-posix application to reproduce the problem with your test case ?
My PC is a very standard one (Xeon dual core and my distro an Ubuntu 10.10 so I think it's very easy to reproduce the test case.
Do you know if there is a bug tracker where tickets are logged to be informed when this point will be solved ?

Thank you for you help.

Pierre Quélin