Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>
Cc: Gary Benson <gbenson@redhat.com>,
	gdb-patches <gdb-patches@sourceware.org>,
	       Philippe Waroquiers <philippe.waroquiers@skynet.be>
Subject: Re: [PATCH] Make only user-specified executable filenames sticky
Date: Wed, 13 May 2015 08:39:00 -0000	[thread overview]
Message-ID: <55530DB4.3040608@redhat.com> (raw)
In-Reply-To: <CADPb22RvXNSxaXibcKGTk1ZhUnGcAoaG2VuuthAp9zMNd1tXOQ@mail.gmail.com>

On 05/12/2015 05:03 PM, Doug Evans wrote:
> On Tue, May 12, 2015 at 3:36 AM, Pedro Alves <palves@redhat.com> wrote:
>> Another way to handle that would be to leave the file loaded
>> in inferior 1, and switch to a new inferior to investigate
>> the other process.
> 
> Sorry, these things don't always occur to me before I hit Send.
> 
> Switching to a new inferior is three steps.
> (gdb) add-inf
> (gdb) infer 2
> (gdb) attach PID
> 
> IWBN to have something like the following
> 
> (gdb) attach -n PID  # "n" for "in new inferior"

I agree here.  It's actually one thing that has been crossing
my mind recently.  I've been experimenting a lot with gdb's CLI around
multi-thread and multi-inferior things, in context of
i/t sets (see [1]), and making it possible to have "attach" create
new inferiors would help.  E.g., attaching to more than one process
would be nice, like "attach PID1 PID2" and "attach --all-children PID".
Maybe even make "attach PID" automatically decide to reuse the
same inferior, so that gdb; attach" reuses inferior 1, but if you've
already used inferior 1, "attach" creates another one.
We do something like that when "target extended-remote" finds multiple
processes already running on the server side.

For preparing a new inferior for "run", we
have "add-inferior -exec FILE", though maybe "file -n" would
be nicer.

[1] https://github.com/palves/gdb/commits/palves/itsets-wip-width
    (note: very experimental, not ready for general feedback yet)
> 
> I kinda would rather do it differently, because it's more than
> just "attach" where one would like to do something in a new inferior,
> and IWBN to solve them all with one new command (or extension
> of existing command).  E.g., "new-inferior <command>", as in
> "new-inferior attach PID". Or some such.

Guess that could be the existing "add-inferior", as in
"add-inferior -exec PROG attach PID".  Not really sure I
like that direction though.  Seems less convenient and more
prone to have users forget/miss this usage than teaching
"attach" etc. directly to me.

In an i/t sets world, another option would be for commands
that create new inferiors to set the current focus to the just
created inferior(s).  Then the following commands would simply
apply to the new inferiors.

> 
> OTOH, "new-inferior pwd" doesn't make much sense,
> and "attach -n PID" is simple (we'd want to enumerate
> all such commands and make sure the same option letter is
> available for use in all of them).

Yeah.

Thanks,
Pedro Alves


      reply	other threads:[~2015-05-13  8:39 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  9:48 qXfer:exec-file:read and non multiprocess target Philippe Waroquiers
2015-05-05 11:02 ` Gary Benson
2015-05-05 20:45   ` Philippe Waroquiers
2015-05-06 10:31     ` Gary Benson
2015-05-06 17:10       ` [PATCH] Locate executables on remote stubs without multiprocess extensions Gary Benson
2015-05-06 17:15         ` Eli Zaretskii
2015-05-06 17:16         ` Gary Benson
2015-05-11 14:37           ` Pedro Alves
2015-05-12 11:03             ` Gary Benson
2015-05-05 15:14 ` qXfer:exec-file:read and non multiprocess target Gary Benson
2015-05-06 10:26   ` [PATCH] Make only user-specified executable filenames sticky Gary Benson
2015-05-06 12:19     ` Pedro Alves
2015-05-06 14:21       ` Pedro Alves
2015-05-06 15:20       ` Gary Benson
2015-05-11 13:57         ` Pedro Alves
2015-05-06 14:46     ` Philippe Waroquiers
2015-05-06 15:41       ` Gary Benson
2015-05-11 13:58         ` Pedro Alves
2015-05-11 20:25       ` Doug Evans
2015-05-11 17:14     ` Don Breazeal
2015-06-05  9:37       ` Gary Benson
2015-06-05 14:54         ` Don Breazeal
2015-07-03 11:14           ` Gary Benson
2015-07-06 12:53             ` Joel Brobecker
2015-07-17 21:48             ` Joel Brobecker
2015-05-11 20:23     ` Doug Evans
2015-05-12 10:36       ` Pedro Alves
2015-05-12 11:13         ` Gary Benson
2015-05-12 11:16           ` Pedro Alves
2015-05-12 13:48             ` Gary Benson
2015-05-12 14:08               ` Pedro Alves
2015-05-12 15:49         ` Doug Evans
2015-05-13  7:55           ` Gary Benson
2015-05-13  9:12             ` Pedro Alves
2015-06-03 17:23               ` Joel Brobecker
2015-06-05 11:22                 ` [PATCH v2] Make only user-specified executable and symbol " Gary Benson
2015-06-07 11:40                   ` Philippe Waroquiers
2015-06-08  9:01                     ` [PATCH v3] " Gary Benson
2015-06-08 19:42                       ` Philippe Waroquiers
2015-07-03 11:01                         ` Gary Benson
2015-07-03 15:44                       ` Pedro Alves
2015-07-06 13:01                         ` Pedro Alves
2015-06-07 12:03                   ` [PATCH v2] " Philippe Waroquiers
2015-06-07 12:13                   ` Philippe Waroquiers
2015-05-13  8:06           ` [PATCH] Make only user-specified executable " Pedro Alves
2015-05-12 16:03         ` Doug Evans
2015-05-13  8:39           ` Pedro Alves [this message]

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=55530DB4.3040608@redhat.com \
    --to=palves@redhat.com \
    --cc=dje@google.com \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=philippe.waroquiers@skynet.be \
    /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