From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa/remote] Reread symbols on 'target remote'
Date: Tue, 23 Mar 2004 16:42:00 -0000 [thread overview]
Message-ID: <406068DB.30007@gnu.org> (raw)
In-Reply-To: <20040323155049.GA21830@nevyn.them.org>
>>Well attach is more messed up than that. It might load the symbol table
>>> (if it isn't already loaded and can be determined from /proc). Should
>>> attach instead always load the symbol table, prefering what is provided
>>> by the executable?
>
>
> If I'm reading you right - then I think the answer is yes. What's your
> opinion on the patch below? If there is no exec file, then attempt to
> determine one from target_pid_to_exec_file. Otherwise, attempt to
> reread the exec file.
I was thinking of something more agressive:
if target (via /proc) can identify exec file
switch to target's exec file, load
else if exec file known
load
else
hope the user knows what they are doing
fi
which is different to the current logic like:
if exec file known
do nothing
else if target (via /proc) can identify exec file
switch to target's exec file, load
else
hope ...
fi
however yes, at least (per your patch) always loading the symbols is a
good first step.
(this goes back to earlier posts where we need to overaul the target
stack so that multiple instances are available)
Andrew
next prev parent reply other threads:[~2004-03-23 16:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-28 17:39 Daniel Jacobowitz
2004-03-05 5:31 ` Andrew Cagney
2004-03-06 23:54 ` Daniel Jacobowitz
2004-03-17 15:16 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-17 16:51 ` Daniel Jacobowitz
2004-03-22 22:28 ` Andrew Cagney
2004-03-23 15:50 ` Daniel Jacobowitz
2004-03-23 16:42 ` Andrew Cagney [this message]
2004-03-23 16:47 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Andrew Cagney
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=406068DB.30007@gnu.org \
--to=cagney@gnu.org \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.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