multi-process remote protocol extensions

multi-process remote protocol extensions

[Pedro Alves]

Hi,

We'd like to add to GDB the possibility to debug multiple processes
simultaneously.  The first target we'll be working with, is the remote
target.  It happens that this OS we're working with, has the
convenient property that although each process has its own address
space, all processes see all the loaded code and data at the same
addresses, which allows us to incrementally implement multi-process
support, before taking care of multiple symbol tables.  After this,
we'll be adding support for non-stop debugging to the remote protocol
as well.

Unfortunately, the remote protocol, as is defined currently, can't
cope with multi-process support properly, all due to the fact that it
leaves the process id of the debuggee implicit.

What follows are proposals and questions on a direction the protocol
could take to support multi-process debugging.  The intention is not
to design a new protocol, but to extend the current protocol.  This is
not a finished design, and we'd very much like to have early community
input on this.

If you think this is entirely the wrong way to extend the protocol say
so; if you think this is the right direction, say so; if you have any
comment whatsoever, please speak up.  If you think you know the answer
to any of the questions below, please speak up.

Thanks you!

I've more or less split the proposal in these parts:

 1 - General notes
 2 - Reporting multi-process support
 3 - Thread IDs
 4 - Stop Reply Packets 
 5 - Interrupting/Stopping threads and processes.
 6 - Detaching and killing processes
 7 - Breakpoints
 8 - Resuming and stepping
 9 - What's left out

----------------------------------------------------------------------

Part 1 - General notes

 Multi process support makes sense when the stub can "attach" or "run"
 processes on demand.  Attaching and running is only supported on the
 extended-remote target, so multi-process extensions apply only to an
 extended-remote capable stub.

----------------------------------------------------------------------

Part 2 - Reporting multi-process support

 Multi-process debugging support should be reported both by GDB and
 the stub using the qSupported mechanism.  The feature name reported
 should be "multiprocess+".

----------------------------------------------------------------------

