public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Gary Benson <gbenson@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>,
		Philippe Waroquiers <philippe.waroquiers@skynet.be>
Subject: Re: [PATCH] Make only user-specified executable filenames sticky
Date: Mon, 11 May 2015 20:23:00 -0000	[thread overview]
Message-ID: <CADPb22SDB9qV1BgP2JmCxsu-E8QXDj1SLnCjBjGWn+g+1M7V7A@mail.gmail.com> (raw)
In-Reply-To: <1430907977-30605-1-git-send-email-gbenson@redhat.com>

On Wed, May 6, 2015 at 3:26 AM, Gary Benson <gbenson@redhat.com> wrote:
> Hi all,
>
> In GDB some executable files are supplied by the user (e.g. using a
> "file" command) and some are determined by GDB (e.g. while processing
> an "attach" command).  GDB will not attempt to determine a filename if
> one has been set.  This causes problems if you attach to one process
> and then attach to another: GDB will not attempt to discover the main
> executable on the second attach.  If the two processes have different
> main executable files then the symbols will now be wrong.
>
> This commit updates GDB to keep track of which executable filenames
> were supplied by the user.  When GDB might attempt to determine an
> executable filename and one is already set, filenames determined by
> GDB may be overridden but user-supplied filenames will not.

Hi.

I can imagine sometimes wanting either behaviour, depending on
the situation.
E.g., if I supply a file name do some stuff, and then change
my mind or wish to investigate a difference process I may
wish gdb to automagically pick up the file name of the new process.
OTOH other times I may wish to override what gdb would
automagically choose and supply my own file name.

This suggests having an option to the command to choose
the behaviour one wants (I'd hate a global switch for this).
This doesn't have to be added today of course.
I only bring this up in case a behavioural change
is being introduced (it doesn't appear so, but I could be wrong),
in which case now is a good time to discuss it.

My main reason for sending this message, though, is that
I think a notification to the user is warranted here.
E.g., something like
"Using xyz for the symbol file name, since that's
what you specified. If this is wrong, please do [...]."
or whatever. Just something so that the user knows
gdb is not automagically picking the file.

  parent reply	other threads:[~2015-05-11 20:23 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 [this message]
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

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=CADPb22SDB9qV1BgP2JmCxsu-E8QXDj1SLnCjBjGWn+g+1M7V7A@mail.gmail.com \
    --to=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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).