[Xenomai-help] Help on debugger gdb

[Xenomai-help] Help on debugger gdb

[Rodrigo Rosenfeld Rosas]

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.

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?

Thank you all again for all the support I had while researching for my 
master thesis. :) After concluding it, it will be time for starting 
looking for a job. If anyone of you knows about some company that could 
employ a brazilian to work with Linux based real-time systems, 
preferently Xenomai, please, let me know.

Best regards,

Rodrigo.


		
_______________________________________________________ 
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! 
http://br.mobile.yahoo.com/mailalertas/ 
 

Re: [Xenomai-help] Help on debugger gdb

[Philippe Gerum]

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. 

> Thank you all again for all the support I had while researching for my 
> master thesis. :) After concluding it, it will be time for starting 
> looking for a job. If anyone of you knows about some company that could 
> employ a brazilian to work with Linux based real-time systems, 
> preferently Xenomai, please, let me know.
> 
> Best regards,
> 
> Rodrigo.
> 
> 
> 		
> _______________________________________________________ 
> Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! 
> http://br.mobile.yahoo.com/mailalertas/ 
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Help on debugger gdb

[Jan Kiszka]

[-- 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 --]

Re: [Xenomai-help] Help on debugger gdb

[Philippe Gerum]

On Tue, 2006-09-26 at 11:40 +0200, Jan Kiszka wrote:
> 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.

Yes, I was talking about the old behaviour we had of returning timeout
conditions repeatedly for each missed release points before
xnpod_wait_thread_period has been reworked to actually compute the
missed periods.

> 
> 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.
> 

Yes, but we will need the reworked timer infrastructure to do that
properly.

> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] Help on debugger gdb

[Rodrigo Rosenfeld Rosas]

Thank you Philippe and Jan,

I would like further to suggest some improvements to this debugging process.

As Jan has said, I can also think of a scenario where a user will wish keep
other
programs running unaltered by the debugged program. Furthermore, I can even 
imagine other tasks inside the debugged program to keep running normally.

Suppose the framework I'm developing. If a user wants to test an own task,
but
would like not to stop the robot basic tasks, it would not be possible from
what I've
understood. If the user compiles the framework as a static library, it will
be the same
process. I did not developed a driver for my robot, which would provide
some ioctl
API for communicating to it. I did not also developed a separated server
program
for that. All robot control is developed inside the user-space library,
playing with
the parallel port pins and iopl()... I know it is not portable, but it is
simple and is
sufficient for my tests.

But if all tasks are frozen, the robot will have unexpected behaviour if a
user is
debugging communication with other robots, using rt-net, for instance.

Thank you for all the information regarding debuggers.

Regards,

Rodrigo.


Philippe Gerum <rpm@xenomai.org> wrote:
>
>On Tue, 2006-09-26 at 11:40 +0200, Jan Kiszka wrote:
>> 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.
>
>Yes, I was talking about the old behaviour we had of returning timeout
>conditions repeatedly for each missed release points before
>xnpod_wait_thread_period has been reworked to actually compute the
>missed periods.
>
>> 
>> 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.
>> 
>
>Yes, but we will need the reworked timer infrastructure to do that
>properly.
>
>> Jan
>> 
>-- 
>Philippe.
>
>

		
_______________________________________________________ 
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! 
http://br.mobile.yahoo.com/mailalertas/