Part 3 - Thread IDs

 GDB currently identifies threads using 'ptid_t' values.  A ptid_t is
 a three-member structure containing a process ID, lightweight process
 ID (for the kernel-level thread within the process), and a thread ID
 (for the thread library's identifier).  This means that GDB is
 already carrying the information needed to find the process to which
 a given thread belongs to.

 Unfortunately, the way the remote protocol is defined currently, only
 allows passing a thread id number.  This means that when the stub
 reports an event in a thread, it doesn't tell GDB which process the
 thread belongs to; when GDB wants to resume a thread in a given
 process, there's no way to specify which process.  Same for reading
 registers, etc, etc.

 As an extension for multi-process support in the remote protocol, it
 is proposed that wherever the protocol specifies a thread or
 thread-id field, in multi-process mode, either the stub or GDB can
 specify a pid as well.  The format will be pid.tid, where it was just
 tid before.  The general format for specifying a thread is then
 extended

 from:

  thread-id := tid
  tid :- -1 | hex-digits

 to:
 
  thread-id := (pid.)?tid
  pid := -1 | hex-digits
  tid :- -1 | hex-digits

 Process ids are passed as hex strings, in the same format as thread
 ids are passed currently.

 E.g.:"123a.2"

 To specify the whole process, the form below is used:

 "pid.-1"

 In the case the protocol already specified that a given packet takes
 a pid parameter to specify a process, not a thread id, the dot `.'
 form is not used.  E.g. this packet is *not* changed:

  `vAttach;pid' Attach to a new process with the specified process ID

 To specify all processes, and all threads, the `-1.-1' form is used.
 Specifying all processes, and a specific thread is an error (e.g.,
 -1.14).

 Looking at the description of the H packet:

  `H c t'
  
  Set thread for subsequent operations (`m', `M', `g', `G', et.al.). c
  depends on the operation to be performed: it should be `c' for step
  and continue operations, `g' for other operations. The thread
  designator t may be `-1', meaning all the threads, a thread number,
  or `0' which means pick any thread.

 With this extension, the thread specified with Hg becomes again the
 stub side equivalent of inferior_ptid in the GDB side.

 The extension allows r/w memory, and r/w register packets to continue
 working unaltered, e.g.:

  `g' Read general registers. 

  `G XX...' Write general registers.

  `m addr,length'
    Read length bytes of memory starting at address addr

  `M addr,length:XX...'
    Write length bytes of memory starting at address addr.

  `p n' Read the value of register n;

  `P n...=r...'
    Write register n... with value r....

In addition, and as examples, these packets below also accept or
return the new pid.tid format, because they already handled a thread
id:

 `qGetTLSAddr:thread-id,offset,lm'

 `qfThreadInfo', `qsThreadInfo' and its reply:
       `m id,id...' - a comma-separated list of thread ids 

 `qC'
    Return the current thread id.

 `qThreadExtraInfo,id'

    Obtain a printable string description of a thread's attributes
    from the target OS. id is a thread-id in big-endian hex. This
    string may contain anything that the target OS thinks is
    interesting for GDB to tell the user about the thread. The string
    is displayed in GDB's info threads display. Some examples of
    possible thread extra info strings are `Runnable', or `Blocked on
    Mutex'.

 `T XX'
    Find out if the thread XX is alive. 

 `vCont[;action[:tid]]...'
   Resume the inferior, specifying different actions for each thread.

----------------------------------------------------------------------

Part 4 - Stop Reply Packets 

 The reply packets must also be extended to report the process ID of
 the thread that got the event.

 The T stop reply packet is defined currently like so:

  T AA n1:r1;n2:r2;...'
      The program received signal number AA (a two-digit hexadecimal
   number).  This is equivalent to an `S' response, except that the
   `n:r' pairs can carry values of important registers and other
   information directly in the stop reply packet, reducing round-trip
   latency. Single-step and breakpoint traps are reported this
   way. Each `n:r' pair is interpreted as follows:

    * If n is a hexadecimal number, it is a register number, and the
      corresponding r gives that register's value. r is a series of
      bytes in target byte order, with each byte given by a two-digit
      hex number.

    * If n is `thread', then r is the thread process ID, in hex.

  The multi-process extension allows specifying a (pid.)?tid as n.

  E.g.:
   `T 05 thread:12.2'


 The W and X reply packets have a different problem, they don't
 specify any thread or pid currently, so they can't be as easily
 extended.  These are the current descriptions:

  `W AA'
    The process exited, and AA is the exit status. This is only
    applicable to certain targets.

  `X AA'
    The process terminated with signal AA.

 In this case, I believe it is better to add a new stop reply packet:

  `vExited;why:id(:value)?

     The why's currently defined would be the same as the W and X stop
     replies, with the extension that the value field isn't limited to
     two nibbles.

     `vExited;W:pid:exit_code'

       W - process pid exited normally with exit status stored in
       `exit_code'

     `vExited;W:pid:signal'

       X - process pid exited signalled, exit signal recorded in
       `signal'

----------------------------------------------------------------------

Part 5 - Interrupting/Stopping threads and processes.

In both non-stop and multi-process, interrupting the remote with
^C or BREAK is not sufficiently accurate.  We need to be able to
specify a process or thread to interrupt.

What would be the preferred way to do this?  Assuming the (pid.)?tid
form is accepted, should we extend vCont with a new action, or
implement a new packet entirely?

----------------------------------------------------------------------

Part 6 - Detaching and killing processes

The detach, and kill packets, described as such in the manual,

 `D' Detach GDB from the remote system.

   Sent to the remote target before GDB disconnects via the
   detach command.

 `k' Kill request.

    FIXME: There is no description of how to operate when a specific
    thread context has been selected (i.e. does 'k' kill only that
    thread?).

 Both suffer from the problem that they don't specify which
 process should be killed or detached.

 What is the prefered form to fix this?

 I see three options:

   a) add new arguments to these packets, that are allowed by
      a multi-process aware stub.  If GDB is talking to a
      non multi-process aware stub, it doesn't send the extra
      arguments.

   b) Do not add arguments, but instead specify that the process
      to detach from is specified with the extended Hg packet.
   
   c) Specify new `vDetach pid`, and `vKill pid` packets.

 Given the FIXME on the description of the `k' packet, I'm somewhat
 inclined to specify new packets.

----------------------------------------------------------------------

Part 7 - Breakpoints

 Currently, the breakpoint packet are documented as so:

  `z type,addr,length'
  `Z type,addr,length'
  
    Insert (`Z') or remove (`z') a type breakpoint or watchpoint
    starting at address address and covering the next length bytes.

  The types currently defined are:

  0 - memory breakpoint
  1 - hardware breakpoint
  2 - write watchpoint
  3 - read watchpoint
  4 - access watchpoint

  Even today, support for thread specific breakpoints is missing on
  these packets.  There are stubs/OSs/debug APIs that can handle
  thread specific breakpoints internally, so GDB doesn't have to
  thread hop over those breakpoints.

  The other issue, is, with multi-process support, there's no way to
  specify to which process a breakpoint applies, or, if the breakpoint
  applies to all processes -- we're working with an OS where all
  processes see the full address space, where it makes sense to have
  global breakpoints.

  Since current stubs totally disregard the current thread (set by
  Hg), when setting a breakpoint with the `z' packets, it may not be
  safe to reuse Hg for per-process and per-thread breakpoints.

  OTOH, extending the packet format as,

  `z type,addr,length,tid'

  .. should be somewhat safe, in the following manner:

  - If the stub misparses it, by ignoring the new parameter, and sets
    a global breakpoint, GDB/infrun.c will still handle thread hops,
    so its as if nothing changed.

  - If the stub replies an empty response, to signal that it doesn't
    support the packet, GDB retries without the `,tid' field, and
    makes sure to not send to the stub the new packet format again.
    Everything goes back to what is was.

  - If the stub replies an error, to signal that it understood the
    packet, but saw a format error, GDB retries without the `,tid'
    field, and makes sure to not send to the stub the new packet
    format again.  Everything goes back to what is was.

  In multi-process, tid would take the (pid.)?tid form, so we can
  specify to which process and thread the breakpoint applies to.
  pid.-1 to the whole process, pid.tid to a single thread, -1.-1 to
  mean all attached processes and threads, and empty to mean all
  processes, even the ones not attached.

  If you think that extended the breakpoint packets is still not safe,
  then I propose a new similar packet:

  vBreak type,addr,lenght,tid

  ... the the same semantics I just described.


