remote protocol extension for step out of range

remote protocol extension for step out of range

[J.T. Conklin]

As I mentioned a few weeks ago, I'd like to add the ability for
step-out-of range to the remote protocol.  While there are still some
unresolved issues about how the range limits should be obtained by the
to_resume vector function, in worst case I could do what the vxWorks
RDB back end does and access the globals step_range_start and
step_range_end.

The current remote protocol "step" command is 

        SNN[,AA..AA]
or:
        s[AA..AA]

The first form encodes a signal number to be delivered and an optional
address that becomes the new PC.  The second form only encodes the new
PC.  Note that while the protocol supports setting the PC, GDB does
not use it.

Unfortunately it would be difficult to extend either command to
contain a range because neither the sample stubs distribued with GDB
or gdbserver completely parse the step commands and return a failure
indication.  Without this, it's pretty much impossible to probe the
stub to see if it supports this extension.

Since that's not practical, I don't think there is any other solution
other than to create a new set of commands.  They could be a superset
of the existing step commands or be used only for step out of range.
I'm not sure which is better.

Step-out-of-range only commands might look like:

        ENN,SS..SS,EE..EE[,AA...AA]
or:
        eSS...SS,EE..EE[,AA..AA]

Which would step from the PC and repeat until it moved out of the
range described by SS..SS and EE..EE.  I've also preserved the ability
to set the initial PC like the existing step commands for parallelism;
I don't expect that GDB will use it either.

To be able to successfully probe for this command, there should be a
return value.  An OK or EXX response should do.  Older stubs would
return "" as they do for all unrecognized commands.

Btw, I chose 'E/e' because that was the only letter in the word 'step'
that isn't already used.

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[Andrew Cagney]

"J.T. Conklin" wrote:

> Step-out-of-range only commands might look like:
> 
>         ENN,SS..SS,EE..EE[,AA...AA]
> or:
>         eSS...SS,EE..EE[,AA..AA]
> 
> Which would step from the PC and repeat until it moved out of the
> range described by SS..SS and EE..EE.  I've also preserved the ability
> to set the initial PC like the existing step commands for parallelism;
> I don't expect that GDB will use it either.
> 
> To be able to successfully probe for this command, there should be a
> return value.  An OK or EXX response should do.  Older stubs would
> return "" as they do for all unrecognized commands.
> 
> Btw, I chose 'E/e' because that was the only letter in the word 'step'
> that isn't already used.

Would an addition to the breakpoint packet work?  Rather than break when
in this range, break when outside of this range.

	Andrew

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Step-out-of-range only commands might look like:
>> 
>> ENN,SS..SS,EE..EE[,AA...AA]
>> or:
>> eSS...SS,EE..EE[,AA..AA]
>> 
>> Which would step from the PC and repeat until it moved out of the
>> range described by SS..SS and EE..EE.  I've also preserved the ability
>> to set the initial PC like the existing step commands for parallelism;
>> I don't expect that GDB will use it either.
>> 
>> To be able to successfully probe for this command, there should be a
>> return value.  An OK or EXX response should do.  Older stubs would
>> return "" as they do for all unrecognized commands.
>> 
>> Btw, I chose 'E/e' because that was the only letter in the word 'step'
>> that isn't already used.

Andrew> Would an addition to the breakpoint packet work?  Rather than
Andrew> break when in this range, break when outside of this range.

If we tried, we could probably come up with something that would work.

However, the point at which we know the bounds of the step region is
"right before" we issue the step command.  If we were to use a varient
of the breakpoint packet, we'd have to issue two commands.  I'd rather
avoid this unnecessary command/response latency.  After all, that is
the primary reason for this extension.

The only other option that appeals to me is to completely depricate
the step command and have a new command that supports either step or
step out of range depending on its arguments.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> Step-out-of-range only commands might look like:
jtc>
jtc>         ENN,SS..SS,EE..EE[,AA...AA]
jtc> or:
jtc>         eSS...SS,EE..EE[,AA..AA]
jtc>
jtc> Which would step from the PC and repeat until it moved out of the
jtc> range described by SS..SS and EE..EE.  I've also preserved the ability
jtc> to set the initial PC like the existing step commands for parallelism;
jtc> I don't expect that GDB will use it either.
jtc>
jtc> To be able to successfully probe for this command, there should be a
jtc> return value.  An OK or EXX response should do.  Older stubs would
jtc> return "" as they do for all unrecognized commands.

