[RFA 03/08] multi-process support: remote multi-process extensions
Pedro Alves
pedro@codesourcery.com
Fri Sep 19 15:32:00 GMT 2008
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
More information about the Gdb-patches
mailing list