----------------------------------------------------------------------

Part 8 - Resuming and stepping

  vCont was devised to overcome limitations in the Hs/s/S/c/C packets,
  but it is an optional packet.

  Applying the same pid.tid extension to Hs, allows s,S,c and C to
  work in multi-process mode, but, *requiring* support for "vCont" in
  multi-process mode seems a better solution, than perpetuating some
  broken packets.  For this reason, we propose requiring vCont support
  in a multi-process aware stub.

----------------------------------------------------------------------

Part 9 - What's left out

 Left out of this proposal are Tracepoint and File-IO packets.

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Michael Snyder]

Hi Pedro, 

I'd like to throw out some thoughts *before* I read your 
somewhat long but apparently well-thought-out proposal.
I'll be brief.

Forgive me if what I toss out has already been covered.

Have you considered the cross-over between the general
case of debugging multiple processes, and the more restricted
case of debugging forks of the same process?  With forks,
(and excluding exec for the moment), you actually have 
several processes with separate address spaces but one
common symbol table.

I'm thinking that the support for fork debugging that we
already have might serve as a stepping-off point for what
you propose.

Maybe an incremental step would be to extend the fork
debugging functionality into the remote protocol and
get it to work with gdbserver?

I'll just go off and actually read what you wrote now...
;-)
Michael

Re: multi-process remote protocol extensions

[Pedro Alves]

A Thursday 29 May 2008 18:58:05, Michael Snyder wrote:
> Hi Pedro,
>
> I'd like to throw out some thoughts *before* I read your
> somewhat long but apparently well-thought-out proposal.
> I'll be brief.
>
> Forgive me if what I toss out has already been covered.
>
> Have you considered the cross-over between the general
> case of debugging multiple processes, and the more restricted
> case of debugging forks of the same process?  With forks,
> (and excluding exec for the moment), you actually have
> several processes with separate address spaces but one
> common symbol table.
>

Yes, we have.  In fact, we've been using native forks as
prototype for non-stop, multi-process support.  The main
difference to the current fork support, is that we enable
all processes to be running concurrently, while the
current support always leaves the non-current
processes stopped.

> I'm thinking that the support for fork debugging that we
> already have might serve as a stepping-off point for what
> you propose.
>
> Maybe an incremental step would be to extend the fork
> debugging functionality into the remote protocol and
> get it to work with gdbserver?
>

That has been considered.

> I'll just go off and actually read what you wrote now...
> ;-)

Thank you very much!

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Daniel Jacobowitz]

On Tue, May 27, 2008 at 10:33:23PM +0100, Pedro Alves wrote:
> Part 2 - Reporting multi-process support
> 
>  Multi-process debugging support should be reported both by GDB and
>  the stub using the qSupported mechanism.  The feature name reported
>  should be "multiprocess+".

Just a nit: the feature name will be "multiprocess".

One big picture question.  Have you thought about how to communicate
shared resources from the stub to the host?  e.g. "(all processes|no
processes|some specific processes) share memory", or "hardware
breakpoints affect (all processes|all threads in a process|one
thread|selectable behavior)"?

"Some processes share memory" is interesting for multi-core systems,
where two cores might be attached to a single RAM (or share a
software-enforced common MMU configuration), while another core lives
in its own little world.  Should sound familiar - Cell is a good
example.

GDB needs to know whether memory writes affect all processes to
correctly insert/remove memory breakpoints.  Though a better solution
to this may be requiring the stub to support software breakpoints via
Z0.  It would be nice to optimize out thread switching when reading
memory from different threads of the same process.

>  GDB currently identifies threads using 'ptid_t' values.  A ptid_t is
>  a three-member structure containing a process ID, lightweight process
>  ID (for the kernel-level thread within the process), and a thread ID
>  (for the thread library's identifier).  This means that GDB is
>  already carrying the information needed to find the process to which
>  a given thread belongs to.

You've extended pid to pid.tid.  Do we need pid.lwp.tid in the
protocol, for symmetry with ptid_t?  I assume the answer is "no"; just
making sure the question was considered.  It should be easier to
extend next time if we need this later.

>   The multi-process extension allows specifying a (pid.)?tid as n.
> 
>   E.g.:
>    `T 05 thread:12.2'

At this point are we talking about an all-stop debug server?  In which
case we do not need any additional information about what threads have
stopped.

>  The W and X reply packets have a different problem, they don't
>  specify any thread or pid currently, so they can't be as easily
>  extended.  These are the current descriptions:
> 
>   `W AA'
>     The process exited, and AA is the exit status. This is only
>     applicable to certain targets.
> 
>   `X AA'
>     The process terminated with signal AA.
> 
>  In this case, I believe it is better to add a new stop reply packet:
> 
>   `vExited;why:id(:value)?
> 
>      The why's currently defined would be the same as the W and X stop
>      replies, with the extension that the value field isn't limited to
>      two nibbles.
> 
>      `vExited;W:pid:exit_code'
> 
>        W - process pid exited normally with exit status stored in
>        `exit_code'
> 
>      `vExited;W:pid:signal'
> 
>        X - process pid exited signalled, exit signal recorded in
>        `signal'

The stub can not send vExited unless it has seen the
qSupported:multiprocess+ from GDB; otherwise GDB won't know what to do
with it.  So I don't see a strong argument here for a new response.

`W AA [; process:PID]' ?

There's some question in my mind about thread exits - should they be
handled the same as process exits.  They're not critical data, so for
all-stop method I have been thinking we could use some async droppable
messages to announce them (Jim's progress reporting work - you may
remember the discussion of this but it's not finished).  But for
non-stop mode we could report them as ordinary events in the same way
as process exit.  So, a hypothetical:

`W AA [; thread:THREAD.ID]'

> ----------------------------------------------------------------------
> 
> Part 5 - Interrupting/Stopping threads and processes.
> 
> In both non-stop and multi-process, interrupting the remote with
> ^C or BREAK is not sufficiently accurate.  We need to be able to
> specify a process or thread to interrupt.
> 
> What would be the preferred way to do this?  Assuming the (pid.)?tid
> form is accepted, should we extend vCont with a new action, or
> implement a new packet entirely?

This seems like a problem.  We can't send a packet at this point
without changing an assumption of the protocol; there's basically a
"token", meaning only one side is allowed to be sending packets.  ^C
is not a packet, for that reason.

If we're in all-stop mode, wouldn't C-c mean "interrupt everything"?
If so, this goes away.  In non-stop mode it'll be clear how to send a
new packet.

> Part 6 - Detaching and killing processes
> 
> The detach, and kill packets, described as such in the manual,
> 
>  `D' Detach GDB from the remote system.
> 
>    Sent to the remote target before GDB disconnects via the
>    detach command.
> 
>  `k' Kill request.
> 
>     FIXME: There is no description of how to operate when a specific
>     thread context has been selected (i.e. does 'k' kill only that
>     thread?).
> 
>  Both suffer from the problem that they don't specify which
>  process should be killed or detached.
> 
>  What is the prefered form to fix this?
> 
>  I see three options:
> 
>    a) add new arguments to these packets, that are allowed by
>       a multi-process aware stub.  If GDB is talking to a
>       non multi-process aware stub, it doesn't send the extra
>       arguments.
> 
>    b) Do not add arguments, but instead specify that the process
>       to detach from is specified with the extended Hg packet.
>    
>    c) Specify new `vDetach pid`, and `vKill pid` packets.
> 
>  Given the FIXME on the description of the `k' packet, I'm somewhat
>  inclined to specify new packets.

I agree that we should add a new packet to replace 'k'.  I'm not sure
about 'D'; there's nothing else wrong with it, so I am not inclined to
deprecate it.

Will vKill have any meaning connected to a non-multiprocess stub?  If
so we should clearly document it (e.g. CPU reset, single core reset,
whatever).

>   Since current stubs totally disregard the current thread (set by
>   Hg), when setting a breakpoint with the `z' packets, it may not be
>   safe to reuse Hg for per-process and per-thread breakpoints.

Good thinking.  I agree that this would be a bad decision.

>   - If the stub replies an empty response, to signal that it doesn't
>     support the packet, GDB retries without the `,tid' field, and
>     makes sure to not send to the stub the new packet format again.
>     Everything goes back to what is was.
> 
>   - If the stub replies an error, to signal that it understood the
>     packet, but saw a format error, GDB retries without the `,tid'
>     field, and makes sure to not send to the stub the new packet
>     format again.  Everything goes back to what is was.

I do not think these are a good idea.  Empty packet means "this entire
packet is not supported" and should continue to mean that.  And we can
either require stubs which announce multi-process support to support
this, or report a separate feature for it - I'm inclined to the latter
since this is useful even for non-multiprocess stubs.

>   In multi-process, tid would take the (pid.)?tid form, so we can
>   specify to which process and thread the breakpoint applies to.
>   pid.-1 to the whole process, pid.tid to a single thread, -1.-1 to
>   mean all attached processes and threads, and empty to mean all
>   processes, even the ones not attached.

Is this really the appropriate meaning for an empty argument?  The
current behavior, with no argument, is either pid.-1 or -1.-1.