It turned out to be trival to implement the above.  I've enclosed a
patch for review.  The guts are ~50 lines, including comments.  The
rest is required for the CLI so the user can enable and disable the
new packets.

I welcome any comments,

        --jtc


Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.35
diff -c -r1.35 remote.c
*** remote.c	2001/01/23 22:48:56	1.35
--- remote.c	2001/01/31 04:20:08
***************
*** 662,667 ****
--- 662,701 ----
      }
  }
  
+ /* Should we try the 'e' (step over range) request? */
+ static struct packet_config remote_protocol_e;
+ 
+ static void
+ set_remote_protocol_e_packet_cmd (char *args, int from_tty,
+ 				  struct cmd_list_element *c)
+ {
+   update_packet_config (&remote_protocol_e);
+ }
+ 
+ static void
+ show_remote_protocol_e_packet_cmd (char *args, int from_tty)
+ {
+   show_packet_config_cmd (&remote_protocol_e);
+ }
+   
+ 
+ /* Should we try the 'E' (step over range / w signal #) request? */
+ static struct packet_config remote_protocol_E;
+ 
+ static void
+ set_remote_protocol_E_packet_cmd (char *args, int from_tty,
+ 				  struct cmd_list_element *c)
+ {
+   update_packet_config (&remote_protocol_E);
+ }
+ 
+ static void
+ show_remote_protocol_E_packet_cmd (char *args, int from_tty)
+ {
+   show_packet_config_cmd (&remote_protocol_E);
+ }
+   
+ 
  /* Should we try the 'P' (set register) request?  */
  
  static struct packet_config remote_protocol_P;
