mirror/binutils-gdb
2
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2024-12-27 04:52:05 +08:00
Code Issues Packages Projects Releases Wiki Activity
bbe1eca622
binutils-gdb/binutils/testsuite/binutils-all/aarch64/in-order.d

29 lines
615 B
D
Raw Normal View History

AArch64: Fix AArch64 disassembler mapping symbol search My previous patch for AArch64 was not enough to catch all the cases where disassembling an out-of-order section could go wrong. It had missed the case DATA sections could be incorrectly disassembled as TEXT. Out of order here refers to an object file where sections are not listed in a monotonic increasing VMA order. The ELF ABI for AArch64 [1] specifies the following for mapping symbols: 1) A text section must always have a corresponding mapping symbol at it's start. 2) Data sections do not require any mapping symbols. 3) The range of a mapping symbol extends from the address it starts on up to the next mapping symbol (exclusive) or section end (inclusive). However there is no defined order between a symbol and it's corresponding mapping symbol in the symbol table. This means that while in general we look up for a corresponding mapping symbol, we have to make at least one check of the symbol below the address being disassembled. When disassembling different PCs within the same section, the search for mapping symbol can be cached somewhat. We know that the mapping symbol corresponding to the current PC is either the previous one used, or one at the same address as the current PC. However this optimization and mapping symbol search must stop as soon as we reach the end or start of the section. Furthermore if we're only disassembling a part of a section, the search is a allowed to search further than the current chunk, but is not allowed to search past it (The mapping symbol if there, must be at the same address, so in practice we usually stop at PC+4). lastly, since only data sections don't require a mapping symbol the default mapping type should be DATA and not INSN as previously defined, however if the binary has had all its symbols stripped than this isn't very useful. To fix this we determine the default based on the section flags. This will allow the disassembler to be more useful on stripped binaries. If there is no section than we assume you to be disassembling INSN. [1] https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4#aaelf64-section4-5-4 binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: New test. * testsuite/binutils-all/aarch64/out-of-order.d: Disassemble data as well. opcodes/ChangeLog: * aarch64-dis.c (print_insn_aarch64): Update the mapping symbol search order.
2019-03-25 20:12:03 +08:00
#PROG: objcopy
#source: out-of-order.s
#ld: -e v1 -Ttext-segment=0x400000
#objdump: -d
#name: Check if disassembler can handle sections in default order
.*: +file format .*aarch64.*
Disassembly of section \.func1:
AArch64/Arm: Update testcases fixing endiannes and linux targets This fixes the testcases that are failing due to my recent patch. It turns out that the start address across baremetal and linux builds isn't entirely predictable without a linker script. Since the address themselves are not the important thing I am ignoring them now. Secondly I was encoding data using .word using non 0 values, however because .word is subjected to endiannes these non-zero values under big-endian happen to fall into the encoding space of instructions which changes the disassembly. Using 0 fixes this problem and the purpose of the test still holds, though objdump will dump ... for data only sections, which is ok as the data/insn mixed sections will test the patch. The ARM Attributes sections is not important and is ignored. binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order-all.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.s: Likewise. * testsuite/binutils-all/arm/in-order-all.d: Likewise. * testsuite/binutils-all/arm/in-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order-all.d: Likewise. * testsuite/binutils-all/arm/out-of-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order.s: Likewise.
2019-03-27 00:46:42 +08:00
.+ <v1>:
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 00000000 \.word 0x00000000
AArch64: Fix AArch64 disassembler mapping symbol search My previous patch for AArch64 was not enough to catch all the cases where disassembling an out-of-order section could go wrong. It had missed the case DATA sections could be incorrectly disassembled as TEXT. Out of order here refers to an object file where sections are not listed in a monotonic increasing VMA order. The ELF ABI for AArch64 [1] specifies the following for mapping symbols: 1) A text section must always have a corresponding mapping symbol at it's start. 2) Data sections do not require any mapping symbols. 3) The range of a mapping symbol extends from the address it starts on up to the next mapping symbol (exclusive) or section end (inclusive). However there is no defined order between a symbol and it's corresponding mapping symbol in the symbol table. This means that while in general we look up for a corresponding mapping symbol, we have to make at least one check of the symbol below the address being disassembled. When disassembling different PCs within the same section, the search for mapping symbol can be cached somewhat. We know that the mapping symbol corresponding to the current PC is either the previous one used, or one at the same address as the current PC. However this optimization and mapping symbol search must stop as soon as we reach the end or start of the section. Furthermore if we're only disassembling a part of a section, the search is a allowed to search further than the current chunk, but is not allowed to search past it (The mapping symbol if there, must be at the same address, so in practice we usually stop at PC+4). lastly, since only data sections don't require a mapping symbol the default mapping type should be DATA and not INSN as previously defined, however if the binary has had all its symbols stripped than this isn't very useful. To fix this we determine the default based on the section flags. This will allow the disassembler to be more useful on stripped binaries. If there is no section than we assume you to be disassembling INSN. [1] https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4#aaelf64-section4-5-4 binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: New test. * testsuite/binutils-all/aarch64/out-of-order.d: Disassemble data as well. opcodes/ChangeLog: * aarch64-dis.c (print_insn_aarch64): Update the mapping symbol search order.
2019-03-25 20:12:03 +08:00
Disassembly of section .func2:
AArch64/Arm: Update testcases fixing endiannes and linux targets This fixes the testcases that are failing due to my recent patch. It turns out that the start address across baremetal and linux builds isn't entirely predictable without a linker script. Since the address themselves are not the important thing I am ignoring them now. Secondly I was encoding data using .word using non 0 values, however because .word is subjected to endiannes these non-zero values under big-endian happen to fall into the encoding space of instructions which changes the disassembly. Using 0 fixes this problem and the purpose of the test still holds, though objdump will dump ... for data only sections, which is ok as the data/insn mixed sections will test the patch. The ARM Attributes sections is not important and is ignored. binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order-all.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.s: Likewise. * testsuite/binutils-all/arm/in-order-all.d: Likewise. * testsuite/binutils-all/arm/in-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order-all.d: Likewise. * testsuite/binutils-all/arm/out-of-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order.s: Likewise.
2019-03-27 00:46:42 +08:00
.+ <\.func2>:
[^:]+: 8b010000 add x0, x0, x1
AArch64: Fix AArch64 disassembler mapping symbol search My previous patch for AArch64 was not enough to catch all the cases where disassembling an out-of-order section could go wrong. It had missed the case DATA sections could be incorrectly disassembled as TEXT. Out of order here refers to an object file where sections are not listed in a monotonic increasing VMA order. The ELF ABI for AArch64 [1] specifies the following for mapping symbols: 1) A text section must always have a corresponding mapping symbol at it's start. 2) Data sections do not require any mapping symbols. 3) The range of a mapping symbol extends from the address it starts on up to the next mapping symbol (exclusive) or section end (inclusive). However there is no defined order between a symbol and it's corresponding mapping symbol in the symbol table. This means that while in general we look up for a corresponding mapping symbol, we have to make at least one check of the symbol below the address being disassembled. When disassembling different PCs within the same section, the search for mapping symbol can be cached somewhat. We know that the mapping symbol corresponding to the current PC is either the previous one used, or one at the same address as the current PC. However this optimization and mapping symbol search must stop as soon as we reach the end or start of the section. Furthermore if we're only disassembling a part of a section, the search is a allowed to search further than the current chunk, but is not allowed to search past it (The mapping symbol if there, must be at the same address, so in practice we usually stop at PC+4). lastly, since only data sections don't require a mapping symbol the default mapping type should be DATA and not INSN as previously defined, however if the binary has had all its symbols stripped than this isn't very useful. To fix this we determine the default based on the section flags. This will allow the disassembler to be more useful on stripped binaries. If there is no section than we assume you to be disassembling INSN. [1] https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4#aaelf64-section4-5-4 binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: New test. * testsuite/binutils-all/aarch64/out-of-order.d: Disassemble data as well. opcodes/ChangeLog: * aarch64-dis.c (print_insn_aarch64): Update the mapping symbol search order.
2019-03-25 20:12:03 +08:00
Disassembly of section \.func3:
AArch64/Arm: Update testcases fixing endiannes and linux targets This fixes the testcases that are failing due to my recent patch. It turns out that the start address across baremetal and linux builds isn't entirely predictable without a linker script. Since the address themselves are not the important thing I am ignoring them now. Secondly I was encoding data using .word using non 0 values, however because .word is subjected to endiannes these non-zero values under big-endian happen to fall into the encoding space of instructions which changes the disassembly. Using 0 fixes this problem and the purpose of the test still holds, though objdump will dump ... for data only sections, which is ok as the data/insn mixed sections will test the patch. The ARM Attributes sections is not important and is ignored. binutils/ChangeLog: * testsuite/binutils-all/aarch64/in-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order-all.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.d: Likewise. * testsuite/binutils-all/aarch64/out-of-order.s: Likewise. * testsuite/binutils-all/arm/in-order-all.d: Likewise. * testsuite/binutils-all/arm/in-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order-all.d: Likewise. * testsuite/binutils-all/arm/out-of-order.d: Likewise. * testsuite/binutils-all/arm/out-of-order.s: Likewise.
2019-03-27 00:46:42 +08:00
.+ <\.func3>:
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 8b010000 add x0, x0, x1
[^:]+: 00000000 \.word 0x00000000
Reference in New Issue Copy Permalink