>   If you think that extended the breakpoint packets is still not safe,
>   then I propose a new similar packet:
> 
>   vBreak type,addr,lenght,tid
> 
>   ... the the same semantics I just described.

I've no objection to extending the Z packets.  But I've no objection
to vBreak either - be sure to talk to Vladimir about this, we've got a
vBreak implementation lying around with a custom type, for a customer
project last year.

> Part 8 - Resuming and stepping
> 
>   vCont was devised to overcome limitations in the Hs/s/S/c/C packets,
>   but it is an optional packet.
> 
>   Applying the same pid.tid extension to Hs, allows s,S,c and C to
>   work in multi-process mode, but, *requiring* support for "vCont" in
>   multi-process mode seems a better solution, than perpetuating some
>   broken packets.  For this reason, we propose requiring vCont support
>   in a multi-process aware stub.

I completely agree.

> Part 9 - What's left out
> 
>  Left out of this proposal are Tracepoint and File-IO packets.

I think these are safe to ignore for the moment.  There is more likely
to be interest in tracepoints than in file I/O (semihosting).

-- 
Daniel Jacobowitz
CodeSourcery

Re: multi-process remote protocol extensions

[Pedro Alves]

Hi Daniel,

Thanks for taking the time to reply.

A Tuesday 03 June 2008 02:27:36, Daniel Jacobowitz wrote:

> One big picture question.  Have you thought about how to communicate
> shared resources from the stub to the host?  e.g. "(all processes|no
> processes|some specific processes) share memory", or "hardware
> breakpoints affect (all processes|all threads in a process|one
> thread|selectable behavior)"?
>
> "Some processes share memory" is interesting for multi-core systems,
> where two cores might be attached to a single RAM (or share a
> software-enforced common MMU configuration), while another core lives
> in its own little world.  Should sound familiar - Cell is a good
> example.
>

Good question.  I haven't planed anything for that, simply
because I had no need for it.  I'm working with a target stub
that has breakpoints support, and there's good chance
gdbserver will gain them too in a not so distant future.

> GDB needs to know whether memory writes affect all processes to
> correctly insert/remove memory breakpoints.  

True.  GDB has to know that so multiple breakpoint shadows
can be kept.  A breakpoint that is set at all attached
processes, where each process has its own code space, looks
similar in principle to breakpoints with multiple locations,
where each location is bound to a process, with its
own shadow.  If the breakpoint target is shared memory, we
can only insert one breakpoint location.

> Though a better solution 
> to this may be requiring the stub to support software breakpoints via
> Z0.  It would be nice to optimize out thread switching when reading
> memory from different threads of the same process.

Yeah.  I don't think we need to require Z0 at the protocol level,
but instead, leave it open.  If someone wants to implement
that knowledge on the GDB side (well, we'll probably get to do
it), it should be possible.

