From: Nick Clifton <nickc@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly
Date: Tue, 25 Nov 2003 12:25:00 -0000 [thread overview]
Message-ID: <m3vfp8zlho.fsf@redhat.com> (raw)
In-Reply-To: <3FBA4581.1080904@redhat.com> (Andrew Cagney's message of "Tue, 18 Nov 2003 11:14:57 -0500")
Hi Andrew,
> Hmm, what information do those mapping symbols provide? Dig dig (from
> tc-arm.c) ...
[snip]
> So GDB and objdump both need this information?
Well yes and no...
> How does objdump handle all this?
Apart from a hack to objdump to skip the mapping symbols when
displaying disassembly it does not use them.
Objdump (and gdb) both have perfectly adequate mechanisms for
distinguishing between code and data and between ARM and THUMB
instructions, so they do not need the mapping symbols.
The code to support mapping symbols in GAS was developed by ARM and I
accepted it because these symbols are required by the ARM ELF
specification. [I believe that where possible, binutils should
attempt to follow all appropriate standards and specifications]. Note
- the patch is not a complete implementation of the specification
since the linker ought to generate these mapping symbols for its
arm<->thumb calling stubs. Currently this has not been implemented.
So basically the mapping symbols are a distraction which gdb ought to
be able to ignore. (Or use if it feels so minded, although as I say,
they are not fully implemented yet).
> - should there be a BFD method that lets GDB better identify a user
> visible [minimal] symbol (gdb's elf reader currently contains what
> can only be described as heuristics).
Yes - this would be a much cleaner way of handling this situation, and
presumably similar situations for other architectures which have
system type symbols which users are not supposed to see.
> - should there be a BFD method that, given an address and symbol
> table, indicates the relevant ISA/ABI?
Not sure. Having such a method would be a good idea, but I am not
sure if it belongs in BFD or in OPCODES. (Since opcodes already has
other disassembler related stuff).
> - or even just have BFD export name->addr and addr->name methods?
It already exports the bfd_asymbol_value() macro which can do
name->addr translation and the _bfd_find_nearest_line() function which
can do addr->name translation. (Although it does not return a symbol
pointer). Were you thinking of these or something else ?
Cheers
Nick
next prev parent reply other threads:[~2003-11-25 12:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-13 14:29 Nick Clifton
2003-11-13 14:45 ` Richard Earnshaw
2003-11-13 15:20 ` Daniel Jacobowitz
2004-01-14 23:42 ` Daniel Jacobowitz
2004-01-20 13:23 ` Nick Clifton
2003-11-18 16:15 ` Andrew Cagney
2003-11-18 16:45 ` Richard Earnshaw
2003-11-18 17:20 ` Andrew Cagney
2003-11-18 17:29 ` Richard Earnshaw
2003-11-18 17:41 ` Andrew Cagney
2003-11-18 19:55 ` Nick Clifton
2003-11-25 12:25 ` Nick Clifton [this message]
2003-11-25 12:34 ` Richard Earnshaw
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=m3vfp8zlho.fsf@redhat.com \
--to=nickc@redhat.com \
--cc=ac131313@redhat.com \
--cc=binutils@sources.redhat.com \
--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