***************
*** 2030,2035 ****
--- 2064,2071 ----
  init_all_packet_configs (void)
  {
    int i;
+   update_packet_config (&remote_protocol_e);
+   update_packet_config (&remote_protocol_E);
    update_packet_config (&remote_protocol_P);
    for (i = 0; i < NR_Z_PACKET_TYPES; i++)
      update_packet_config (&remote_protocol_Z[i]);
***************
*** 2293,2298 ****
--- 2329,2335 ----
  remote_resume (int pid, int step, enum target_signal siggnal)
  {
    char *buf = alloca (PBUFSIZ);
+   char *p;
  
    if (pid == -1)
      set_thread (0, 0);		/* run any thread */
***************
*** 2307,2317 ****
    if (target_resume_hook)
      (*target_resume_hook) ();
  
    if (siggnal != TARGET_SIGNAL_0)
      {
        buf[0] = step ? 'S' : 'C';
        buf[1] = tohex (((int) siggnal >> 4) & 0xf);
!       buf[2] = tohex ((int) siggnal & 0xf);
        buf[3] = '\0';
      }
    else
--- 2344,2409 ----
    if (target_resume_hook)
      (*target_resume_hook) ();
  
+ 
+   /* The s/S/c/C packets do not return status.  So if the target does
+      not support the S or C packets, the debug agent returns an empty
+      string which is detected in remote_wait().  This protocol defect
+      is fixed in the e/E packets. */
+ 
+   if (step && step_range_end)
+     {
+       /* If the target does not support the 'E' packet, we try the 'S'
+ 	 packet.  Ideally we would fall back to the 'e' packet if that
+ 	 too is not supported.  But that would require another copy of
+ 	 the code to issue the 'e' packet (and fall back to 's' if not
+ 	 supported) in remote_wait().  */
+       
+       if (siggnal != TARGET_SIGNAL_0)
+ 	{
+ 	  if (remote_protocol_E.support != PACKET_DISABLE)
+ 	    {
+ 	      p = buf;
+ 	      *p++ = 'E';
+ 	      *p++ = tohex (((int) siggnal >> 4) & 0xf);
+ 	      *p++ = tohex (((int) siggnal) & 0xf);
+ 	      *p++ = ',';
+ 	      p += hexnumstr (p, (ULONGEST) step_range_start);
+ 	      *p++ = ',';
+ 	      p += hexnumstr (p, (ULONGEST) step_range_end);
+ 	      *p++ = 0;
+ 
+ 	      putpkt (buf);
+ 	      getpkt (buf, PBUFSIZ, 0);
+ 
+ 	      if (packet_ok(buf, &remote_protocol_E) == PACKET_OK)
+ 		return;
+ 	    }
+ 	}
+       else
+ 	{
+ 	  if (remote_protocol_e.support != PACKET_DISABLE)
+ 	    {
+ 	      p = buf;
+ 	      *p++ = 'e';
+ 	      p += hexnumstr (p, (ULONGEST) step_range_start);
+ 	      *p++ = ',';
+ 	      p += hexnumstr (p, (ULONGEST) step_range_end);
+ 	      *p++ = 0;
+ 
+ 	      putpkt (buf);
+ 	      getpkt (buf, PBUFSIZ, 0);
+ 
+ 	      if (packet_ok(buf, &remote_protocol_e) == PACKET_OK)
+ 		return;
+ 	    }
+ 	}
+     }
+ 
    if (siggnal != TARGET_SIGNAL_0)
      {
        buf[0] = step ? 'S' : 'C';
        buf[1] = tohex (((int) siggnal >> 4) & 0xf);
!       buf[2] = tohex (((int) siggnal) & 0xf);
        buf[3] = '\0';
      }
    else
***************
*** 5497,5503 ****
--- 5589,5598 ----
  static void
  show_remote_cmd (char *args, int from_tty)
  {
+   
    show_remote_protocol_Z_packet_cmd (args, from_tty);
+   show_remote_protocol_e_packet_cmd (args, from_tty);
+   show_remote_protocol_E_packet_cmd (args, from_tty);
    show_remote_protocol_P_packet_cmd (args, from_tty);
    show_remote_protocol_binary_download_cmd (args, from_tty);
  }
***************
*** 5641,5646 ****
--- 5736,5755 ----
  
    add_info ("remote-process", remote_info_process,
  	    "Query the remote system for process info.");
+ 
+   add_packet_config_cmd (&remote_protocol_e,
+ 			 "e", "step-over-range",
+ 			 set_remote_protocol_e_packet_cmd,
+ 			 show_remote_protocol_e_packet_cmd,
+ 			 &remote_set_cmdlist, &remote_show_cmdlist,
+ 			 0);
+ 
+   add_packet_config_cmd (&remote_protocol_E,
+ 			 "E", "step-over-range-w-signal",
+ 			 set_remote_protocol_E_packet_cmd,
+ 			 show_remote_protocol_E_packet_cmd,
+ 			 &remote_set_cmdlist, &remote_show_cmdlist,
+ 			 0);
  
    add_packet_config_cmd (&remote_protocol_P,
  			 "P", "set-register",


-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> It turned out to be trival to implement the above.  I've enclosed a
jtc> patch for review.  The guts are ~50 lines, including comments.  The
jtc> rest is required for the CLI so the user can enable and disable the
jtc> new packets.

I got a chance to implement support for this in the debug stub used 
by one of our x86 based targets.  The result was spectacular.

Before this change, on a bit of random x86 code, each "step" caused
GDB to send an average of 3 to 4 "s" commands to the target.  After
the change, those "s" commands were replaced with a single "e".  This
greatly improves command latency.  This should be welcomed by anyone
who debugs over a slow debug channel, or cases where the target is 
half the world away.

Unfortunately, GDB still insists on inserting and removing breakpoints
around each step, so things aren't quite as efficent as they could be.
I think in time even that can be fixed.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[Andrew Cagney]

"J.T. Conklin" wrote:

> It turned out to be trival to implement the above.  I've enclosed a
> patch for review.  The guts are ~50 lines, including comments.  The
> rest is required for the CLI so the user can enable and disable the
> new packets.
> 
> I welcome any comments,

The new packet expects an immediate response.  The remote protocol could
have gone in two different directions here - drop the ack, always
require the ack - and you've chosen the later and that definitly doesn't
worry me :-)

What I'm trying to understand is how this packet will interact with
other things such as that out-of-band output (``O'') packet that comes
from the target.  Ditto for an input packet if that is ever created.

	Andrew

Re: remote protocol extension for step out of range

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
> jtc> Step-out-of-range only commands might look like:
> jtc>
> jtc>         ENN,SS..SS,EE..EE[,AA...AA]
> jtc> or:
> jtc>         eSS...SS,EE..EE[,AA..AA]
> jtc>
> jtc> Which would step from the PC and repeat until it moved out of the
> jtc> range described by SS..SS and EE..EE.  I've also preserved the ability
> jtc> to set the initial PC like the existing step commands for parallelism;
> jtc> I don't expect that GDB will use it either.
> jtc>
> jtc> To be able to successfully probe for this command, there should be a
> jtc> return value.  An OK or EXX response should do.  Older stubs would
> jtc> return "" as they do for all unrecognized commands.
> 
> It turned out to be trival to implement the above.  I've enclosed a
> patch for review.  The guts are ~50 lines, including comments.  The
> rest is required for the CLI so the user can enable and disable the
> new packets.
> 
> I welcome any comments,

I'm wondering about is how this works in a threaded environment.  This
continuation is very thread unfriendly (so is the underlying code so I'm
fighting an up hill battle here :-).  That was the reason for thinking
of an explicit breakpoint packet - so it could eventually be bound to a
specific thread.  Given that this packet is mostly reflecting the way
the GDB works, I suspect doing this different is beyond the scope of
your proposed change.

How will this packet work with something like the sparc where, to do a
correct continue you need to set both PC and NPC.  Consequently a sparc
does a resume by setting PC/NPC with register-write packets and then
does the continue.

With regard to the syntax, can it be specified in a way that is
extensable?  The ``T'' reply packet can bundle up all sorts of
information.  If we're going to have a new continue packet can the
syntax be such that it allows similar extensions?

Dig dig dig.  I've a local stub that uses the T packet to send back
_all_ the registers (none of this ``Gg'' stuff :-).  It was also tweeked
to allow the syntax <RENUM>!<NETWORK-ORDERD-VALUE> instead of
``<REGNUM>=<TARGET-ORDERD-VALUE>''  Should the [eE] packet syntax mirror
that of the ``T'' reply?  Perhaphs not the register values but at least
the ability to be extensable?

	Andrew

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> The new packet expects an immediate response.  The remote
Andrew> protocol could have gone in two different directions here -
Andrew> drop the ack, always require the ack - and you've chosen the
Andrew> later and that definitly doesn't worry me :-)
Andrew>
Andrew> What I'm trying to understand is how this packet will interact
Andrew> with other things such as that out-of-band output (``O'')
Andrew> packet that comes from the target.  Ditto for an input packet
Andrew> if that is ever created.

Note that the response from new packet(s) indicate whether the packet
was received and parsed correctly.  It does not contain the result of
the step.

If GDB receives an OK response, it knows the debug agent has started
the target executing.  GDB will then wait for status from the target.
This could be an indication that the steps have continued and the PC
is now out of bounds, it could be a breakpoint, it could be a ``O''
packet, etc.

While I don't do this myself, one way to think about it is that these
new command packets have two responses (possibly more, when the ``O''
packets are taken into consideration).  I tend to think of the 'S', 
'T', 'W', 'X', 'O' responses as asyncronous notifications of target 
state, and that the existing 'c', 'C', 's', and 'S' commands screwed
up by not requiring a command response.

For an Input packet, the debug agent would have to support some sort
of asyncronous packet processing (otherwise we couldn't send input
when the target is running).  Handling the same while stepping in a
range would be no different IMO.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I'm wondering about is how this works in a threaded
Andrew> environment.  This continuation is very thread unfriendly (so
Andrew> is the underlying code so I'm fighting an up hill battle here
Andrew> :-).  That was the reason for thinking of an explicit
Andrew> breakpoint packet - so it could eventually be bound to a
Andrew> specific thread.  Given that this packet is mostly reflecting
Andrew> the way the GDB works, I suspect doing this different is
Andrew> beyond the scope of your proposed change.

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.

[ As your probably can recall from previous discussions, I would have
preferred to have an (optional) thread id in the new commands so that
the latency of an additional command to set the thread id could be 
avoided.  But that is inconsistant with the protocol architecture. ]

Both before and after this change, the protocol seems to be more
flexible than either GDB or the provided debug agents offer.  It
appears that GDB assumes that all threads are stopped when attached,
etc.  And none of the sample stubs have thread support at all.  IMO,
getting the protocol right is the most important, because both GDB and
the agents can grow into the capabilities of the protocol.

Andrew> How will this packet work with something like the sparc where,
Andrew> to do a correct continue you need to set both PC and NPC.
Andrew> Consequently a sparc does a resume by setting PC/NPC with
Andrew> register-write packets and then does the continue.

In a target that supported with threads, GDB would be setting the
thread specific PC and NPC, and the step, continue, and step over
range commands would act on the that thread.  One has to assume that
the step boundries for step over range would be stored in thread 
local memory.  When that thread is scheduled, the debug agent would 
catch the exception after one instruction had executed.   For step
over range, it would compare the PC with the step boundries.  If it
was within that range, it would reschedule the thread so it would do
another step.  Once it's out of range, it would send a notification
packet indicating that that thread has stopped.

Andrew> With regard to the syntax, can it be specified in a way that
Andrew> is extensable?  The ``T'' reply packet can bundle up all sorts
Andrew> of information.  If we're going to have a new continue packet
Andrew> can the syntax be such that it allows similar extensions?

I think we can make it extensible.  The fact that the proposed packets
return status makes it lot easier than otherwise.  If we define status
for errors more stringently than has been done in the past, GDB should 
be able to probe for extensions reasonably well.

However, other than thread ID, I'm at a bit of a loss about what more
we would want to add.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[Andrew Cagney]

"J.T. Conklin" wrote:

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

If I understand the existing code correctly, you can only do this
step-range thing for a single thread.  If something else happens then
that request is dropped on the floor.

For instance, GDB does a step out of range for thread T1.  While this is
happening, thread T2 hits a breakpoint so the target stops.  The user
then step out of range T2.  I suspect that GDB either:

	o	forgets that it is step out of ranging T1

	o	reverts to single stepping for T1

the protocol will certainly only allow GDB to step-out-of-range one
thread.

	Andrew

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.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>
Andrew> 	o	forgets that it is step out of ranging T1
Andrew>
Andrew> 	o	reverts to single stepping for T1
Andrew>
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.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[Andrew Cagney]

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

That is what I want to be 100% clear on.

It means that there is probably going to be an interum version of this
feature - one that works with the current thread model.  This discussion
thread [er, groan] should provide the rationale behind the decision :-)

Enjoy,
	Andrew

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> 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.

Andrew> That is what I want to be 100% clear on.
Andrew>
Andrew> It means that there is probably going to be an interum version
Andrew> of this feature - one that works with the current thread
Andrew> model.  This discussion thread [er, groan] should provide the
Andrew> rationale behind the decision :-)

