Re: [Xenomai] gdb / threads on beaglebone black

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 05/28/2014 09:19 PM, Drew wrote:
> On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>>
>> Is there no message printed on the kernel console which would explain
>> why this syscall gets rejected?
>>
> 
> A good idea! Unfortunately, after hooking up my debug serial cable I don't
> see any message when this happens. Running tail -f /var/log/messages
> doesn't show anything suspicious either. (well, it did find some things I
> didn't clean up in my main application... ;-)
> 
> Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does
> that contain the kernel side of the do while loop? I notice that
> xnshadow_sys_trace (which seems debugger related to me..) defaults its
> error to -ENOSYS...
> 
The problem is syscall restarting by calling the syscall
sys_restart_syscall. When it appeared in entry.S, I made the assumption
that it would only be used for Linux syscall, that Xenomai syscall would
never have anything else than current_thread_info()->restart_block.fn
equal to "do_not_restart_syscall". This seems to be right most of the
time, except when running under gdb, where the kernel may want to
restart xenomai syscalls.

This implies reworking entry.S somehow. I do not see how yet, but I am
on it.

-- 
                                                                Gilles.