From: Julian Brown <julian@codesourcery.com>
To: Richard Earnshaw <rearnsha@gcc.gnu.org>
Cc: binutils@sources.redhat.com, julian@codesourcery.com
Subject: Re: [PATCH] Fix type and alignment of ARM/Thumb EABI mapping symbols
Date: Wed, 30 Mar 2005 15:31:00 -0000 [thread overview]
Message-ID: <4249C7E9.8000100@codesourcery.com> (raw)
In-Reply-To: <1112111047.12337.7.camel@pc960.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]
Richard Earnshaw wrote:
> On Sun, 2005-03-27 at 21:25, Julian Brown wrote:
>
>>Hi,
>>
>>This patch fixes two problems: the type of mapping symbols is made
>>STT_NOTYPE (from STT_FUNC or STT_OBJECT from ARM/Thumb or data
>>respectively), and the alignment is corrected to not have the low bit
>>set for Thumb mapping symbols, in accordance with the latest version of
>>the ARM AAELF spec.
>>
>>Unfortunately altering the symbol type to STT_NOTYPE for mapping symbols
>>affects the output of disassembly from objdump. $a and $t were
>>previously treated as functions. When objdump tried to find the closest
>>symbol for possibly-symbol-relative offsets previously, it found those
>>mapping symbols since compare_symbols places functions first in a sorted
>>version of the symbol table. They were then rejected by the
>>symbol_is_valid hook (arm_symbol_is_valid) from the disassemble_info
>>struct, and the section name was printed instead.
>>
>>When the type of mapping symbols is changed to STT_NOTYPE, they are no
>>longer placed first in the sorted symbol list, so another symbol is used
>>instead. This causes test regressions, e.g. a symbol-offset address
>>which was previously output as:
>>
>> bl 8224 <.text-0xc>
>>
>>was output instead as:
>>
>> bl 8224 <_start-0xc>
>>
>>In the interest of preserving existing behaviour, I have fixed this by
>>adding a new disassemble_info hook which allows the symbol table used
>>for disassembly to have a target-specific hook for altering each symbol
>>(or remove it) in the remove_useless_symbols function. This sets the
>>BSF_FUNCTION flag for mapping symbols, which makes things behave the way
>>they used to, and possibly provides useful functionality for other
>>platforms as well.
>>
>>It may be better to just change the expected test output instead. Thoughts?
>>
>
>
> I think the tests should be fixed. Other targets (those that don't have
> mapping symbols) would almost certainly output _start in the example
> above, so the existing behaviour should be considered undesirable at
> best and probably just buggy.
>
> That should allow you to simplify your patch so that you don't need to
> touch MI parts.
OK, this is a simpler version of the patch which alters the expected
test output instead (only ARM-specific code is now touched).
Tested with cross to arm-none-eabi and arm-none-symbianelf, and with all
targets on i686-pc-linux-gnu. OK to apply?
ChangeLog:
* bfd/elf32-arm.c (arm_elf_find_function): Include STT_NOTYPE in test
for mapping symbols.
* gas/config/tc-arm.c (mapping_state): Update documentation in
function comment. Change type of mapping symbols to BSF_NO_TYPE.
(is_arm_mapping_symbol_name): New function.
(arm_adjust_symtab): Don't change type of mapping symbols here.
* gas/testsuite/gas/arm/mapping.d: Update expected output.
* ld/testsuite/ld-arm/arm-app-abs32.d: Likewise.
* ld/testsuite/ld-arm/arm-app.d: Likewise.
* ld/testsuite/ld-arm/mixed-app.d: Likewise.
[-- Attachment #2: patch-4 --]
[-- Type: text/plain, Size: 15332 bytes --]
? bfd/doc/bfd.info
? bfd/doc/bfd.info-1
? gas/doc/as.info
? gas/doc/as.info-1
Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.28
diff -c -p -r1.28 elf32-arm.c
*** bfd/elf32-arm.c 29 Mar 2005 16:54:19 -0000 1.28
--- bfd/elf32-arm.c 29 Mar 2005 21:13:42 -0000
*************** arm_elf_find_function (bfd * abf
*** 4754,4765 ****
break;
case STT_FUNC:
case STT_ARM_TFUNC:
/* Skip $a and $t symbols. */
if ((q->symbol.flags & BSF_LOCAL)
&& is_arm_mapping_symbol_name (q->symbol.name))
continue;
/* Fall through. */
- case STT_NOTYPE:
if (bfd_get_section (&q->symbol) == section
&& q->symbol.value >= low_func
&& q->symbol.value <= offset)
--- 4754,4765 ----
break;
case STT_FUNC:
case STT_ARM_TFUNC:
+ case STT_NOTYPE:
/* Skip $a and $t symbols. */
if ((q->symbol.flags & BSF_LOCAL)
&& is_arm_mapping_symbol_name (q->symbol.name))
continue;
/* Fall through. */
if (bfd_get_section (&q->symbol) == section
&& q->symbol.value >= low_func
&& q->symbol.value <= offset)
Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.199
diff -c -p -r1.199 tc-arm.c
*** gas/config/tc-arm.c 29 Mar 2005 16:54:21 -0000 1.199
--- gas/config/tc-arm.c 29 Mar 2005 21:13:47 -0000
*************** validate_offset_imm (unsigned int val, i
*** 1243,1316 ****
\f
#ifdef OBJ_ELF
/* This code is to handle mapping symbols as defined in the ARM ELF spec.
! (This text is taken from version B-02 of the spec):
! 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
--- 1243,1308 ----
\f
#ifdef OBJ_ELF
/* This code is to handle mapping symbols as defined in the ARM ELF spec.
! (This text is taken from version 0.62 RC 2 of the spec):
! 4.5.7 Mapping symbols
! A section of an 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, and potentially other tools, need to map images correctly (for
! example, to support byte swapping to produce a BE-8 image from a BE-32
! object file). To support this, a number of symbols, termed mapping
! symbols appear in the symbol table to denote the start of a sequence of
! bytes of the appropriate type. All mapping symbols have type STT_NOTYPE
! and binding STB_LOCAL. The st_size field is unused and must be zero.
!
! The mapping symbols are defined in Table 4-6, Mapping symbols. It is an
! error for a relocation to reference a mapping symbol. Two forms of
! mapping symbol are supported:
!
! * a short form, that uses a dollar character and a single letter
! denoting the class. This form can be used when an object producer
! creates mapping symbols automatically, and minimizes symbol table
! space
!
! * a longer form, where the short form is extended with a period and
! then any sequence of characters that are legal for a symbol. This
! form can be used when assembler files have to be annotated manually
! and the assembler does not support multiple definitions of symbols.
!
! Table 4-6, Mapping symbols
!
! Name Meaning
!
! $a Start of a sequence of ARM instructions
! $a.<any...>
!
! $d Start of a sequence of data items (for example, a literal
! $d.<any...> pool)
!
! $t Start of a sequence of Thumb instructions
! $t.<any...>
!
! 4.5.7.1 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 the 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 section must
! have a mapping symbol defined at the beginning of the section; however,
! if the section contains only data then the mapping symbol may be omitted.
!
! 4.5.7.2 Absolute mapping symbols
!
! Mapping symbols are no-longer required for the absolute section. The
! equivalent information is now conveyed by the type of the absolute
! symbol.
Note - the Tagging symbols ($b, $f, $p $m) have been dropped from
the EABI (which is still under development), so they are not
*************** mapping_state (enum mstate state)
*** 1336,1350 ****
{
case MAP_DATA:
symname = "$d";
! type = BSF_OBJECT;
break;
case MAP_ARM:
symname = "$a";
! type = BSF_FUNCTION;
break;
case MAP_THUMB:
symname = "$t";
! type = BSF_FUNCTION;
break;
case MAP_UNDEFINED:
return;
--- 1328,1342 ----
{
case MAP_DATA:
symname = "$d";
! type = BSF_NO_FLAGS;
break;
case MAP_ARM:
symname = "$a";
! type = BSF_NO_FLAGS;
break;
case MAP_THUMB:
symname = "$t";
! type = BSF_NO_FLAGS;
break;
case MAP_UNDEFINED:
return;
*************** arm_frob_label (symbolS * sym)
*** 13678,13683 ****
--- 13670,13685 ----
}
}
+ /* Recognize short-form or long-form mapping symbol names. */
+
+ static bfd_boolean
+ is_arm_mapping_symbol_name (const char* name)
+ {
+ return name && name[0] == '$'
+ && (name[1] == 'a' || name[1] == 'd' || name[1] == 't')
+ && (name[2] == '\0' || name[2] == '.');
+ }
+
/* Adjust the symbol table. This marks Thumb symbols as distinct from
ARM ones. */
*************** arm_adjust_symtab (void)
*** 13738,13751 ****
elf_sym = elf_symbol (symbol_get_bfdsym (sym));
bind = ELF_ST_BIND (elf_sym->internal_elf_sym.st_info);
! /* If it's a .thumb_func, declare it as so,
! otherwise tag label as .code 16. */
! if (THUMB_IS_FUNC (sym))
! elf_sym->internal_elf_sym.st_info =
! ELF_ST_INFO (bind, STT_ARM_TFUNC);
! else
! elf_sym->internal_elf_sym.st_info =
! ELF_ST_INFO (bind, STT_ARM_16BIT);
}
}
#endif
--- 13740,13756 ----
elf_sym = elf_symbol (symbol_get_bfdsym (sym));
bind = ELF_ST_BIND (elf_sym->internal_elf_sym.st_info);
! if (!is_arm_mapping_symbol_name (elf_sym->symbol.name))
! {
! /* If it's a .thumb_func, declare it as so,
! otherwise tag label as .code 16. */
! if (THUMB_IS_FUNC (sym))
! elf_sym->internal_elf_sym.st_info =
! ELF_ST_INFO (bind, STT_ARM_TFUNC);
! else
! elf_sym->internal_elf_sym.st_info =
! ELF_ST_INFO (bind, STT_ARM_16BIT);
! }
}
}
#endif
Index: gas/testsuite/gas/arm/mapping.d
===================================================================
RCS file: /cvs/src/src/gas/testsuite/gas/arm/mapping.d,v
retrieving revision 1.4
diff -c -p -r1.4 mapping.d
*** gas/testsuite/gas/arm/mapping.d 11 Dec 2004 04:32:36 -0000 1.4
--- gas/testsuite/gas/arm/mapping.d 29 Mar 2005 21:13:47 -0000
*************** SYMBOL TABLE:
*** 9,18 ****
0+00 l d .text 0+0 (|.text)
0+00 l d .data 0+0 (|.data)
0+00 l d .bss 0+0 (|.bss)
! 0+00 l F .text 0+0 \$a
! 0+08 l F .text 0+0 \$t
! 0+00 l O .data 0+0 \$d
0+00 l d foo 0+0 (|foo)
! 0+00 l F foo 0+0 \$t
0+00 g .text 0+0 mapping
0+08 g F .text 0+0 thumb_mapping
--- 9,18 ----
0+00 l d .text 0+0 (|.text)
0+00 l d .data 0+0 (|.data)
0+00 l d .bss 0+0 (|.bss)
! 0+00 l .text 0+0 \$a
! 0+08 l .text 0+0 \$t
! 0+00 l .data 0+0 \$d
0+00 l d foo 0+0 (|foo)
! 0+00 l foo 0+0 \$t
0+00 g .text 0+0 mapping
0+08 g F .text 0+0 thumb_mapping
Index: ld/testsuite/ld-arm/arm-app-abs32.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/arm-app-abs32.d,v
retrieving revision 1.2
diff -c -p -r1.2 arm-app-abs32.d
*** ld/testsuite/ld-arm/arm-app-abs32.d 17 Nov 2004 17:50:27 -0000 1.2
--- ld/testsuite/ld-arm/arm-app-abs32.d 29 Mar 2005 21:14:01 -0000
*************** Disassembly of section .plt:
*** 8,14 ****
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <.plt\+0x10>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .* .*
--- 8,14 ----
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <_start-0x10>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .* .*
Index: ld/testsuite/ld-arm/arm-app.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/arm-app.d,v
retrieving revision 1.2
diff -c -p -r1.2 arm-app.d
*** ld/testsuite/ld-arm/arm-app.d 17 Nov 2004 17:50:27 -0000 1.2
--- ld/testsuite/ld-arm/arm-app.d 29 Mar 2005 21:14:01 -0000
*************** Disassembly of section .plt:
*** 8,14 ****
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <.plt\+0x10>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .*
--- 8,14 ----
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <_start-0x10>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .*
*************** Disassembly of section .text:
*** 27,33 ****
.* <app_func>:
.*: e1a0c00d mov ip, sp
.*: e92dd800 stmdb sp!, {fp, ip, lr, pc}
! .*: ebfffff4 bl .* <.text-0xc>
.*: e89d6800 ldmia sp, {fp, sp, lr}
.*: e12fff1e bx lr
--- 27,33 ----
.* <app_func>:
.*: e1a0c00d mov ip, sp
.*: e92dd800 stmdb sp!, {fp, ip, lr, pc}
! .*: ebfffff4 bl .* <_start-0xc>
.*: e89d6800 ldmia sp, {fp, sp, lr}
.*: e12fff1e bx lr
Index: ld/testsuite/ld-arm/mixed-app.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/mixed-app.d,v
retrieving revision 1.1
diff -c -p -r1.1 mixed-app.d
*** ld/testsuite/ld-arm/mixed-app.d 17 Nov 2004 17:50:27 -0000 1.1
--- ld/testsuite/ld-arm/mixed-app.d 29 Mar 2005 21:14:01 -0000
*************** Disassembly of section .plt:
*** 8,14 ****
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <.plt\+0x10>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .*
--- 8,14 ----
.* <.plt>:
.*: e52de004 str lr, \[sp, #-4\]!
! .*: e59fe004 ldr lr, \[pc, #4\] ; .* <_start-0x2c>
.*: e08fe00e add lr, pc, lr
.*: e5bef008 ldr pc, \[lr, #8\]!
.*: .*
*************** Disassembly of section .text:
*** 34,40 ****
.* <app_func>:
.*: e1a0c00d mov ip, sp
.*: e92dd800 stmdb sp!, {fp, ip, lr, pc}
! .*: ebffffe. bl .* <.text-0x..>
.*: e89d6800 ldmia sp, {fp, sp, lr}
.*: e12fff1e bx lr
.*: e1a00000 nop \(mov r0,r0\)
--- 34,40 ----
.* <app_func>:
.*: e1a0c00d mov ip, sp
.*: e92dd800 stmdb sp!, {fp, ip, lr, pc}
! .*: ebffffe. bl .* <_start-0x..>
.*: e89d6800 ldmia sp, {fp, sp, lr}
.*: e12fff1e bx lr
.*: e1a00000 nop \(mov r0,r0\)
*************** Disassembly of section .text:
*** 49,55 ****
.* <app_tfunc>:
.*: b500 push {lr}
! .*: (ffc.f7ff|f7ffffc.) bl .* <.text-0x..>
.*: bd00 pop {pc}
.*: 4770 bx lr
.*: 46c0 nop \(mov r8, r8\)
--- 49,55 ----
.* <app_tfunc>:
.*: b500 push {lr}
! .*: (ffc.f7ff|f7ffffc.) bl .* <_start-0x..>
.*: bd00 pop {pc}
.*: 4770 bx lr
.*: 46c0 nop \(mov r8, r8\)
next prev parent reply other threads:[~2005-03-29 21:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-28 8:41 Julian Brown
2005-03-28 10:17 ` Daniel Jacobowitz
2005-03-28 10:36 ` Julian Brown
2005-03-29 16:54 ` Richard Earnshaw
2005-03-29 17:25 ` Daniel Jacobowitz
2005-03-30 15:31 ` Julian Brown [this message]
2005-03-30 17:05 ` Richard Earnshaw
2005-03-30 21:08 ` Paul Brook
2005-03-30 21:11 ` Julian Brown
2005-03-31 0:27 ` Richard Earnshaw
2005-03-31 0:34 ` Julian Brown
2005-03-31 0:58 ` Richard Earnshaw
2005-03-31 2:17 ` Julian Brown
2005-03-31 15:25 ` 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=4249C7E9.8000100@codesourcery.com \
--to=julian@codesourcery.com \
--cc=binutils@sources.redhat.com \
--cc=rearnsha@gcc.gnu.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).