Re: [Xenomai-help] Help on debugger gdb

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

Philippe Gerum wrote:
> On Mon, 2006-09-25 at 22:40 -0300, Rodrigo Rosenfeld Rosas wrote:
>> Hi, it's me again, after a long while :)
>>
>> I'll present my Master thesis this Friday and I would like to comment 
>> about the debugger. Since I'm in hurry with a lot other issues, I do not 
>> have to time to test what I'm going to ask.
>>
>> I've never used a debugger with Xenomai (or RTAI). I mean, not GDB. I 
>> used other techniques to debug, such as logging, etc. My doubt is:
>>
>> Suppose I have a user-space program with 3 independent Xenomai RT-tasks. 
>> If I put a breakpoint in one of them, will the other two keep running? I 
>> guess yes, but I'm not sure and that is why I'm asking.
>>
> 
> Actually, they would not. The kernel would stop all of them as a
> consequence of ptracing, and Xenomai would switch them back to secondary
> mode if needed, to let them handle the new situation properly.
> 
>> Another thing. I think that the scheduler will keep counting the time 
>> when the debugger stopped the task. So, the next call to 
>> rt_task_wait_period() will return -ETIMEDOUT immediately, with the 
>> overruns set accordly, if this was the case, right?
>>
> 
> No, the outstanding RT timers are globally frozen whenever a ptraced
> user-space task is stopped by the debugger, exactely to prevent the case
> you described, so that you can step into your application without
> causing such annoying side-effect. Since we are breakpointing/stepping
> into the code, real-time accuracy doesn't matter anyway, so we act as if
> the timeline was being frozen each time the debugger holds the
> application. 

Timers are frozen, but internal timekeeping continues, e.g. in
xnpod_wait_thread_period (which is used by rt_task_wait_period). So the
overrun counter is in fact incremented and an error is returned after
the interruption.

That raises the question for me if we shouldn't allow this freeze also
per-process in the future to confine the effect only to those programs
actually being debugged. I can easily imagine scenarios where the
developer might be more happy to keep other, fairly independent parts of
the system alive while stepping through one application.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]