> >  GDB currently identifies threads using 'ptid_t' values.  A ptid_t is
> >  a three-member structure containing a process ID, lightweight process
> >  ID (for the kernel-level thread within the process), and a thread ID
> >  (for the thread library's identifier).  This means that GDB is
> >  already carrying the information needed to find the process to which
> >  a given thread belongs to.
>
> You've extended pid to pid.tid.  Do we need pid.lwp.tid in the
> protocol, for symmetry with ptid_t?  I assume the answer is "no"; just
> making sure the question was considered.  It should be easier to
> extend next time if we need this later.
>

I assumed that stubs that need some form of lwp.tid pair currently
to specify a task, do a stub-tid <-> lwp.tid mapping.

Perhaps we should tag ids?

T.ID.T.ID.T.ID

c.core.p.pid.l.lwp.t.tid
c.1.p.999.l.0.t.123

Tags:
 p - process
 l - lwp
 t - thread
 c - core
 w - whatever

p.999.t.123

That's just 4 characters more.

Or:

pPID.lLWP.TID
oOTHERNAMESPACE.pPID.lLWP.TID

 p999.123
 p999.l1.123

Can only use letters > f then, but that shouldn't be a problem?

I don't think using a letter is ambiguous in any case expecting a
thread id currently.

> >   The multi-process extension allows specifying a (pid.)?tid as n.
> >
> >   E.g.:
> >    `T 05 thread:12.2'
>
> At this point are we talking about an all-stop debug server?  In which
> case we do not need any additional information about what threads have
> stopped.
>

Yes, all-stop.  I don't think you're saying a change is not
needed here.  But for avoidance of doubt, the thread here must
also specify the pid (that's `12.' in the example), otherwise
GDB can't tell which process thread 2 belongs to.

> >  The W and X reply packets have a different problem, they don't
> >  specify any thread or pid currently, so they can't be as easily
> >  extended.  These are the current descriptions:
> >
> >   `W AA'
> >     The process exited, and AA is the exit status. This is only
> >     applicable to certain targets.
> >
> >   `X AA'
> >     The process terminated with signal AA.
> >
> >  In this case, I believe it is better to add a new stop reply packet:
> >
> >   `vExited;why:id(:value)?
> >
> >      The why's currently defined would be the same as the W and X stop
> >      replies, with the extension that the value field isn't limited to
> >      two nibbles.
> >
> >      `vExited;W:pid:exit_code'
> >
> >        W - process pid exited normally with exit status stored in
> >        `exit_code'
> >
> >      `vExited;W:pid:signal'
> >
> >        X - process pid exited signalled, exit signal recorded in
> >        `signal'
>
> The stub can not send vExited unless it has seen the
> qSupported:multiprocess+ from GDB; otherwise GDB won't know what to do
> with it.  So I don't see a strong argument here for a new response.
>
> `W AA [; process:PID]' ?
>

I'm all for it.  I had proposed this first internally, but had
feared adding arguments to existing packets would be unaccepted,
If we can, then I'd prefer it too.  It's very easy for a stub
to not send it if the GDB side doesn't support it.

> There's some question in my mind about thread exits - should they be
> handled the same as process exits.  They're not critical data, so for
> all-stop method I have been thinking we could use some async droppable
> messages to announce them 

Yeah, for non-stop we'll want thread creation too.

> (Jim's progress reporting work - you may 
> remember the discussion of this but it's not finished).

Hmm, I don't seem to remember this.  Was this a public discussion?

> But for non-stop mode we could report them as ordinary events in the same 
way
> as process exit.  So, a hypothetical:
>
> `W AA [; thread:THREAD.ID]'
>

Yes.

Not stricly multi-process related, but while we're at it, two
nibbles `AA' only is unnecessarilly limiting.  That was
the other reason for proposing new status packets.

> > ----------------------------------------------------------------------
> >
> > Part 5 - Interrupting/Stopping threads and processes.
> >
> > In both non-stop and multi-process, interrupting the remote with
> > ^C or BREAK is not sufficiently accurate.  We need to be able to
> > specify a process or thread to interrupt.
> >
> > What would be the preferred way to do this?  Assuming the (pid.)?tid
> > form is accepted, should we extend vCont with a new action, or
> > implement a new packet entirely?
>
> This seems like a problem.  We can't send a packet at this point
> without changing an assumption of the protocol; there's basically a
> "token", meaning only one side is allowed to be sending packets.  ^C
> is not a packet, for that reason.
>
> If we're in all-stop mode, wouldn't C-c mean "interrupt everything"?
> If so, this goes away.  In non-stop mode it'll be clear how to send a
> new packet.
>

Ok, I was thinking ahead, and mixed up.  Let's drop this for now.

> > Part 6 - Detaching and killing processes
> >
> > The detach, and kill packets, described as such in the manual,
> >
> >  `D' Detach GDB from the remote system.
> >
> >    Sent to the remote target before GDB disconnects via the
> >    detach command.
> >
> >  `k' Kill request.
> >
> >     FIXME: There is no description of how to operate when a specific
> >     thread context has been selected (i.e. does 'k' kill only that
> >     thread?).
> >
> >  Both suffer from the problem that they don't specify which
> >  process should be killed or detached.
> >
> >  What is the prefered form to fix this?
> >
> >  I see three options:
> >
> >    a) add new arguments to these packets, that are allowed by
> >       a multi-process aware stub.  If GDB is talking to a
> >       non multi-process aware stub, it doesn't send the extra
> >       arguments.
> >
> >    b) Do not add arguments, but instead specify that the process
> >       to detach from is specified with the extended Hg packet.
> >
> >    c) Specify new `vDetach pid`, and `vKill pid` packets.
> >
> >  Given the FIXME on the description of the `k' packet, I'm somewhat
> >  inclined to specify new packets.
>
> I agree that we should add a new packet to replace 'k'.  I'm not sure
> about 'D'; there's nothing else wrong with it, so I am not inclined to
> deprecate it.

So, do a) for D ?

 D;process:PID

>
> Will vKill have any meaning connected to a non-multiprocess stub?  If
> so we should clearly document it (e.g. CPU reset, single core reset,
> whatever).
>

No reset:

 vKill;PID - kills process PID, in an OS sense.  Get rid of
process PID.

But can be:
 vKill;process:PID - kills process PID.
 vKill;thread:ID - kills thread ID, where ID can be an extended
                   pid.tid (or whatever comes decided) form in
                   multi-process aware stubs.

I'm not sure we should put resets on the same boat as kills.
Killing a process or a thread should have a reply.  It isn't
specified currently if the packets requires a reply or not.
gdbserver doesn't send one, and GDB doesn't expect one.

A reset on the core the stub is running, may have the effect that
it's not always possible for a packet acknowledge to be flushed
on the stub side, and GDB never gets the answer.

Maybe that should be kept a separate packet, similar in vein
to R - restart - vReset/vRestart,

 vReset;core:ID - resets core ID (-1 all cores).  This packet
 has no reply.

> >   - If the stub replies an empty response, to signal that it doesn't
> >     support the packet, GDB retries without the `,tid' field, and
> >     makes sure to not send to the stub the new packet format again.
> >     Everything goes back to what is was.
> >
> >   - If the stub replies an error, to signal that it understood the
> >     packet, but saw a format error, GDB retries without the `,tid'
> >     field, and makes sure to not send to the stub the new packet
> >     format again.  Everything goes back to what is was.
>
> I do not think these are a good idea.  Empty packet means "this entire
> packet is not supported" and should continue to mean that.  And we can
> either require stubs which announce multi-process support to support
> this, or report a separate feature for it - I'm inclined to the latter
> since this is useful even for non-multiprocess stubs.
>

Ok.  The whole idea so it wasn't tied to multiprocess support, and
the notion that if per-thread breakpoints aren't support on the stub
side, the only fallback, is normal process-wide breakpoints, and have
GDB filter them, like it is done currently.

I agree that if we extend Z and announce in some form, then it should
be announced separatelly to multi-process support.

> >   In multi-process, tid would take the (pid.)?tid form, so we can
> >   specify to which process and thread the breakpoint applies to.
> >   pid.-1 to the whole process, pid.tid to a single thread, -1.-1 to
> >   mean all attached processes and threads, and empty to mean all
> >   processes, even the ones not attached.
>
> Is this really the appropriate meaning for an empty argument?  The
> current behavior, with no argument, is either pid.-1 or -1.-1.

Yeah, I take it back.  Making a Z packet with no argument mean all
current attached processes makes more sense.  I'll talk with Vlad about
this vBreak experience.

> >   If you think that extended the breakpoint packets is still not safe,
> >   then I propose a new similar packet:
> >
> >   vBreak type,addr,lenght,tid
> >
> >   ... the the same semantics I just described.
>
> I've no objection to extending the Z packets.  But I've no objection
> to vBreak either - be sure to talk to Vladimir about this, we've got a
> vBreak implementation lying around with a custom type, for a customer
> project last year.

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Daniel Jacobowitz]

On Tue, Jun 03, 2008 at 04:20:28PM +0100, Pedro Alves wrote:
> Or:
> 
> pPID.lLWP.TID
> oOTHERNAMESPACE.pPID.lLWP.TID
> 
>  p999.123
>  p999.l1.123
> 
> Can only use letters > f then, but that shouldn't be a problem?

I like this one, though I would only define p for the moment.
A whole process becomes "p99" and the special ".-1" can go away.

> Yes, all-stop.  I don't think you're saying a change is not
> needed here.  But for avoidance of doubt, the thread here must
> also specify the pid (that's `12.' in the example), otherwise
> GDB can't tell which process thread 2 belongs to.

