maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/gdb-index-multiple-cu.s

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

89 lines
2.7 KiB
ArmAsm
Raw Normal View History

Fix r346747 and r346796 Require x86 for the tests in order to fix non-x86 bots. This seems to be the case for all other tests in that directory. llvm-svn: 346842
2018-11-14 17:58:17 +08:00
# REQUIRES: x86
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
# RUN: ld.lld --gdb-index %t.o -o %t
# RUN: llvm-dwarfdump -gdb-index %t | FileCheck %s
[ELF] Fix variable names in comments after VariableName -> variableName change Also fix some typos. llvm-svn: 366181
2019-07-16 13:50:45 +08:00
# cuIndexAndAttrs of _start:
# attributes << 24 | cuIndex = 48 << 24 | 0 = 0x30000000
# cuIndexAndAttrs of foo:
# attributes << 24 | cuIndex = 48 << 24 | 1 = 0x30000001
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
# CHECK: Symbol table
# CHECK-DAG: String name: _start, CU vector index: 0
# CHECK-DAG: String name: foo, CU vector index: 1
# CHECK: Constant pool
# CHECK-NEXT: 0(0x0): 0x30000000
# CHECK-NEXT: 1(0x8): 0x30000001
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.globl _start, foo
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
_start:
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
foo:
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.section .debug_abbrev,"",@progbits
.byte 1 # Abbreviation Code
.byte 17 # DW_TAG_compile_unit
.byte 1 # DW_CHILDREN_yes
.ascii "\264B" # DW_AT_GNU_pubnames
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.byte 25 # DW_FORM_flag_present
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.byte 0 # EOM(1)
.byte 0 # EOM(2)
.byte 2 # Abbreviation Code
.byte 46 # DW_TAG_subprogram
.byte 0 # DW_CHILDREN_no
.byte 3 # DW_AT_name
.byte 8 # DW_FORM_string
.byte 0 # EOM(1)
.byte 0 # EOM(2)
.byte 0
.section .debug_info,"",@progbits
.Lcu_begin0:
.long .Lcu_end0 - .Lcu_begin0 - 4
.short 4 # DWARF version number
.long 0 # Offset Into Abbrev. Section
.byte 4 # Address Size
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.Ldie0:
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.byte 1 # Abbrev [1] DW_TAG_compile_unit
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.byte 2 # Abbrev [2] DW_TAG_subprogram
.asciz "_start" # DW_AT_name
.byte 0
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.byte 0
.Lcu_end0:
.Lcu_begin1:
.long .Lcu_end1 - .Lcu_begin1 - 4
.short 4 # DWARF version number
.long 0 # Offset Into Abbrev. Section
.byte 4 # Address Size
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.Ldie1:
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.byte 1 # Abbrev [1] DW_TAG_compile_unit
.byte 2 # Abbrev [2] DW_TAG_subprogram
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.asciz "foo" # DW_AT_name
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.byte 0
.Lcu_end1:
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
# Swap sets to test the case where pubnames are in a
# different order than the CUs they refer to.
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.section .debug_gnu_pubnames,"",@progbits
[ELF] Fix variable names in comments after VariableName -> variableName change Also fix some typos. llvm-svn: 366181
2019-07-16 13:50:45 +08:00
# cuIndex: 1
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.long .LpubNames_end1 - .LpubNames_begin1
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.LpubNames_begin1:
.short 2 # Version
.long .Lcu_begin1 # CU Offset
.long .Lcu_end1 - .Lcu_begin1
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.long .Ldie1 - .Lcu_begin1
[ELF] Add a better test for the multi-CU .gdb_index bug that D54361 fixed gdb-index-multiple-cu-2.s puts the symbol in question to another object file %t1.o, so that its CuIndex is affected by the number of CUs in %t.o Also change `Kind:` in a comment to `Attributes:` as a follow-up of D54480 and D54481 llvm-svn: 346796
2018-11-14 04:49:36 +08:00
.byte 48 # Attributes: FUNCTION, EXTERNAL
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.asciz "foo" # External Name
[ELF] .gdb_index: fix CuOff when a .debug_info section contains more than 1 DW_TAG_compile_unit Summary: Idx passed to readPubNamesAndTypes was an index into Chunks, not an index into the CU list. This would be incorrect if some .debug_info section contained more than 1 DW_TAG_compile_unit. In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds. Without this patch, any application linking such Scrt1.o would have invalid .gdb_index The issue could be demonstrated by: (gdb) py print(gdb.lookup_global_symbol('main')) None Reviewers: espindola, ruiu Reviewed By: ruiu Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54361 llvm-svn: 346747
2018-11-13 16:43:07 +08:00
.long 0
.LpubNames_end1:
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
[ELF] Fix variable names in comments after VariableName -> variableName change Also fix some typos. llvm-svn: 366181
2019-07-16 13:50:45 +08:00
# cuIndex: 0
[ELF] --gdb-index: use lower_bound to compute relative CU index in the object file Summary: This reinstates what I originally intended to do in D54361. It removes the assumption that .debug_gnu_pubnames has increasing CuOffset. Now we do better than gold here: when .debug_gnu_pubnames contains multiple sets, gold would think every set has the same CU index as the first set (incorrect). Reviewed By: ruiu Reviewers: ruiu, dblaikie, espindola Subscribers: emaste, arichardson, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54483 llvm-svn: 347820
2018-11-29 08:17:00 +08:00
.long .LpubNames_end0 - .LpubNames_begin0
.LpubNames_begin0:
.short 2 # Version
.long .Lcu_begin0 # CU Offset
.long .Lcu_end0 - .Lcu_begin0
.long .Ldie0 - .Lcu_begin0
.byte 48 # Attributes: FUNCTION, EXTERNAL
.asciz "_start" # External Name
.long 0
.LpubNames_end0: