Async mode and setting breakpoints

Async mode and setting breakpoints

[Marc Khouzam]

Hi,

I'm investigating the value of using async mode without non-stop
to decide if I should use it whenever possible for DSF-GDB.

The main advantage I was seeking was to be able to set a breakpoint
while the target was running.  It does not work though.
I'm guessing that while the inferior is running, it is not possible
for GDB to plant the breakpoint (although the bp command is accepted
without complaint).  I guess I still have to interrupt the inferior, 
set the bp, and resume, even in async mode?

Thanks

Marc

Re: Async mode and setting breakpoints

[Pedro Alves]

Hi Marc,

On Thursday 18 December 2008 15:41:33, Marc Khouzam wrote:
> I'm investigating the value of using async mode without non-stop
> to decide if I should use it whenever possible for DSF-GDB.
> 
> The main advantage I was seeking was to be able to set a breakpoint
> while the target was running.  It does not work though.
> I'm guessing that while the inferior is running, it is not possible
> for GDB to plant the breakpoint (although the bp command is accepted
> without complaint).  I guess I still have to interrupt the inferior, 
> set the bp, and resume, even in async mode?

Short answer, yes, in all async capable targets currently supported by GDB
(that's linux native and remote).

This is target dependent, on two levels.

On native linux, inserting a breakpoint in all-stop,async will fail when
the target is running, because it isn't possible to patch memory when
the target is running.  GDB could be momentarily stopping an LWP of the
inferior process to do this, but it isn't.  There are some threads in
the archives about this.

The remote target is a bit more complicated.  Against remote targets, even
if the OS allows patching memory or inserting breakpoints to running
processes, due to the design of the years old standard all-stop remote
protocol, it is not possible to issue any command to the remote while
the target is running.

Inserting a breakpoint requires talking to the remote side.

In more detail, after GDB issues a resume request (vCont, s, c, etc.), the
remote side will not be ready for any other packet.  GDB can only send
an interrupt request (which is really an out of band request) in this state,
or wait for a stop reply.  If GDB did send another packet in this state, both the
stub and GDB would end up confused.  To prevent this, if this condition
is detected, GDB errors out with "Cannot execute this command while the target
is running." (remote.c:putpkt_binary).

This means that in all-stop + async + remote, any GDB command that tries
to talk to the remote side while the remote is running will error out.  Any
command that *doesn't* talk to the remote side will still work.

The non-stop version of the remote protocol removed this protocol level
limitation, mostly by making stop replies asynchronous, so the stub can
accept more commands while the target is running.  It is still dependent on
the stub/OS if it is possible to insert breakpoints or patch memory while the
target is running though.  Same in native non-stop.

-- 
Pedro Alves