This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: multi-process remote protocol extensions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]