Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



  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