Re: multi-process remote protocol extensions

[Daniel Jacobowitz <drow at false dot org>]

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