Re: [Xenomai] gdb / threads on beaglebone black

[Philippe Gerum <rpm@xenomai.org>]

On 05/28/2014 04:08 PM, Drew wrote:
> Yes, my guess was correct.
> The do - while loop in trampoline is exiting with error -38 (-ENOSYS?)
> If I change line 110 of skins/native/task.c:
>
> - while(err == -EINTR)
> + while(err == -EINTR || err == -ENOSYS)
>
> then I'm able to single-step in gdb. :-)
>
> Is my change a hack, or is it the correct thing to do?

No Xenomai call should ever return ENOSYS. Something is definitely wrong 
with the current setup.

> It looks like rt_task_trampoline is only expecting EINTR to occur. Is
> some other bug causing ENOSYS?

This means that the 'barrier' syscall did not get to Xenomai core, but 
was rejected as undefined.

Could any of the hints mentioned here apply in your case?
http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_any_xenomai_service_fails_with_code_38_enosys

  Or are there a few other valid errors
> that may be returned while waiting on the barrier? (the comment above
> the loop says "to process Linux signals" but the code only checks for
> one thing.) Should rt_task_trampoline somehow warn a user if the
> do-while encounters an error it doesn't expect? (or does it already,
> through another debug mechanism I'm not using?)

The loop only cares for non-restartable syscalls, which receive EINTR 
when interrupted by a signal handler.

>
> As an aside, another question is why rt_task_trampoline at all? Why fire
> up the new thread when it doesn't yet know what it will be executing?
> I'm guessing it is for speed, so that when rt_task_start actually does
> execute, it will execute immediately...
>

Correct, rt_task_create() does all the resource reservation, all the 
lengthy stuff. When successful, we know that we'll be able to start the 
task code upon rt_task_start(), provided the task descriptor is valid. 
rt_task_start() is only about unleashing a ready-to-run thread context.

-- 
Philippe.