Re: [RFA 03/08] multi-process support: remote multi-process extensions

[Pedro Alves <pedro@codesourcery.com>]

On Friday 19 September 2008 00:24:39, Daniel Jacobowitz wrote:
> On Fri, Sep 12, 2008 at 05:51:30PM +0100, Pedro Alves wrote:
> > 2008-09-12  Pedro Alves  <pedro@codesourcery.com>
> >
> > 	Implement multi-process extensions.
>
> This looks basically OK to me.  I've got one question, which is not
> bad for a patch this size :-)

Yay!  :-)

> What about "target remote" vs "target extended-remote"?  Are you
> always expected to use target extended-remote to connect to a
> multi-process target, and if so, should we enforce that?  Or are
> remote and extended-remote supposed to behave the same if the target
> is multi-process?

Good question.  Originally, it was meant to only be used
by extended-remote.

[cross reference for the archives:
 http://sourceware.org/ml/gdb/2008-05/msg00166.html]

But maybe we can try to do something that is sensible
with target remote.

I can imagine attaching with "target remote" to a stub that
was already debugging multiple things (disconnect/connect,
for instance).  You wont be able to run new processes, but,
you'll be able to see what was already there.

> I ask because of the change in remote_detach_1.  If
> rs->multi_process_aware is set, we never unregister from
> the target.  But we call target_mourn_inferior which will unpush the
> remote target in that case.

Yeah.  I can imagine making use of these extensions for
simple multi-core configurations, where detaching from a single
core doesn't make that much sense.

How about we still send the older 'D' packet when in "target
remote", and leave 'D;pid' "target extended-remote"?  That would
mirror vAttach.  I'm already sending 'k' in "target remote"
instead of 'vKill', even if multi-process.

A multi-process aware stub would them detach from processes
(or something else exported as processes to gdb) when seeing 'D'.
I'm already applying similar logic to target_kill/'k'/'vKill'.

I just noticed a bug I had fixed in an internal tree, that
I forgot adding to this patch.  "info threads" in addition to
adding threads to the thread list, should also add inferiors
to the inferior list (e.g., disconnect/connect).

-- 
Pedro Alves