Right.

> > (Jim's progress reporting work - you may 
> > remember the discussion of this but it's not finished).
> 
> Hmm, I don't seem to remember this.  Was this a public discussion?

Nope.  I'll point you to it.

> > But for non-stop mode we could report them as ordinary events in the same 
> way
> > as process exit.  So, a hypothetical:
> >
> > `W AA [; thread:THREAD.ID]'
> >
> 
> Yes.
> 
> Not stricly multi-process related, but while we're at it, two
> nibbles `AA' only is unnecessarilly limiting.  That was
> the other reason for proposing new status packets.

Allow more than just two nibbles if gdb supports the semicolon?
 
> > I agree that we should add a new packet to replace 'k'.  I'm not sure
> > about 'D'; there's nothing else wrong with it, so I am not inclined to
> > deprecate it.
> 
> So, do a) for D ?
> 
>  D;process:PID

Yes, I think so.

> > Will vKill have any meaning connected to a non-multiprocess stub?  If
> > so we should clearly document it (e.g. CPU reset, single core reset,
> > whatever).
> >
> 
> No reset:
> 
>  vKill;PID - kills process PID, in an OS sense.  Get rid of
> process PID.
> 
> But can be:
>  vKill;process:PID - kills process PID.
>  vKill;thread:ID - kills thread ID, where ID can be an extended
>                    pid.tid (or whatever comes decided) form in
>                    multi-process aware stubs.

I don't think allowing kills of a specific thread is useful.  Probably
some systems will not be able to implement it.

> I'm not sure we should put resets on the same boat as kills.
> Killing a process or a thread should have a reply.  It isn't
> specified currently if the packets requires a reply or not.
> gdbserver doesn't send one, and GDB doesn't expect one.
> 
> A reset on the core the stub is running, may have the effect that
> it's not always possible for a packet acknowledge to be flushed
> on the stub side, and GDB never gets the answer.
> 
> Maybe that should be kept a separate packet, similar in vein
> to R - restart - vReset/vRestart,
> 
>  vReset;core:ID - resets core ID (-1 all cores).  This packet
>  has no reply.

Anyway, let's define that vKill is only used for processes today.
Sound OK?

-- 
Daniel Jacobowitz
CodeSourcery