I think it's more like this feature will always work in a single
threaded context, and because of current limitations within GDB will
"mostly" work in a multi-threaded context.  It will fail if there is a
context switch in the middle of a step over range.  This same failure
can occur without the step-over-range command when GDB issues multiple
step-instruction commands and explicitly checks the pc to determine if
it is in range.  This problem will be addressed when GDB is enhanced
to keep track of each execution context.

I believe the protocol command itself is solid and won't need updating.

If debug agents are written correctly, they will store the step ranges
in thread specific instead of global variables.  So they will not have
to be updated.  IMO there is a risk here.  It would be best if we had
a reference implementation, but as of yet we don't have a sample debug
agent that supports threads.  Something to address in the future.  For
the time being, it might be acceptable to mention this in the remote
protocol section of the GDB User's manual.

Is there anything else you think must be addressed?  I'd like to make
sure you're comfortable with this before going forward.  On the other
hand, I'd like to get this in because it makes debugging so much nicer
over high latency links.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[J.T. Conklin]

>>>>> "Adam" == Adam Mirowski <mir@solfege.France.Sun.COM> writes:
>> Unfortunately, GDB still insists on inserting and removing breakpoints
>> around each step, so things aren't quite as efficient as they could be.
>> I think in time even that can be fixed.

Adam> Leaving breakpoints in all the time would probably greatly improve
Adam> performance. This is exactly what we do when debugging ChorusOS using
Adam> the Microtec XRAY debugger, at both applicative (Ethernet) and system
Adam> (serial line) level. XRAY leaves the breakpoints in all the time, but
Adam> requires that the debug server hides them when memory is being read.

