llvm-project/llvm/test/ObjectYAML/MachO/DWARF-debug_info.yaml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

911 lines
29 KiB
YAML
Raw Normal View History

## This file contains test cases for generating a DAWRFv4 .debug_info
## section in object files from the DWARF entry of Mach-O YAML inputs.
## a) Test that yaml2obj emits a DWARF32 .debug_info sections and obj2yaml
## converts it back.
# RUN: yaml2obj --docnum=1 %s | obj2yaml | FileCheck %s --check-prefix=DWARF32
--- !mach-o
FileHeader:
magic: 0xFEEDFACF
cputype: 0x01000007
cpusubtype: 0x00000003
filetype: 0x0000000A
ncmds: 5
sizeofcmds: 1800
flags: 0x00000000
reserved: 0x00000000
LoadCommands:
- cmd: LC_SEGMENT_64
cmdsize: 72
segname: __PAGEZERO
vmaddr: 0
vmsize: 4294967296
fileoff: 0
filesize: 0
maxprot: 0
initprot: 0
nsects: 0
flags: 0
- cmd: LC_SEGMENT_64
cmdsize: 472
segname: __TEXT
vmaddr: 4294967296
vmsize: 4096
fileoff: 0
filesize: 0
maxprot: 7
initprot: 5
nsects: 5
flags: 0
Sections:
- sectname: __text
segname: __TEXT
addr: 0x0000000100000F50
size: 52
offset: 0x00000000
align: 4
reloff: 0x00000000
nreloc: 0
flags: 0x80000400
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __stubs
segname: __TEXT
addr: 0x0000000100000F84
size: 6
offset: 0x00000000
align: 1
reloff: 0x00000000
nreloc: 0
flags: 0x80000408
reserved1: 0x00000000
reserved2: 0x00000006
reserved3: 0x00000000
- sectname: __stub_helper
segname: __TEXT
addr: 0x0000000100000F8C
size: 26
offset: 0x00000000
align: 2
reloff: 0x00000000
nreloc: 0
flags: 0x80000400
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __cstring
segname: __TEXT
addr: 0x0000000100000FA6
size: 14
offset: 0x00000000
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000002
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __unwind_info
segname: __TEXT
addr: 0x0000000100000FB4
size: 72
offset: 0x00000000
align: 2
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- cmd: LC_SEGMENT_64
cmdsize: 232
segname: __DATA
vmaddr: 4294971392
vmsize: 4096
fileoff: 0
filesize: 0
maxprot: 7
initprot: 3
nsects: 2
flags: 0
Sections:
- sectname: __nl_symbol_ptr
segname: __DATA
addr: 0x0000000100001000
size: 16
offset: 0x00000000
align: 3
reloff: 0x00000000
nreloc: 0
flags: 0x00000006
reserved1: 0x00000001
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __la_symbol_ptr
segname: __DATA
addr: 0x0000000100001010
size: 8
offset: 0x00000000
align: 3
reloff: 0x00000000
nreloc: 0
flags: 0x00000007
reserved1: 0x00000003
reserved2: 0x00000000
reserved3: 0x00000000
- cmd: LC_SEGMENT_64
cmdsize: 72
segname: __LINKEDIT
vmaddr: 4294975488
vmsize: 4096
fileoff: 4096
filesize: 60
maxprot: 7
initprot: 1
nsects: 0
flags: 0
- cmd: LC_SEGMENT_64
cmdsize: 952
segname: __DWARF
vmaddr: 4294979584
vmsize: 4096
fileoff: 8192
filesize: 764
maxprot: 7
initprot: 3
nsects: 11
flags: 0
Sections:
- sectname: __debug_line
segname: __DWARF
addr: 0x0000000100003000
size: 69
offset: 0x00002000
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_pubnames
segname: __DWARF
addr: 0x0000000100003045
size: 27
offset: 0x00002045
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_pubtypes
segname: __DWARF
addr: 0x0000000100003060
size: 35
offset: 0x00002060
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_aranges
segname: __DWARF
addr: 0x0000000100003083
size: 48
offset: 0x00002083
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_info
segname: __DWARF
addr: 0x00000001000030B3
size: 121
offset: 0x000020B3
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_abbrev
segname: __DWARF
addr: 0x000000010000312C
size: 76
offset: 0x0000212C
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_str
segname: __DWARF
addr: 0x0000000100003178
size: 142
offset: 0x00002178
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __apple_names
segname: __DWARF
addr: 0x0000000100003206
size: 60
offset: 0x00002206
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __apple_namespac
segname: __DWARF
addr: 0x0000000100003242
size: 36
offset: 0x00002242
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __apple_types
segname: __DWARF
addr: 0x0000000100003266
size: 114
offset: 0x00002266
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __apple_objc
segname: __DWARF
addr: 0x00000001000032D8
size: 36
offset: 0x000022D8
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
LinkEditData:
NameList:
- n_strx: 2
n_type: 0x0F
n_sect: 1
n_desc: 16
n_value: 4294967296
- n_strx: 22
n_type: 0x0F
n_sect: 1
n_desc: 0
n_value: 4294971216
StringTable:
- ''
- ''
- __mh_execute_header
- _main
DWARF:
debug_abbrev:
- Table:
- Code: 0x00000001
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_yes
Attributes:
- Attribute: DW_AT_producer
Form: DW_FORM_strp
- Attribute: DW_AT_language
Form: DW_FORM_data2
- Attribute: DW_AT_name
Form: DW_FORM_strp
- Attribute: DW_AT_stmt_list
Form: DW_FORM_sec_offset
- Attribute: DW_AT_comp_dir
Form: DW_FORM_strp
- Attribute: DW_AT_low_pc
Form: DW_FORM_addr
- Attribute: DW_AT_high_pc
Form: DW_FORM_data4
- Code: 0x00000002
Tag: DW_TAG_subprogram
Children: DW_CHILDREN_yes
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_addr
- Attribute: DW_AT_high_pc
Form: DW_FORM_data4
- Attribute: DW_AT_frame_base
Form: DW_FORM_exprloc
- Attribute: DW_AT_name
Form: DW_FORM_strp
- Attribute: DW_AT_decl_file
Form: DW_FORM_data1
- Attribute: DW_AT_decl_line
Form: DW_FORM_data1
- Attribute: DW_AT_prototyped
Form: DW_FORM_flag_present
- Attribute: DW_AT_type
Form: DW_FORM_ref4
- Attribute: DW_AT_external
Form: DW_FORM_flag_present
- Code: 0x00000003
Tag: DW_TAG_formal_parameter
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_location
Form: DW_FORM_exprloc
- Attribute: DW_AT_name
Form: DW_FORM_strp
- Attribute: DW_AT_decl_file
Form: DW_FORM_data1
- Attribute: DW_AT_decl_line
Form: DW_FORM_data1
- Attribute: DW_AT_type
Form: DW_FORM_ref4
- Code: 0x00000004
Tag: DW_TAG_base_type
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_name
Form: DW_FORM_strp
- Attribute: DW_AT_encoding
Form: DW_FORM_data1
- Attribute: DW_AT_byte_size
Form: DW_FORM_data1
- Code: 0x00000005
Tag: DW_TAG_pointer_type
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_type
Form: DW_FORM_ref4
debug_aranges:
- Length: 44
Version: 2
CuOffset: 0
AddressSize: 8
SegmentSelectorSize: 0
Descriptors:
- Address: 0x0000000100000F50
Length: 52
debug_info:
- Length: 117
Version: 4
AbbrOffset: 0
AddrSize: 8
Entries:
- AbbrCode: 0x00000001
Values:
- Value: 0x0000000000000001
- Value: 0x000000000000000C
- Value: 0x0000000000000038
- Value: 0x0000000000000000
- Value: 0x0000000000000046
- Value: 0x0000000100000F50
- Value: 0x0000000000000034
- AbbrCode: 0x00000002
Values:
- Value: 0x0000000100000F50
- Value: 0x0000000000000034
- Value: 0x0000000000000001
BlockData:
- 0x56
- Value: 0x0000000000000076
- Value: 0x0000000000000001
- Value: 0x0000000000000003
- Value: 0x0000000000000001
- Value: 0x0000000000000060
- Value: 0x0000000000000001
- AbbrCode: 0x00000003
Values:
- Value: 0x0000000000000002
BlockData:
- 0x91
- 0x78
- Value: 0x000000000000007B
- Value: 0x0000000000000001
- Value: 0x0000000000000003
- Value: 0x0000000000000060
- AbbrCode: 0x00000003
Values:
- Value: 0x0000000000000002
BlockData:
- 0x91
- 0x70
- Value: 0x0000000000000080
- Value: 0x0000000000000001
- Value: 0x0000000000000003
- Value: 0x0000000000000067
- AbbrCode: 0x00000000
- AbbrCode: 0x00000004
Values:
- Value: 0x0000000000000085
- Value: 0x0000000000000005
- Value: 0x0000000000000004
- AbbrCode: 0x00000005
Values:
- Value: 0x000000000000006C
- AbbrCode: 0x00000005
Values:
- Value: 0x0000000000000071
- AbbrCode: 0x00000004
Values:
- Value: 0x0000000000000089
- Value: 0x0000000000000006
- Value: 0x0000000000000001
- AbbrCode: 0x00000000
debug_line:
- Length: 65
Version: 2
PrologueLength: 36
MinInstLength: 1
DefaultIsStmt: 1
LineBase: 251
LineRange: 14
OpcodeBase: 13
StandardOpcodeLengths:
- 0
- 1
- 1
- 1
- 1
- 0
- 0
- 0
- 1
- 0
- 0
- 1
Files:
- Name: hello_world.c
DirIdx: 0
ModTime: 0
Length: 0
Opcodes:
- Opcode: DW_LNS_extended_op
ExtLen: 9
SubOpcode: DW_LNE_set_address
Data: 4294971216
- Opcode: 0x14
Data: 4294971216
- Opcode: DW_LNS_set_column
Data: 3
- Opcode: DW_LNS_set_prologue_end
Data: 3
- Opcode: DW_LNS_const_add_pc
Data: 3
- Opcode: 0xBB
Data: 3
- Opcode: 0xBB
Data: 3
- Opcode: DW_LNS_advance_pc
Data: 11
- Opcode: DW_LNS_extended_op
ExtLen: 1
SubOpcode: DW_LNE_end_sequence
Data: 11
...
...
# DWARF32: DWARF:
# DWARF32: debug_info:
# DWARF32-NEXT: - Length: 0x75
# DWARF32-NEXT: Version: 4
# DWARF32-NEXT: AbbrevTableID: 0
# DWARF32-NEXT: AbbrOffset: 0
# DWARF32-NEXT: AddrSize: 8
# DWARF32-NEXT: Entries:
# DWARF32-NEXT: - AbbrCode: 0x1
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - Value: 0xC
# DWARF32-NEXT: - Value: 0x38
# DWARF32-NEXT: - Value: 0x0
# DWARF32-NEXT: - Value: 0x46
# DWARF32-NEXT: - Value: 0x100000F50
# DWARF32-NEXT: - Value: 0x34
# DWARF32-NEXT: - AbbrCode: 0x2
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x100000F50
# DWARF32-NEXT: - Value: 0x34
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: BlockData: [ 0x56 ]
# DWARF32-NEXT: - Value: 0x76
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - Value: 0x3
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - Value: 0x60
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - AbbrCode: 0x3
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x2
# DWARF32-NEXT: BlockData: [ 0x91, 0x78 ]
# DWARF32-NEXT: - Value: 0x7B
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - Value: 0x3
# DWARF32-NEXT: - Value: 0x60
# DWARF32-NEXT: - AbbrCode: 0x3
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x2
# DWARF32-NEXT: BlockData: [ 0x91, 0x70 ]
# DWARF32-NEXT: - Value: 0x80
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - Value: 0x3
# DWARF32-NEXT: - Value: 0x67
# DWARF32-NEXT: - AbbrCode: 0x0
# DWARF32-NEXT: - AbbrCode: 0x4
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x85
# DWARF32-NEXT: - Value: 0x5
# DWARF32-NEXT: - Value: 0x4
# DWARF32-NEXT: - AbbrCode: 0x5
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x6C
# DWARF32-NEXT: - AbbrCode: 0x5
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x71
# DWARF32-NEXT: - AbbrCode: 0x4
# DWARF32-NEXT: Values:
# DWARF32-NEXT: - Value: 0x89
# DWARF32-NEXT: - Value: 0x6
# DWARF32-NEXT: - Value: 0x1
# DWARF32-NEXT: - AbbrCode: 0x0
## b) Test that yaml2obj emits a correct unit header and obj2yaml is able to convert it back.
## Test DWARF32 unit header.
# RUN: yaml2obj --docnum=2 -DFORMAT=DWARF32 %s | \
# RUN: obj2yaml | FileCheck %s --check-prefix=DWARF32-YAML
# DWARF32-YAML: debug_info:
# DWARF32-YAML-NEXT: - Length: 0xC
# DWARF32-YAML-NEXT: Version: 4
# DWARF32-YAML-NEXT: AbbrevTableID: 0
# DWARF32-YAML-NEXT: AbbrOffset: 0
# DWARF32-YAML-NEXT: AddrSize: 8
# DWARF32-YAML-NEXT: Entries:
# DWARF32-YAML-NEXT: - AbbrCode: 0x1
# DWARF32-YAML-NEXT: Values:
# DWARF32-YAML-NEXT: - Value: 0x1234
--- !mach-o
FileHeader:
magic: 0xFEEDFACF
cputype: 0x01000007
cpusubtype: 0x00000003
filetype: 0x0000000A
ncmds: 1
sizeofcmds: 232
flags: 0x00000000
reserved: 0x00000000
LoadCommands:
- cmd: LC_SEGMENT_64
cmdsize: 232
segname: __DWARF
vmaddr: 0x00
vmsize: 0x00
fileoff: 0x00
filesize: 0x00
maxprot: 0
initprot: 0
nsects: 2
flags: 0
Sections:
- sectname: __debug_abbrev
segname: __DWARF
addr: 0x00
size: 12
offset: 528
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_info
segname: __DWARF
addr: 0x00
size: 0xffff
offset: 1070
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
DWARF:
debug_abbrev:
- Table:
- Code: 1
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_addr
debug_info:
- Format: [[FORMAT]]
Length: 12
Version: 4
AbbrOffset: 0
AddrSize: 8
Entries:
- AbbrCode: 1
Values:
- Value: 0x1234
## Test DWARF64 unit header.
# RUN: yaml2obj --docnum=2 -DFORMAT=DWARF64 %s | \
# RUN: obj2yaml | FileCheck %s --check-prefix=DWARF64-YAML
# DWARF64-YAML: debug_info:
# DWARF64-YAML-NEXT: - Format: DWARF64
# DWARF64-YAML-NEXT: Length: 0xC
# DWARF64-YAML-NEXT: Version: 4
# DWARF64-YAML-NEXT: AbbrevTableID: 0
# DWARF64-YAML-NEXT: AbbrOffset: 0
# DWARF64-YAML-NEXT: AddrSize: 8
# DWARF64-YAML-NEXT: Entries:
# DWARF64-YAML-NEXT: - AbbrCode: 0x1
# DWARF64-YAML-NEXT: Values:
# DWARF64-YAML-NEXT: - Value: 0x1234
## c) Test that yaml2obj is able to generate compilation units according to the
## associated abbrev table that is referenced by the 'AbbrevTableID' and obj2yaml
## is able to convert it back.
# RUN: yaml2obj --docnum=3 %s | obj2yaml | FileCheck %s --check-prefix=MULTI-TABLES
# MULTI-TABLES: DWARF:
# MULTI-TABLES-NEXT: debug_abbrev:
# MULTI-TABLES-NEXT: - ID: 0
# MULTI-TABLES-NEXT: Table:
# MULTI-TABLES-NEXT: - Code: 0x1
# MULTI-TABLES-NEXT: Tag: DW_TAG_compile_unit
# MULTI-TABLES-NEXT: Children: DW_CHILDREN_no
# MULTI-TABLES-NEXT: Attributes:
# MULTI-TABLES-NEXT: - Attribute: DW_AT_low_pc
# MULTI-TABLES-NEXT: Form: DW_FORM_addr
# MULTI-TABLES-NEXT: - ID: 1
# MULTI-TABLES-NEXT: Table:
# MULTI-TABLES-NEXT: - Code: 0x1
# MULTI-TABLES-NEXT: Tag: DW_TAG_compile_unit
# MULTI-TABLES-NEXT: Children: DW_CHILDREN_no
# MULTI-TABLES-NEXT: Attributes:
# MULTI-TABLES-NEXT: - Attribute: DW_AT_low_pc
# MULTI-TABLES-NEXT: Form: DW_FORM_data4
# MULTI-TABLES-NEXT: - Code: 0x2
Fix debug_abbrev emitter to only assign table id once While generating yamls for my tests I noticed that the new debug_abbrev format (with multiple table support) was incorrectly assigning id's to the table because it was generating one per abbrev entry in the table. For instance, the first table would get id 4 when 5 abbrev entries existed in the table. By itself this is not a problem but the corresponding debug_info sections were still referencing id 0. This was introduced here: https://reviews.llvm.org/D83116. Maybe a better fix is to actually correctly calculate the table id when emitting debug info? From a quick glance it seems to me the ID is just being calculated as the distance between the first DWARFAbbreviationDeclarationSet and the one the debug info entry points to, which means it's just its index and not the actual table id that was generated when emitting the debug_abbrev tables. With my fix I guess this is fine but on the diff that introduced this Pavel mentioned that he would like to have some sort of unique id between them but not necessarily +1 increasing, but for that to work we need to actually find the table ID, I guess by going directly to Y.DebugAbbrev but to honest I have no idea how to link the DWARFAbbreviationDeclarationSet and the Y.DebugAbbrev, so I just did this simple fix. I also realized there's barely any tests for MachO so it might useful to invest on that if the tool is being reworked on. Reviewed By: Higuoxing, jhenderson Differential Revision: https://reviews.llvm.org/D87179
2020-11-09 10:09:32 +08:00
# MULTI-TABLES-NEXT: Tag: DW_TAG_compile_unit
# MULTI-TABLES-NEXT: Children: DW_CHILDREN_no
# MULTI-TABLES-NEXT: Attributes:
# MULTI-TABLES-NEXT: - Attribute: DW_AT_low_pc
# MULTI-TABLES-NEXT: Form: DW_FORM_data4
# MULTI-TABLES-NEXT: - ID: 2
# MULTI-TABLES-NEXT: Table:
# MULTI-TABLES-NEXT: - Code: 0x1
# MULTI-TABLES-NEXT: Tag: DW_TAG_compile_unit
# MULTI-TABLES-NEXT: Children: DW_CHILDREN_no
# MULTI-TABLES-NEXT: Attributes:
# MULTI-TABLES-NEXT: - Attribute: DW_AT_low_pc
# MULTI-TABLES-NEXT: Form: DW_FORM_udata
Fix debug_abbrev emitter to only assign table id once While generating yamls for my tests I noticed that the new debug_abbrev format (with multiple table support) was incorrectly assigning id's to the table because it was generating one per abbrev entry in the table. For instance, the first table would get id 4 when 5 abbrev entries existed in the table. By itself this is not a problem but the corresponding debug_info sections were still referencing id 0. This was introduced here: https://reviews.llvm.org/D83116. Maybe a better fix is to actually correctly calculate the table id when emitting debug info? From a quick glance it seems to me the ID is just being calculated as the distance between the first DWARFAbbreviationDeclarationSet and the one the debug info entry points to, which means it's just its index and not the actual table id that was generated when emitting the debug_abbrev tables. With my fix I guess this is fine but on the diff that introduced this Pavel mentioned that he would like to have some sort of unique id between them but not necessarily +1 increasing, but for that to work we need to actually find the table ID, I guess by going directly to Y.DebugAbbrev but to honest I have no idea how to link the DWARFAbbreviationDeclarationSet and the Y.DebugAbbrev, so I just did this simple fix. I also realized there's barely any tests for MachO so it might useful to invest on that if the tool is being reworked on. Reviewed By: Higuoxing, jhenderson Differential Revision: https://reviews.llvm.org/D87179
2020-11-09 10:09:32 +08:00
# MULTI-TABLES-NEXT: - ID: 3
# MULTI-TABLES-NEXT: debug_info:
# MULTI-TABLES-NEXT: - Length: 0xC
# MULTI-TABLES-NEXT: Version: 4
# MULTI-TABLES-NEXT: AbbrevTableID: 1
# MULTI-TABLES-NEXT: AbbrOffset: 0x8
# MULTI-TABLES-NEXT: AddrSize: 8
# MULTI-TABLES-NEXT: Entries:
# MULTI-TABLES-NEXT: - AbbrCode: 0x1
# MULTI-TABLES-NEXT: Values:
# MULTI-TABLES-NEXT: - Value: 0x1234
# MULTI-TABLES-NEXT: - Length: 0xC
# MULTI-TABLES-NEXT: Version: 4
# MULTI-TABLES-NEXT: AbbrevTableID: 1
# MULTI-TABLES-NEXT: AbbrOffset: 0x8
# MULTI-TABLES-NEXT: AddrSize: 8
# MULTI-TABLES-NEXT: Entries:
# MULTI-TABLES-NEXT: - AbbrCode: 0x1
# MULTI-TABLES-NEXT: Values:
# MULTI-TABLES-NEXT: - Value: 0x4321
# MULTI-TABLES-NEXT: - Length: 0x10
# MULTI-TABLES-NEXT: Version: 4
# MULTI-TABLES-NEXT: AbbrevTableID: 0
# MULTI-TABLES-NEXT: AbbrOffset: 0x0
# MULTI-TABLES-NEXT: AddrSize: 8
# MULTI-TABLES-NEXT: Entries:
# MULTI-TABLES-NEXT: - AbbrCode: 0x1
# MULTI-TABLES-NEXT: Values:
# MULTI-TABLES-NEXT: - Value: 0x5678
# MULTI-TABLES-NEXT: - Length: 0xB
# MULTI-TABLES-NEXT: Version: 4
# MULTI-TABLES-NEXT: AbbrevTableID: 2
# MULTI-TABLES-NEXT: AbbrOffset: 0x17
# MULTI-TABLES-NEXT: AddrSize: 8
# MULTI-TABLES-NEXT: Entries:
# MULTI-TABLES-NEXT: - AbbrCode: 0x1
# MULTI-TABLES-NEXT: Values:
# MULTI-TABLES-NEXT: - Value: 0x8765
# MULTI-TABLES-NEXT: ...
--- !mach-o
FileHeader:
magic: 0xFEEDFACF
cputype: 0x01000007
cpusubtype: 0x00000003
filetype: 0x0000000A
ncmds: 1
sizeofcmds: 232
flags: 0x00000000
reserved: 0x00000000
LoadCommands:
- cmd: LC_SEGMENT_64
cmdsize: 232
segname: __DWARF
vmaddr: 0x00
vmsize: 0x00
fileoff: 0x00
filesize: 0x00
maxprot: 0
initprot: 0
nsects: 2
flags: 0
Sections:
- sectname: __debug_abbrev
segname: __DWARF
addr: 0x00
Fix debug_abbrev emitter to only assign table id once While generating yamls for my tests I noticed that the new debug_abbrev format (with multiple table support) was incorrectly assigning id's to the table because it was generating one per abbrev entry in the table. For instance, the first table would get id 4 when 5 abbrev entries existed in the table. By itself this is not a problem but the corresponding debug_info sections were still referencing id 0. This was introduced here: https://reviews.llvm.org/D83116. Maybe a better fix is to actually correctly calculate the table id when emitting debug info? From a quick glance it seems to me the ID is just being calculated as the distance between the first DWARFAbbreviationDeclarationSet and the one the debug info entry points to, which means it's just its index and not the actual table id that was generated when emitting the debug_abbrev tables. With my fix I guess this is fine but on the diff that introduced this Pavel mentioned that he would like to have some sort of unique id between them but not necessarily +1 increasing, but for that to work we need to actually find the table ID, I guess by going directly to Y.DebugAbbrev but to honest I have no idea how to link the DWARFAbbreviationDeclarationSet and the Y.DebugAbbrev, so I just did this simple fix. I also realized there's barely any tests for MachO so it might useful to invest on that if the tool is being reworked on. Reviewed By: Higuoxing, jhenderson Differential Revision: https://reviews.llvm.org/D87179
2020-11-09 10:09:32 +08:00
size: 32
offset: 528
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
- sectname: __debug_info
segname: __DWARF
addr: 0x00
size: 67
offset: 1070
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
DWARF:
debug_abbrev:
- Table:
- Code: 1
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_addr
- ID: 2
Table:
- Code: 1
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_data4
Fix debug_abbrev emitter to only assign table id once While generating yamls for my tests I noticed that the new debug_abbrev format (with multiple table support) was incorrectly assigning id's to the table because it was generating one per abbrev entry in the table. For instance, the first table would get id 4 when 5 abbrev entries existed in the table. By itself this is not a problem but the corresponding debug_info sections were still referencing id 0. This was introduced here: https://reviews.llvm.org/D83116. Maybe a better fix is to actually correctly calculate the table id when emitting debug info? From a quick glance it seems to me the ID is just being calculated as the distance between the first DWARFAbbreviationDeclarationSet and the one the debug info entry points to, which means it's just its index and not the actual table id that was generated when emitting the debug_abbrev tables. With my fix I guess this is fine but on the diff that introduced this Pavel mentioned that he would like to have some sort of unique id between them but not necessarily +1 increasing, but for that to work we need to actually find the table ID, I guess by going directly to Y.DebugAbbrev but to honest I have no idea how to link the DWARFAbbreviationDeclarationSet and the Y.DebugAbbrev, so I just did this simple fix. I also realized there's barely any tests for MachO so it might useful to invest on that if the tool is being reworked on. Reviewed By: Higuoxing, jhenderson Differential Revision: https://reviews.llvm.org/D87179
2020-11-09 10:09:32 +08:00
- Code: 2
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_data4
- ID: 1
Table:
- Code: 1
Tag: DW_TAG_compile_unit
Children: DW_CHILDREN_no
Attributes:
- Attribute: DW_AT_low_pc
Form: DW_FORM_udata
Fix debug_abbrev emitter to only assign table id once While generating yamls for my tests I noticed that the new debug_abbrev format (with multiple table support) was incorrectly assigning id's to the table because it was generating one per abbrev entry in the table. For instance, the first table would get id 4 when 5 abbrev entries existed in the table. By itself this is not a problem but the corresponding debug_info sections were still referencing id 0. This was introduced here: https://reviews.llvm.org/D83116. Maybe a better fix is to actually correctly calculate the table id when emitting debug info? From a quick glance it seems to me the ID is just being calculated as the distance between the first DWARFAbbreviationDeclarationSet and the one the debug info entry points to, which means it's just its index and not the actual table id that was generated when emitting the debug_abbrev tables. With my fix I guess this is fine but on the diff that introduced this Pavel mentioned that he would like to have some sort of unique id between them but not necessarily +1 increasing, but for that to work we need to actually find the table ID, I guess by going directly to Y.DebugAbbrev but to honest I have no idea how to link the DWARFAbbreviationDeclarationSet and the Y.DebugAbbrev, so I just did this simple fix. I also realized there's barely any tests for MachO so it might useful to invest on that if the tool is being reworked on. Reviewed By: Higuoxing, jhenderson Differential Revision: https://reviews.llvm.org/D87179
2020-11-09 10:09:32 +08:00
- ID: 3
debug_info:
- Version: 4
AbbrevTableID: 2
Entries:
- AbbrCode: 1
Values:
- Value: 0x1234
- Version: 4
AbbrevTableID: 2
Entries:
- AbbrCode: 1
Values:
- Value: 0x4321
- Version: 4
AbbrevTableID: 0
Entries:
- AbbrCode: 1
Values:
- Value: 0x5678
- Version: 4
AbbrevTableID: 1
Entries:
- AbbrCode: 1
Values:
- Value: 0x8765
## d) Test that yaml2obj emits an error message when a compilation unit doesn't have
## an associated abbrev table.
# RUN: not yaml2obj --docnum=4 %s 2>&1 | FileCheck %s --check-prefix=MISSING-ABBREV
# MISSING-ABBREV: yaml2obj: error: cannot find abbrev table whose ID is 0 for compilation unit with index 0
--- !mach-o
FileHeader:
magic: 0xFEEDFACF
cputype: 0x01000007
cpusubtype: 0x00000003
filetype: 0x0000000A
ncmds: 1
sizeofcmds: 232
flags: 0x00000000
reserved: 0x00000000
LoadCommands:
- cmd: LC_SEGMENT_64
cmdsize: 152
segname: __DWARF
vmaddr: 0x00
vmsize: 0x00
fileoff: 0x00
filesize: 0x00
maxprot: 0
initprot: 0
nsects: 2
flags: 0
Sections:
- sectname: __debug_info
segname: __DWARF
addr: 0x00
size: 64
offset: 1070
align: 0
reloff: 0x00000000
nreloc: 0
flags: 0x00000000
reserved1: 0x00000000
reserved2: 0x00000000
reserved3: 0x00000000
DWARF:
debug_info:
- Version: 4
AbbrOffset: 0x00
Entries:
- AbbrCode: 1
Values:
- Value: 0x1234