mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 20:23:11 +01:00
0ba63b8a56
I've noticed that it is not convenient to create YAMLs from
binaries (using obj2yaml) that have to be test cases for obj2yaml
later (after applying yaml2obj).
The problem, for example is that obj2yaml emits "DynamicSymbols:"
key instead of .dynsym. It also does not create .dynstr.
And when a YAML document without explicitly defined .dynsym/.dynstr
is given to yaml2obj, we have issues:
1) These sections are placed after non-allocatable sections (I've fixed it in D74756).
2) They have VA == 0. User needs create descriptions for such sections explicitly manually
to set a VA.
This patch addresses (2). I suggest to let yaml2obj assign virtual addresses by itself.
It makes an output binary to be much closer to "normal" ELF.
(It is still possible to use "Address: 0x0" for a section to get the original behavior
if it is needed)
Differential revision: https://reviews.llvm.org/D74764
134 lines
4.5 KiB
YAML
134 lines
4.5 KiB
YAML
## Check how obj2yaml produces SHT_GNU_HASH section descriptions.
|
|
|
|
## Check that obj2yaml uses "Header", "BloomFilter", "HashBuckets" and "HashValues"
|
|
## tags to describe a SHT_GNU_HASH section when it has content of a correct size.
|
|
|
|
# RUN: yaml2obj --docnum=1 %s -o %t1
|
|
# RUN: obj2yaml %t1 | FileCheck %s --check-prefix=FIELDS
|
|
|
|
# FIELDS: - Name: .gnu.hash
|
|
# FIELDS-NEXT: Type: SHT_GNU_HASH
|
|
# FIELDS-NEXT: Flags: [ SHF_ALLOC ]
|
|
# FIELDS-NEXT: Header:
|
|
# FIELDS-NEXT: SymNdx: 0x00000001
|
|
# FIELDS-NEXT: Shift2: 0x00000002
|
|
# FIELDS-NEXT: BloomFilter: [ 0x0000000000000003, 0x0000000000000004 ]
|
|
# FIELDS-NEXT: HashBuckets: [ 0x00000005, 0x00000006, 0x00000007 ]
|
|
# FIELDS-NEXT: HashValues: [ 0x00000008, 0x00000009, 0x0000000A, 0x0000000B ]
|
|
|
|
--- !ELF
|
|
FileHeader:
|
|
Class: ELFCLASS32
|
|
Data: ELFDATA2LSB
|
|
Type: ET_DYN
|
|
Machine: EM_386
|
|
Sections:
|
|
- Name: .gnu.hash
|
|
Type: SHT_GNU_HASH
|
|
Flags: [ SHF_ALLOC ]
|
|
Header:
|
|
SymNdx: 0x1
|
|
Shift2: 0x2
|
|
BloomFilter: [0x3, 0x4]
|
|
HashBuckets: [0x5, 0x6, 0x7]
|
|
HashValues: [0x8, 0x9, 0xA, 0xB]
|
|
|
|
## Check how we handle broken cases.
|
|
|
|
# RUN: yaml2obj --docnum=2 %s -o %t2
|
|
# RUN: obj2yaml %t2 | FileCheck %s --check-prefix=INVALID
|
|
|
|
# INVALID: - Name: .gnu.hash.tooshort
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Flags: [ SHF_ALLOC ]
|
|
# INVALID-NEXT: Content: 112233445566778899AABBCCDDEEFF
|
|
# INVALID-NEXT: - Name: .gnu.hash.empty
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Flags: [ SHF_ALLOC ]
|
|
# INVALID-NEXT: Address: 0x000000000000000F
|
|
# INVALID-NEXT: Header:
|
|
# INVALID-NEXT: SymNdx: 0x00000000
|
|
# INVALID-NEXT: Shift2: 0x00000000
|
|
# INVALID-NEXT: BloomFilter: [ ]
|
|
# INVALID-NEXT: HashBuckets: [ ]
|
|
# INVALID-NEXT: HashValues: [ ]
|
|
# INVALID-NEXT: - Name: .gnu.hash.broken.maskwords
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Content: '00000000000000000100000000000000'
|
|
# INVALID-NEXT: - Name: .gnu.hash.broken.nbuckets
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Content: '01000000000000000000000000000000'
|
|
# INVALID-NEXT: - Name: .gnu.hash.hashvalues.ok
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Header:
|
|
# INVALID-NEXT: SymNdx: 0x00000000
|
|
# INVALID-NEXT: Shift2: 0x00000000
|
|
# INVALID-NEXT: BloomFilter: [ ]
|
|
# INVALID-NEXT: HashBuckets: [ ]
|
|
# INVALID-NEXT: HashValues: [ 0x00000000 ]
|
|
# INVALID-NEXT: - Name: .gnu.hash.hashvalues.fail
|
|
# INVALID-NEXT: Type: SHT_GNU_HASH
|
|
# INVALID-NEXT: Content: '000000000000000000000000000000000000000000'
|
|
|
|
--- !ELF
|
|
FileHeader:
|
|
Class: ELFCLASS32
|
|
Data: ELFDATA2LSB
|
|
Type: ET_DYN
|
|
Machine: EM_386
|
|
Sections:
|
|
## Case 1: Content is less than 16 bytes.
|
|
- Name: .gnu.hash.tooshort
|
|
Type: SHT_GNU_HASH
|
|
Flags: [ SHF_ALLOC ]
|
|
Content: "112233445566778899AABBCCDDEEFF"
|
|
## Case2: Check how we handle a fully empty hash section.
|
|
## It is almost technically valid, but uncommon. Modern linkers
|
|
## create at least one entry in Bloom filter if they want to disable it.
|
|
## Also, the dynamic symbol table has a null entry and having SymNdx = 0
|
|
## here is at least strange.
|
|
- Name: .gnu.hash.empty
|
|
Type: SHT_GNU_HASH
|
|
Flags: [ SHF_ALLOC ]
|
|
Header:
|
|
SymNdx: 0x0
|
|
Shift2: 0x0
|
|
MaskWords: 0x0
|
|
NBuckets: 0x0
|
|
BloomFilter: []
|
|
HashBuckets: []
|
|
HashValues: []
|
|
## Case 3: MaskWords field is broken: it says that the number of entries
|
|
## in the Bloom filter is 1, but the Bloom filter is empty.
|
|
- Name: .gnu.hash.broken.maskwords
|
|
Type: SHT_GNU_HASH
|
|
Header:
|
|
SymNdx: 0x0
|
|
Shift2: 0x0
|
|
MaskWords: 0x1
|
|
NBuckets: 0x0
|
|
BloomFilter: []
|
|
HashBuckets: []
|
|
HashValues: []
|
|
## Case 4: NBuckets field is broken, it says that the number of entries
|
|
## in the hash buckets is 1, but it is empty.
|
|
- Name: .gnu.hash.broken.nbuckets
|
|
Type: SHT_GNU_HASH
|
|
Header:
|
|
SymNdx: 0x0
|
|
Shift2: 0x0
|
|
MaskWords: 0x0
|
|
NBuckets: 0x1
|
|
BloomFilter: []
|
|
HashBuckets: []
|
|
HashValues: []
|
|
## Case 5: Check that we use the various properties to dump the data when it
|
|
## has a size that is a multiple of 4, but fallback to dumping the whole section
|
|
## using the "Content" property otherwise.
|
|
- Name: .gnu.hash.hashvalues.ok
|
|
Type: SHT_GNU_HASH
|
|
Content: "0000000000000000000000000000000000000000"
|
|
- Name: .gnu.hash.hashvalues.fail
|
|
Type: SHT_GNU_HASH
|
|
Content: "000000000000000000000000000000000000000000"
|