On many (most?) GDB targets, GDB inserts breakpoints with memory
writes instead of a higher level "insert breakpoint" command.  While
at this point (ie, I have not studied this in enough detail) I think
it might be easier to support keeping breakpoints installed only in
those targets that support high level breakpoint insertion/removal,
that would require that we maintain the current code that inserts and
removes breakpoints via memory reads/writes for all the other targets.
I think the aggregate complexity of such a scheme is greater than just
doing it for all targets.

For example, since GDB has to read the original contents of the memory
region (so it can replace it when the breakpoint is removed).  We just
need a mechanism so that those bits of memory overlay the actual
memory contents when doing a memory read.

Adam> The debug servers currently forbid overwriting them, but could also
Adam> transparently re-insert a breakpoint after an underlying code
Adam> modification has been performed, assuming the instruction boundaries
Adam> did not change. Of course, hardware breakpoints are removed or disabled
Adam> systematically at each stop, but this is done by the server itself.

When I added support for insert/remove breakpoint packets to the
remote protocol, I used a similar scheme in our debug agent.
Breakpoints instructions are written to memory when the agent resumes
target execution, and they are removed when the agent regains control.
I don't have any interlocks between memory writes and breakpoint adds,
but since GDB always removes breakpoints it hasn't been an issue.

Adam> I think this optimization could be dealt-with in the target vector
Adam> itself, and we will probably attempt to implement it at some point in
Adam> the ChorusOS target vector code which we are developping currently.
Adam> Breakpoint removes could be ignored except if GDB does not re-insert
Adam> them when performing the target_resume() operation, assuming we already
Adam> hide the breakpoints.

