[Xenomai] Debugger and secondary mode question

[Xenomai] Debugger and secondary mode question

[Mathew Benson]

I fixed all my toolchain problems and am finally back to debugging my
code.  Thanks for the help earlier.

It looks like gdbserver causes suspended threads to drop back down to
secondary mode, causing my rt_... calls to return ENOSYS.  Is there
anything I can do to prevent this?  I expect its unavoidable.

If I can't stop it, does anybody have any recommendations of how to make
code resilient to this?  I'm mostly just using mutexes and semaphores in my
main loop.  Can I mix real time and non-realtime functions with the same
handle?  In other words, what happens to a rt semaphore when the thread
transitions back to secondary mode?  Does the handle refer to a non rt
version now, or is it just inaccessible?

Re: [Xenomai] Debugger and secondary mode question

[Gilles Chanteperdrix]

On Wed, Mar 04, 2015 at 11:33:46AM -0600, Mathew Benson wrote:
> I fixed all my toolchain problems and am finally back to debugging my
> code.  Thanks for the help earlier.
> 
> It looks like gdbserver causes suspended threads to drop back down to
> secondary mode, 

Yes, that is expected/

> causing my rt_... calls to return ENOSYS.

What rt_ calls ? If you are talking about rtdm calls, returning
ENOSYS should cause xenomai to switch again to primary mode, so is
not an issue. Are you sure you do not mean EINTR ? Because yes, some
calls can return EINTR when interrupted by a signal (which is what
happens when running gdb), and if this is not handled by the call
itself (for instance pthread_mutex_lock does not expose EINTR, it is
handled in the user-space function itself), then your application
should handle it.

>  Is there
> anything I can do to prevent this?  I expect its unavoidable.

There is no way to run gdb without signals.

> 
> If I can't stop it, does anybody have any recommendations of how to make
> code resilient to this? 

Test EINTR,and try again when it happens.

> I'm mostly just using mutexes and semaphores in my
> main loop.  Can I mix real time and non-realtime functions with the same
> handle?  In other words, what happens to a rt semaphore when the thread
> transitions back to secondary mode?  Does the handle refer to a non rt
> version now, or is it just inaccessible?

Xenomai will switch back to primary mode as soon as needed. An rt
semaphore or mutex is rt-only, it has no secondary mode counterpart.

-- 
					    Gilles.

Re: [Xenomai] Debugger and secondary mode question

[Mathew Benson]

I'll test it again shortly.  

What happens when a thread depletes a semaphore or takes a mutex, then transitions to secondary mode?  Does the semaphore or mutex automatically get given back or does the thread keep it for when it transitions back to primary mode?

Sent from my iPhone

> On Mar 4, 2015, at 11:42 AM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On Wed, Mar 04, 2015 at 11:33:46AM -0600, Mathew Benson wrote:
>> I fixed all my toolchain problems and am finally back to debugging my
>> code.  Thanks for the help earlier.
>> 
>> It looks like gdbserver causes suspended threads to drop back down to
>> secondary mode,
> 
> Yes, that is expected/
> 
>> causing my rt_... calls to return ENOSYS.
> 
> What rt_ calls ? If you are talking about rtdm calls, returning
> ENOSYS should cause xenomai to switch again to primary mode, so is
> not an issue. Are you sure you do not mean EINTR ? Because yes, some
> calls can return EINTR when interrupted by a signal (which is what
> happens when running gdb), and if this is not handled by the call
> itself (for instance pthread_mutex_lock does not expose EINTR, it is
> handled in the user-space function itself), then your application
> should handle it.
> 
>> Is there
>> anything I can do to prevent this?  I expect its unavoidable.
> 
> There is no way to run gdb without signals.
> 
>> 
>> If I can't stop it, does anybody have any recommendations of how to make
>> code resilient to this?
> 
> Test EINTR,and try again when it happens.
> 
>> I'm mostly just using mutexes and semaphores in my
>> main loop.  Can I mix real time and non-realtime functions with the same
>> handle?  In other words, what happens to a rt semaphore when the thread
>> transitions back to secondary mode?  Does the handle refer to a non rt
>> version now, or is it just inaccessible?
> 
> Xenomai will switch back to primary mode as soon as needed. An rt
> semaphore or mutex is rt-only, it has no secondary mode counterpart.
> 
> -- 
>                        Gilles.

Re: [Xenomai] Debugger and secondary mode question

[Gilles Chanteperdrix]

On Wed, Mar 04, 2015 at 03:45:09PM -0600, Mathew Benson wrote:
> I'll test it again shortly.  
> 
> What happens when a thread depletes a semaphore or takes a mutex, then transitions to secondary mode?  Does the semaphore or mutex automatically get given back or does the thread keep it for when it transitions back to primary mode?

It keeps it, but this is very bad, and you should normally get a
warning in your kernel console. You can get a SIGDEBUG too, if you
enable the notification for the thread.

Of course, when debugging, timing issues are not so important, so
this is not an issue.

-- 
					    Gilles.

Re: [Xenomai] Debugger and secondary mode question

[Gilles Chanteperdrix]

On Wed, Mar 04, 2015 at 03:45:09PM -0600, Mathew Benson wrote:
> I'll test it again shortly.  
> 
> What happens when a thread depletes a semaphore or takes a mutex,
> then transitions to secondary mode? Does the semaphore or mutex
> automatically get given back or does the thread keep it for when
> it transitions back to primary mode?

A semaphore has no notion of ownership, so when the counter is 0, it
is impossible to say who should increment it. When not using a
semaphore has a mutex, the one who increments the semaphore may not
be the same as the one who decrements it. And there is little reason
to use semaphores as mutex, because mutex are more convenient for
that.

-- 
					    Gilles.