2017-03-01 07:40:46 +08:00
|
|
|
// RUN: llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 5 -fdebug-compilation-dir=/tmp
|
2020-02-28 13:57:40 +08:00
|
|
|
// RUN: llvm-dwarfdump -v %t | FileCheck --check-prefixes=DWARF,DWARF5 %s
|
2018-02-09 07:08:02 +08:00
|
|
|
// RUN: llvm-dwarfdump --debug-line %t | FileCheck -check-prefix DWARF-DL -check-prefix DWARF-DL-5 -DDWVER=5 -DDWFILE=0 %s
|
2020-02-28 13:57:40 +08:00
|
|
|
// RUN: llvm-objdump -r %t | FileCheck --check-prefixes=RELOC,RELOC5 %s
|
[llvm] Prevent duplicate files in debug line header in dwarf 5: another attempt
Another attempt to land the changes in debug line header to prevent duplicate
files in Dwarf 5. I rolled back my previous commit because of a mistake in
generating the object file in a test. Meanwhile, I addressed some offline
comments and changed the implementation; the largest difference is that
MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I
also merged the patch to fix two lld tests that will strt to fail into this
patch.
Original Commit:
https://reviews.llvm.org/D59515
Original Message:
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.
The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)
With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf
5) However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.
llvm-svn: 358732
2019-04-19 10:26:56 +08:00
|
|
|
// RUN: llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 4 -fdebug-compilation-dir=/tmp
|
2020-02-28 13:57:40 +08:00
|
|
|
// RUN: llvm-dwarfdump -v %t | FileCheck -check-prefixes=DWARF,DWARF34,DWARF4 %s
|
2020-11-17 08:48:19 +08:00
|
|
|
// RUN: llvm-dwarfdump --debug-line %t | FileCheck --check-prefixes=DWARF-DL,DWARF-DL-3 -DDWVER=4 -DDWFILE=1 %s
|
2020-02-28 13:57:40 +08:00
|
|
|
// RUN: llvm-objdump -r %t | FileCheck --check-prefixes=RELOC,RELOC34,RELOC4 %s
|
2015-12-23 09:57:31 +08:00
|
|
|
// RUN: llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 3 -fdebug-compilation-dir=/tmp
|
2020-02-28 13:57:40 +08:00
|
|
|
// RUN: llvm-dwarfdump -v %t | FileCheck --check-prefixes=DWARF,DWARF34,DWARF3 %s
|
2020-11-17 08:48:19 +08:00
|
|
|
// RUN: llvm-dwarfdump --debug-line %t | FileCheck --check-prefixes=DWARF-DL,DWARF-DL-3 -DDWVER=3 -DDWFILE=1 %s
|
2014-09-22 18:45:16 +08:00
|
|
|
// RUN: llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 2 2>&1 | FileCheck -check-prefix VERSION %s
|
2014-06-20 00:35:19 +08:00
|
|
|
// RUN: not llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 1 2>&1 | FileCheck -check-prefix DWARF1 %s
|
2017-03-01 07:40:46 +08:00
|
|
|
// RUN: not llvm-mc < %s -triple=armv7-linux-gnueabi -filetype=obj -o %t -g -dwarf-version 6 2>&1 | FileCheck -check-prefix DWARF6 %s
|
2014-06-20 00:35:19 +08:00
|
|
|
.section .text, "ax"
|
|
|
|
a:
|
|
|
|
mov r0, r0
|
|
|
|
|
|
|
|
.section foo, "ax"
|
|
|
|
b:
|
|
|
|
mov r1, r1
|
|
|
|
|
2020-11-17 12:02:25 +08:00
|
|
|
// Non-executable sections do not contribute address ranges.
|
|
|
|
.section .rodata, "a"
|
|
|
|
c:
|
|
|
|
mov r2, r2
|
|
|
|
|
|
|
|
// Non-SHF_ALLOC sections do not contribute address ranges.
|
|
|
|
.section nonalloc, "x"
|
|
|
|
d:
|
|
|
|
mov r3, r3
|
|
|
|
|
2014-06-20 00:35:19 +08:00
|
|
|
// DWARF: .debug_abbrev contents:
|
|
|
|
// DWARF: Abbrev table for offset: 0x00000000
|
|
|
|
// DWARF: [1] DW_TAG_compile_unit DW_CHILDREN_yes
|
2015-12-23 09:57:31 +08:00
|
|
|
// DWARF3: DW_AT_stmt_list DW_FORM_data4
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF4: DW_AT_stmt_list DW_FORM_sec_offset
|
|
|
|
// DWARF5: DW_AT_stmt_list DW_FORM_sec_offset
|
2015-12-23 09:57:31 +08:00
|
|
|
// DWARF3: DW_AT_ranges DW_FORM_data4
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF4: DW_AT_ranges DW_FORM_sec_offset
|
|
|
|
// DWARF5: DW_AT_ranges DW_FORM_sec_offset
|
2014-06-20 00:35:19 +08:00
|
|
|
// DWARF: DW_AT_name DW_FORM_string
|
|
|
|
// DWARF: DW_AT_comp_dir DW_FORM_string
|
|
|
|
// DWARF: DW_AT_producer DW_FORM_string
|
|
|
|
// DWARF: DW_AT_language DW_FORM_data2
|
|
|
|
|
|
|
|
// DWARF: .debug_info contents:
|
|
|
|
// DWARF: 0x{{[0-9a-f]+}}: DW_TAG_compile_unit [1]
|
2015-12-23 09:57:31 +08:00
|
|
|
// DWARF-NOT: DW_TAG_
|
2017-03-01 07:40:46 +08:00
|
|
|
// DWARF3: DW_AT_ranges [DW_FORM_data4] (0x00000000
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF4: DW_AT_ranges [DW_FORM_sec_offset] (0x00000000
|
|
|
|
// DWARF5: DW_AT_ranges [DW_FORM_sec_offset] (0x0000000c
|
2014-06-20 00:35:19 +08:00
|
|
|
|
2020-05-25 13:30:59 +08:00
|
|
|
// DWARF: 0x{{[0-9a-f]+}}: DW_TAG_label [2]
|
2014-06-20 00:35:19 +08:00
|
|
|
// DWARF-NEXT: DW_AT_name [DW_FORM_string] ("a")
|
|
|
|
|
2020-05-25 13:30:59 +08:00
|
|
|
// DWARF: 0x{{[0-9a-f]+}}: DW_TAG_label [2]
|
2014-06-20 00:35:19 +08:00
|
|
|
// DWARF-NEXT: DW_AT_name [DW_FORM_string] ("b")
|
|
|
|
|
2020-11-17 08:48:19 +08:00
|
|
|
// DWARF-NOT: DW_TAG_label
|
|
|
|
|
2014-06-20 00:35:19 +08:00
|
|
|
|
|
|
|
// DWARF: .debug_aranges contents:
|
2020-06-02 16:44:47 +08:00
|
|
|
// DWARF-NEXT: Address Range Header: length = 0x00000024, format = DWARF32, version = 0x0002, cu_offset = 0x00000000, addr_size = 0x04, seg_size = 0x00
|
2018-01-16 19:17:57 +08:00
|
|
|
// DWARF-NEXT: [0x00000000, 0x00000004)
|
|
|
|
// DWARF-NEXT: [0x00000000, 0x00000004)
|
2020-11-17 08:48:19 +08:00
|
|
|
// DWARF-EMPTY:
|
2014-06-20 00:35:19 +08:00
|
|
|
|
|
|
|
|
2017-09-22 04:15:30 +08:00
|
|
|
// DWARF-DL: .debug_line contents:
|
2017-12-06 04:35:00 +08:00
|
|
|
// DWARF-DL: version: [[DWVER]]
|
|
|
|
// DWARF-DL-5: address_size: 4
|
2018-03-30 01:16:41 +08:00
|
|
|
// DWARF-DL-5: include_directories[ 0] = "/tmp"
|
2018-02-24 07:01:06 +08:00
|
|
|
// DWARF-DL: file_names[ [[DWFILE]]]:
|
2018-03-30 01:16:41 +08:00
|
|
|
// DWARF-DL: name: "{{(<stdin>|-)}}"
|
[llvm] Prevent duplicate files in debug line header in dwarf 5: another attempt
Another attempt to land the changes in debug line header to prevent duplicate
files in Dwarf 5. I rolled back my previous commit because of a mistake in
generating the object file in a test. Meanwhile, I addressed some offline
comments and changed the implementation; the largest difference is that
MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I
also merged the patch to fix two lld tests that will strt to fail into this
patch.
Original Commit:
https://reviews.llvm.org/D59515
Original Message:
Motivation: In previous dwarf versions, file name indexes started from 1, and
the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes
the primary source file to be explicitly given an entry with an index number 0.
The current implementation honors the specification by just duplicating the
main source file, once with index number 0, and later maybe with another
index number. While this is compliant with the letter of the standard, the
duplication causes problems for consumers of this information such as lldb.
(Some files are duplicated, where only some of them have a line table although
all refer to the same file)
With this change, dwarf 5 debug line section files always start from 0, and
the zeroth entry is not duplicated whenever possible. This requires different
handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns
an index zero for a file name, it signals an error in dwarf 4, but not in dwarf
5) However, I think the minor complication is worth it, because it enables all
consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the
file name list homogenously.
llvm-svn: 358732
2019-04-19 10:26:56 +08:00
|
|
|
// DWARF-DL-5: 0x0000000000000000 17 0 0 0 0 is_stmt
|
|
|
|
// DWARF-DL-5-NEXT: 0x0000000000000004 17 0 0 0 0 is_stmt end_sequence
|
|
|
|
// DWARF-DL-5-NEXT: 0x0000000000000000 21 0 0 0 0 is_stmt
|
|
|
|
// DWARF-DL-5-NEXT: 0x0000000000000004 21 0 0 0 0 is_stmt end_sequence
|
2020-11-17 08:48:19 +08:00
|
|
|
// DWARF-DL-3: 0x0000000000000000 17 0 1 0 0 is_stmt
|
|
|
|
// DWARF-DL-3-NEXT: 0x0000000000000004 17 0 1 0 0 is_stmt end_sequence
|
|
|
|
// DWARF-DL-3-NEXT: 0x0000000000000000 21 0 1 0 0 is_stmt
|
|
|
|
// DWARF-DL-3-NEXT: 0x0000000000000004 21 0 1 0 0 is_stmt end_sequence
|
|
|
|
// DWARF-DL-EMPTY:
|
2019-03-27 04:05:27 +08:00
|
|
|
|
2014-06-20 00:35:19 +08:00
|
|
|
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF34: .debug_ranges contents:
|
|
|
|
// DWARF34-NEXT: 00000000 ffffffff 00000000
|
|
|
|
// DWARF34-NEXT: 00000000 00000000 00000004
|
|
|
|
// DWARF34-NEXT: 00000000 ffffffff 00000000
|
|
|
|
// DWARF34-NEXT: 00000000 00000000 00000004
|
|
|
|
// DWARF34-NEXT: 00000000 <End of list>
|
2018-09-17 23:40:01 +08:00
|
|
|
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF5: .debug_rnglists contents:
|
2020-06-02 17:11:02 +08:00
|
|
|
// DWARF5-NEXT: 0x00000000: range list header: length = 0x00000015, format = DWARF32, version = 0x0005, addr_size = 0x04, seg_size = 0x00, offset_entry_count = 0x00000000
|
2020-02-28 13:57:40 +08:00
|
|
|
// DWARF5-NEXT: ranges:
|
|
|
|
// DWARF5-NEXT: 0x0000000c: [DW_RLE_start_length]: 0x00000000, 0x00000004 => [0x00000000, 0x00000004)
|
|
|
|
// DWARF5-NEXT: 0x00000012: [DW_RLE_start_length]: 0x00000000, 0x00000004 => [0x00000000, 0x00000004)
|
|
|
|
// DWARF5-NEXT: 0x00000018: [DW_RLE_end_of_list ]
|
2014-06-20 00:35:19 +08:00
|
|
|
|
|
|
|
|
2017-03-01 07:40:46 +08:00
|
|
|
// Offsets are different in DWARF v5 due to different header layout.
|
2019-05-07 21:14:18 +08:00
|
|
|
// RELOC: RELOCATION RECORDS FOR [.debug_info]:
|
2020-02-11 19:10:57 +08:00
|
|
|
// RELOC4-NEXT: OFFSET TYPE VALUE
|
2017-03-01 07:40:46 +08:00
|
|
|
// RELOC4-NEXT: 00000006 R_ARM_ABS32 .debug_abbrev
|
|
|
|
// RELOC4-NEXT: 0000000c R_ARM_ABS32 .debug_line
|
|
|
|
// RELOC4-NEXT: 00000010 R_ARM_ABS32 .debug_ranges
|
2020-02-11 19:10:57 +08:00
|
|
|
// RELOC5-NEXT: OFFSET TYPE VALUE
|
2017-03-01 07:40:46 +08:00
|
|
|
// RELOC5-NEXT: 00000008 R_ARM_ABS32 .debug_abbrev
|
|
|
|
// RELOC5-NEXT: 0000000d R_ARM_ABS32 .debug_line
|
2020-02-28 13:57:40 +08:00
|
|
|
// RELOC5-NEXT: 00000011 R_ARM_ABS32 .debug_rnglists
|
2014-06-20 04:00:13 +08:00
|
|
|
// RELOC-NEXT: R_ARM_ABS32 .text
|
|
|
|
// RELOC-NEXT: R_ARM_ABS32 foo
|
2014-06-20 00:35:19 +08:00
|
|
|
|
2019-05-07 21:14:18 +08:00
|
|
|
// RELOC: RELOCATION RECORDS FOR [.debug_aranges]:
|
2020-02-11 19:10:57 +08:00
|
|
|
// RELOC-NEXT: OFFSET TYPE VALUE
|
2014-06-20 00:35:19 +08:00
|
|
|
// RELOC-NEXT: 00000006 R_ARM_ABS32 .debug_info
|
|
|
|
// RELOC-NEXT: 00000010 R_ARM_ABS32 .text
|
|
|
|
// RELOC-NEXT: 00000018 R_ARM_ABS32 foo
|
|
|
|
|
2020-02-28 13:57:40 +08:00
|
|
|
// RELOC34: RELOCATION RECORDS FOR [.debug_ranges]:
|
|
|
|
// RELOC34-NEXT: OFFSET TYPE VALUE
|
|
|
|
// RELOC34-NEXT: 00000004 R_ARM_ABS32 .text
|
|
|
|
// RELOC34-NEXT: 00000014 R_ARM_ABS32 foo
|
|
|
|
|
|
|
|
// RELOC5: RELOCATION RECORDS FOR [.debug_rnglists]:
|
|
|
|
// RELOC5-NEXT: OFFSET TYPE VALUE
|
|
|
|
// RELOC5-NEXT: 0000000d R_ARM_ABS32 .text
|
|
|
|
// RELOC5-NEXT: 00000013 R_ARM_ABS32 foo
|
|
|
|
|
2014-06-20 00:35:19 +08:00
|
|
|
|
2014-09-22 18:45:16 +08:00
|
|
|
// VERSION: {{.*}} warning: DWARF2 only supports one section per compilation unit
|
2014-06-20 00:35:19 +08:00
|
|
|
|
|
|
|
// DWARF1: Dwarf version 1 is not supported.
|
2017-03-01 07:40:46 +08:00
|
|
|
// DWARF6: Dwarf version 6 is not supported.
|