I suppose you could probably do this all in the target vector.  That
seems somewhat hackish to me.  It just seems easier to go about this
in the higher layers.

I guess find out in as I investigate further.

Adam> BTW, since this thread was originally about optimizing stepping,
Adam> ChorusOS debug servers have a special step mode called "step till next
Adam> function call or return". Combined with "nexti", it is handy in order
Adam> to quickly understand what a given piece of unknown code does at
Adam> execution time or where it fails, by executing it from function call to
Adam> function call and looking at return values. I guess such a command
Adam> could be added to GDB as well (if it does not exist already, I am still
Adam> relatively new to all this :-).

So does the debug agent step instruction by instruction until a call
or ret instruction is reached?  Or does it disassemble starting from
the current PC?  Disassembly might be difficult to do concisely on 
some architectures, especially those with variable instruction size.

Of course, with step over range, the debugger can find when the next
call or ret instruction is located and limit the range to that insn.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol extension for step out of range

[Adam Mirowski]

Hello.

> Unfortunately, GDB still insists on inserting and removing breakpoints
> around each step, so things aren't quite as efficient as they could be.
> I think in time even that can be fixed.

Leaving breakpoints in all the time would probably greatly improve
performance. This is exactly what we do when debugging ChorusOS using
the Microtec XRAY debugger, at both applicative (Ethernet) and system
(serial line) level. XRAY leaves the breakpoints in all the time, but
requires that the debug server hides them when memory is being read.
The debug servers currently forbid overwriting them, but could also
transparently re-insert a breakpoint after an underlying code
modification has been performed, assuming the instruction boundaries
did not change. Of course, hardware breakpoints are removed or disabled
systematically at each stop, but this is done by the server itself.

    Breakpoints are actually even automatically re-inserted by the
    debug server (applicative debug only) at program restart time,
    unless the binaries in which they are located have changed, but
    this is probably more questionable. The advantage is that the
    debugger needs to issue only one request to restart a program.
    This fits with the paradigm of issuing only one remote request to
    start execution or to get the full state after a stop.

I think this optimization could be dealt-with in the target vector
itself, and we will probably attempt to implement it at some point in
the ChorusOS target vector code which we are developping currently.
Breakpoint removes could be ignored except if GDB does not re-insert
them when performing the target_resume() operation, assuming we already
hide the breakpoints.

BTW, since this thread was originally about optimizing stepping,
ChorusOS debug servers have a special step mode called "step till next
function call or return". Combined with "nexti", it is handy in order
to quickly understand what a given piece of unknown code does at
execution time or where it fails, by executing it from function call to
function call and looking at return values. I guess such a command
could be added to GDB as well (if it does not exist already, I am still
relatively new to all this :-).

Regards.
-Adam Mirowski