Re: multi-process remote protocol extensions

[Pedro Alves]

A Tuesday 03 June 2008 16:42:11, Daniel Jacobowitz wrote:
> On Tue, Jun 03, 2008 at 04:20:28PM +0100, Pedro Alves wrote:
> > Or:
> >
> > pPID.lLWP.TID
> > oOTHERNAMESPACE.pPID.lLWP.TID
> >
> >  p999.123
> >  p999.l1.123
> >
> > Can only use letters > f then, but that shouldn't be a problem?
>
> I like this one, though I would only define p for the moment.
> A whole process becomes "p99" and the special ".-1" can go away.
>

Ack.  I'll look a bit deeper to see if there's any problem, but
I like it better too.  Great.

> > Not stricly multi-process related, but while we're at it, two
> > nibbles `AA' only is unnecessarilly limiting.  That was
> > the other reason for proposing new status packets.
>
> Allow more than just two nibbles if gdb supports the semicolon?

How can the stub know if GDB supports the semicolon?

> > > Will vKill have any meaning connected to a non-multiprocess stub?  If
> > > so we should clearly document it (e.g. CPU reset, single core reset,
> > > whatever).
> >
> > No reset:
> >
> >  vKill;PID - kills process PID, in an OS sense.  Get rid of
> > process PID.
> >

> Anyway, let's define that vKill is only used for processes today.
> Sound OK?

Yep.  Was just pointing future extension possibilities.  I've no
use for killing threads now.

I'll tinker a bit, readjust the proposal doc and repost.

Thank you.

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Daniel Jacobowitz]

On Tue, Jun 03, 2008 at 04:54:46PM +0100, Pedro Alves wrote:
> > > Not stricly multi-process related, but while we're at it, two
> > > nibbles `AA' only is unnecessarilly limiting.  That was
> > > the other reason for proposing new status packets.
> >
> > Allow more than just two nibbles if gdb supports the semicolon?
> 
> How can the stub know if GDB supports the semicolon?

By the multiprocess announcement, I suppose.  We already needed to
know this since ;process would break otherwise.

-- 
Daniel Jacobowitz
CodeSourcery

Re: multi-process remote protocol extensions

[Pedro Alves]

A Tuesday 03 June 2008 17:13:40, Daniel Jacobowitz wrote:
> On Tue, Jun 03, 2008 at 04:54:46PM +0100, Pedro Alves wrote:
> > > > Not stricly multi-process related, but while we're at it, two
> > > > nibbles `AA' only is unnecessarilly limiting.  That was
> > > > the other reason for proposing new status packets.
> > >
> > > Allow more than just two nibbles if gdb supports the semicolon?
> >
> > How can the stub know if GDB supports the semicolon?
>
> By the multiprocess announcement, I suppose.  We already needed to
> know this since ;process would break otherwise.

Hmmm, no, this is a separate issue to multiprocess, it affects
single-process stubs as well, e.g., native Windows gdbserver is
replying 'W' AA, but the exit code of a Windows process isn't
limited to 8-bits.  It should be reported as a separate
feature, I guess.

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Pedro Alves]

A Tuesday 03 June 2008 18:04:11, Pedro Alves wrote:
> A Tuesday 03 June 2008 17:13:40, Daniel Jacobowitz wrote:
> > On Tue, Jun 03, 2008 at 04:54:46PM +0100, Pedro Alves wrote:
> > > > > Not stricly multi-process related, but while we're at it, two
> > > > > nibbles `AA' only is unnecessarilly limiting.  That was
> > > > > the other reason for proposing new status packets.
> > > >
> > > > Allow more than just two nibbles if gdb supports the semicolon?
> > >
> > > How can the stub know if GDB supports the semicolon?
> >
> > By the multiprocess announcement, I suppose.  We already needed to
> > know this since ;process would break otherwise.
>
> Hmmm, no, this is a separate issue to multiprocess, it affects
> single-process stubs as well, e.g., native Windows gdbserver is
> replying 'W' AA, but the exit code of a Windows process isn't
> limited to 8-bits.  It should be reported as a separate
> feature, I guess.

(lamely replying to myself)

Well, if GDB starts announcing multi process in the same
release it supports more than two nibbles, all should be fine,
the stub can rely on the multi-process support check.  I'm in
no hurry to fix this, so, I'm ok with the wait.  :-)

Not as clean, but avoids growing the qSupported string.

-- 
Pedro Alves

Re: multi-process remote protocol extensions

[Daniel Jacobowitz]

On Tue, Jun 03, 2008 at 06:12:18PM +0100, Pedro Alves wrote:
> Well, if GDB starts announcing multi process in the same
> release it supports more than two nibbles, all should be fine,
> the stub can rely on the multi-process support check.  I'm in
> no hurry to fix this, so, I'm ok with the wait.  :-)

Right, that's exactly what I meant.

-- 
Daniel Jacobowitz
CodeSourcery