Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Marc Khouzam" <marc.khouzam@ericsson.com>
To: "Vladimir Prus" <vladimir@codesourcery.com>
Cc: <gdb@sources.redhat.com>
Subject: RE: Multiprocess MI extensions
Date: Tue, 17 Jun 2008 18:32:00 -0000	[thread overview]
Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA042911E1@ecamlmw720.eamcs.ericsson.se> (raw)
In-Reply-To: <200806141915.49678.vladimir@codesourcery.com>


> > Currently, when the inferior exits, there is an event that 
> looks like:
> > *stopped,reason="exited-normally"
> > or some other variant.
> > 
> > I gather this is not a considered option for multi-process?
> > It probably would have helped with backwards compatibility.
> 
> I don't know, honestly. Is extending *stopped with 
> thread-group field really
> much better for backward compatibility that new notification?

I had imagined to make multi-process debugging the only variant, which
would makes a single-process session actually be a multi-process one
with a single process (or thread-group).
But what we can do is look for both the new notification for process exit
and the *stopped one, which ever _one_ we see, will be the trigger.
So, as long as we get one or the other but not both at the same time,
it should be fine.

On another point for multi-process, I was wondering if there will be a need
to select a thread-group before issuing commands affecting a entire
group?  Something similar to what we have with -thread-select.  
I was thinking that a command affecting a group would apply to the group
to which the current thread belongs.

This would allow for any command currently applicable to the single process
or inferior, to be applied in the same way.  To be honnest, I'm not entirely
sure this is a good idea.

Did you guys discuss this?

Thanks

Marc


  reply	other threads:[~2008-06-17 18:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-10 19:24 Vladimir Prus
2008-06-10 19:42 ` Pawel Piech
2008-06-10 19:53   ` Vladimir Prus
2008-06-11 16:40     ` Pawel Piech
2008-06-11 16:43       ` Vladimir Prus
2008-06-13 17:34     ` Marc Khouzam
2008-06-14 15:15       ` Vladimir Prus
2008-06-17 18:32         ` Marc Khouzam [this message]
2008-06-18  8:39           ` Vladimir Prus
2008-06-18 13:49             ` Marc Khouzam
2008-06-17 19:28     ` Marc Khouzam
2008-06-17 19:33       ` Marc Khouzam
2008-06-17 19:50         ` Vladimir Prus
2008-06-17 20:19           ` Marc Khouzam
2008-06-18  7:41             ` Vladimir Prus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6D19CA8D71C89C43A057926FE0D4ADAA042911E1@ecamlmw720.eamcs.ericsson.se \
    --to=marc.khouzam@ericsson.com \
    --cc=gdb@sources.redhat.com \
    --cc=vladimir@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox