From: Tom Tromey <tromey@redhat.com>
To: Andreas Schwab <schwab@suse.de>
Cc: gdb-patches@sourceware.org
Subject: Re: RFA: attach to a PID using a different exec
Date: Thu, 13 Nov 2008 23:55:00 -0000 [thread overview]
Message-ID: <m38wrn4ba7.fsf@fleche.redhat.com> (raw)
In-Reply-To: <jevdurfl2v.fsf@sykes.suse.de> (Andreas Schwab's message of "Thu\, 13 Nov 2008 21\:05\:28 +0100")
>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
Daniel> I don't want GDB to prompt my to switch to the stripped
Daniel> program...
Andreas> I think a warning would still be helpful, similar to what you
Andreas> get when you load a core that does not match.
I did consider a warning.
My patch was tailored to my use case, where basically I made an early
mistake in selecting the exec file. Suppose in this situation that
gdb warns about the non-matching exec. After that, gdb is left in an
un-useful state, and furthermore the user has to resort to
cut-and-paste (or a lot of typing) to get back to the exec file that
gdb already knows. That seems unfriendly.
I did not think of either Daniel's or Joel's use cases.
I would classify Daniel's as advanced usage -- but again, perhaps
tinged by my experience. That is, I have never once done what he
describes, but then I almost always have separate debug info available
for those few stripped programs I must debug.
Joel's is an interesting case of making the "opposite" mistake
(starting the wrong program), but I think it doesn't really have an
effect on the outcome of this discussion (either thing gdb does will
yield the right answer when he restarts the inferior and reattaches).
Another oddity in this area, btw, is that at least the linux native
target gives a funny report if the attached process' exec file has
been deleted.
I don't like to add new options, in general, but I would add one for
this case if that would help.
Tom
next prev parent reply other threads:[~2008-11-13 20:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 22:32 Tom Tromey
2008-11-13 22:49 ` Daniel Jacobowitz
2008-11-13 22:54 ` Tom Tromey
2008-11-13 23:24 ` Stan Shebs
2008-11-13 23:51 ` Daniel Jacobowitz
2008-11-13 22:59 ` Joel Brobecker
2008-11-13 23:17 ` Andreas Schwab
2008-11-13 23:55 ` Tom Tromey [this message]
2008-11-14 0:54 ` Michael Snyder
2008-11-14 1:53 ` Tom Tromey
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=m38wrn4ba7.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=schwab@suse.de \
/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