From: Andrew Cagney <ac131313@redhat.com>
To: Nick Clifton <nickc@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, 18 Nov 2003 16:15:00 -0000 [thread overview]
Message-ID: <3FBA4581.1080904@redhat.com> (raw)
In-Reply-To: <m3he181gxc.fsf@redhat.com>
Nick,
> I have recently committed a patch to the arm-elf port of GAS which
> causes it to generate special mapping symbols as required by the ARM
> ELF spec. Unfortunately this now means that when GDB shows a
> disassembly it can select one of the mapping symbols instead of the
> proper function name symbol.
(GDB has minimal (=== asymbol), partial and full symbols. IN the below
"symbol" refers to the minimal symbol.)
Hmm, what information do those mapping symbols provide? Dig dig (from
tc-arm.c) ...
4.4.7 Mapping and tagging symbols
A section of an ARM ELF file can contain a mixture of ARM code,
Thumb code, and data. There are inline transitions between code
and data at literal pool boundaries. There can also be inline
transitions between ARM code and Thumb code, for example in
ARM-Thumb inter-working veneers. Linkers, machine-level
debuggers, profiling tools, and disassembly tools need to map
images accurately. For example, setting an ARM breakpoint on a
Thumb location, or in a literal pool, can crash the program
being debugged, ruining the debugging session.
ARM ELF entities are mapped (see section 4.4.7.1 below) and
tagged (see section 4.4.7.2 below) using local symbols (with
binding STB_LOCAL). To assist consumers, mapping and tagging
symbols should be collated first in the symbol table, before
other symbols with binding STB_LOCAL.
To allow properly collated mapping and tagging symbols to be
skipped by consumers that have no interest in them, the first
such symbol should have the name $m and its st_value field equal
to the total number of mapping and tagging symbols (including
the $m) in the symbol table.
4.4.7.1 Mapping symbols
$a Labels the first byte of a sequence of ARM instructions.
Its type is STT_FUNC.
$d Labels the first byte of a sequence of data items.
Its type is STT_OBJECT.
$t Labels the first byte of a sequence of Thumb instructions.
Its type is STT_FUNC.
This list of mapping symbols may be extended in the future.
Section-relative mapping symbols
Mapping symbols defined in a section define a sequence of
half-open address intervals that cover the address range of the
section. Each interval starts at the address defined by a
mapping symbol, and continues up to, but not including, the
address defined by the next (in address order) mapping symbol or
the end of the section. A corollary is that there must be a
mapping symbol defined at the beginning of each section.
Consumers can ignore the size of a section-relative mapping
symbol. Producers can set it to 0.
Absolute mapping symbols
Because of the need to crystallize a Thumb address with the
Thumb-bit set, absolute symbol of type STT_FUNC (symbols of type
STT_FUNC defined in section SHN_ABS) need to be mapped with $a
or $t.
The extent of a mapping symbol defined in SHN_ABS is [st_value,
st_value + st_size), or [st_value, st_value + 1) if st_size = 0,
where [x, y) denotes the half-open address range from x,
inclusive, to y, exclusive.
In the absence of a mapping symbol, a consumer can interpret a
function symbol with an odd value as the Thumb code address
obtained by clearing the least significant bit of the
value. This interpretation is deprecated, and it may not work in
the future.
Note - the Tagging symbols ($b, $f, $p $m) have been dropped from
the EABI (which is still under development), so they are not
implemented here. */
So GDB and objdump both need this information? How does objdump handle
all this?
- should there be a BFD method that lets GDB better identify a user
visibile [minimal] symbol (gdb's elf reader currently contains what can
only be described as heuristics).
- should there be a BFD method that, given an address and symbol table,
indicates the relevant ISA/ABI?
- or even just have BFD export name->addr and addr->name methods?
Andrew
next prev parent reply other threads:[~2003-11-18 16:15 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 [this message]
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
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=3FBA4581.1080904@redhat.com \
--to=ac131313@redhat.com \
--cc=binutils@sources.redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=nickc@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