This is the mail archive of the
mailing list for the GDB project.
Re: remote protocol extension for step out of range
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: remote protocol extension for step out of range
- From: jtc at redback dot com (J.T. Conklin)
- Date: 05 Feb 2001 12:04:08 -0800
- Cc: gdb at sourceware dot cygnus dot com
- References: <firstname.lastname@example.org> <email@example.com> <3A79BFB3.E2C17712@cygnus.com> <firstname.lastname@example.org> <3A7EED79.678DFCE4@cygnus.com>
- Reply-To: jtc at redback dot com
>>>>> "Andrew" == Andrew Cagney <email@example.com> writes:
>> >From the protocol perspective, I don't think it would work any
>> differently than stepping or continuing a given task. Currently
>> remote_resume() will send a "set thread" packet if the target's
>> current thread is different than GDB's. I didn't change this for
>> the new packets, so the debug agent will be able to determine what
>> thread the step range is for.
Andrew> If I understand the existing code correctly, you can only do
Andrew> this step-range thing for a single thread. If something else
Andrew> happens then that request is dropped on the floor.
The intent is for step out of range to work for multiple threads. I
suspect that there may be problems with stepping threads in GDB, but
they are not limited to this protocol extension.
Andrew> For instance, GDB does a step out of range for thread T1.
Andrew> While this is happening, thread T2 hits a breakpoint so the
Andrew> target stops. The user then step out of range T2. I suspect
Andrew> that GDB either:
Andrew> o forgets that it is step out of ranging T1
Andrew> o reverts to single stepping for T1
Andrew> the protocol will certainly only allow GDB to step-out-of-
Andrew> range one thread.
I think we can poke a similar hole in GDB as it stands today. For
instance, GDB does a step out of range for thread T1. Without the
step out of range command, it does it internally by issuing multiple
steps and comparing the PC after each step. While this is happening,
thread T2 hits a breakpoint and returns status that T2 has stopped.
The user then does a step out of range for T2.
I think the problem is the same, and will only be solved when GDB
is able to track multiple processes/threads/contexts.