Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Koning <pkoning@equallogic.com>
To: gdb@sources.redhat.com
Subject: Looking for a gdb function to handle alias addresses
Date: Tue, 30 Dec 2003 22:19:00 -0000	[thread overview]
Message-ID: <16369.64013.161868.574183@gargle.gargle.HOWL> (raw)

Gentlepeople,

I'm working on a kernel dump analyzer integrated with gdb (similar to
the corefile support -- but with a pile of added wrinkles many of
which are specific to our particular platform).

One thing we run into from time to time is that there are several
legal addresses for the same object.  The target is MIPS-based, so an
obvious one is that a KSEG1 address (0xa0000000-0xbfffffff) aliases a
KSEG0 address (KSEG1 - 0x02000000).  Similarly, in MIPS64 there are
64-bit addresses of various forms that also alias, sometimes in more
complex ways than simply a numeric bias.

The ELF image of course has its symbols associated with one of these
addresses, typically the KSEG0 address.  As a result, when I'm dealing
with an alias address, the mapping of address to symbol doesn't work
right.  It's easy to get the right data from the dump file, but for
commands like "bt" to work, the symbol references have to come out
right. 

So... is there a standard gdb hook (say, part of the gdbarch
machinery) that is supposed to take an alias address and map it to the
"canonical" form which is the one expected to be found in the symtab?

I thought of tweaking gdbarch_frame_saved_pc, but then I end up with
false (numeric) addresses showing up in "bt" -- the canonical ones
rather than the ones that are really in the call stack.

Is there a function that's called at a later spot, so I can get the
raw addresses in the callstack and yet have them resolved to symbols
correctly?  Similarly, would that allow things like "disassemble
<alias>" to work with the symbol names "correctly" shown in the
disassembly output?

If this doesn't currently exist, could anyone offer hints as to where
such a beast could be added (and what form, roughly, it should take)?

Thanks,
	paul


             reply	other threads:[~2003-12-30 22:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-30 22:19 Paul Koning [this message]
2003-12-30 23:00 ` Daniel Jacobowitz
2003-12-31 15:26   ` Paul Koning
2003-12-31 16:37     ` Daniel Jacobowitz
2003-12-31 16:53       ` Paul Koning
2003-12-31 17:36 ` Andrew Cagney
2003-12-31 18:31   ` Paul Koning

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=16369.64013.161868.574183@gargle.gargle.HOWL \
    --to=pkoning@equallogic.com \
    --cc=gdb@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