Differential D36313 Diff 110339 test/DebugInfo/X86/dwarfdump-ranges-unrelocated.s

Changeset View

Standalone View

test/DebugInfo/X86/dwarfdump-ranges-unrelocated.s

	# RUN: llvm-mc -triple x86_64-pc-linux -filetype=obj %s -o %t			# RUN: llvm-mc -triple x86_64-pc-linux -filetype=obj %s -o %t
	# RUN: llvm-dwarfdump %t \| FileCheck %s			# RUN: llvm-dwarfdump %t \| FileCheck %s

				# CHECK: .debug_info contents:
				# CHECK: DW_TAG_compile_unit
				# CHECK: DW_AT_ranges [DW_FORM_sec_offset] (0x00000000
				# CHECK-NEXT: [0x0000000000000000 - 0x0000000000000001) ".text.foo1"
				# CHECK-NEXT: [0x0000000000000000 - 0x0000000000000002) ".text.foo2" [4]
				dblaikieUnsubmitted Not Done Reply Inline Actions It'd be nice to columnize the section number - but maybe that's too much work? (scanning through to find the longest section name, etc) Also, similar amount of work: Do you think it'd be worth it/good to omit the section number if the section names are not ambiguous in this list? (or perhaps necessary to only do this if the name is not ambiguous in the whole file (so you on't look at the ranges for two functions and see them describing what appears to be the same section)) & what about omitting the name or putting it somewhere else (like at the start on a separate line) if every entry is in the same section? (which will be the case for all ranges except the compile_unit ranges, most likely) Maybe that's all overkill - wouldn't mind getting Adrian's take on this, as he was driving a bunch of the dwarfdump improvements like this inline range dumping. dblaikie: It'd be nice to columnize the section number - but maybe that's too much work? (scanning…
				grimarAuthorUnsubmitted Not Done Reply Inline Actions I would not scan over all sections of file, because it looks too much. Scanning over all sections can be slow. I would not omit something dependent on third conditions too, because it makes logic of output unclear for people that are not familar with tool. ("Why it prints section index for "foo" and does not for "bar" ? BUUUG !") Also I think often I am looking for section number in readelf/objdump/other tools, so I would not omit it to be able to find it as fast as possible without manual eye-mapping name to index by myself. Basing on above I think I like "omitting the name or putting it somewhere else (like at the start on a separate line) if every entry is in the same section" as it avoids printing the same name+index multiple times. It also removes need to columnize anything probably and thus scan through to find longest index/section name, what should leave code simple. What do you think about new version of output ? (I am wondering if we still want to columnize the section index, I am not sure). grimar: I would not scan over all sections of file, because it looks too much. Scanning over all…
				# CHECK-NEXT: [0x0000000000000000 - 0x0000000000000003) ".text.foo2" [5])

	# CHECK: .debug_ranges contents:			# CHECK: .debug_ranges contents:
	# CHECK: 00000000 0000000000000000 0000000000000001			# CHECK: 00000000 0000000000000000 0000000000000001
	# CHECK: 00000000 0000000000000000 0000000000000002			# CHECK: 00000000 0000000000000000 0000000000000002
				# CHECK: 00000000 0000000000000000 0000000000000003
	# CHECK: 00000000 <End of list>			# CHECK: 00000000 <End of list>

	## Asm code for testcase is a reduced output from next invocation and source:			# RUN: llvm-dwarfdump -brief=true %t \| FileCheck %s --check-prefix=BRIEF
				# BRIEF: DW_TAG_compile_unit
				# BRIEF: DW_AT_ranges (0x00000000
				# BRIEF-NEXT: [0x0000000000000000 - 0x0000000000000001)
				# BRIEF-NEXT: [0x0000000000000000 - 0x0000000000000002)
				# BRIEF-NEXT: [0x0000000000000000 - 0x0000000000000003))

				## Asm code for testcase is a reduced and modified output from next
				## invocation and source:
	# clang test.cpp -S -o test.s -gmlt -ffunction-sections			# clang test.cpp -S -o test.s -gmlt -ffunction-sections
	# test.cpp:			# test.cpp:
	# void foo1() { }			# void foo1() { }
	# void foo2() { }			# void foo2() { }

	.section .text.foo1,"ax",@progbits			.section .text.foo1,"ax",@progbits
	.Lfunc_begin0:			.Lfunc_begin0:
	nop			nop
	.Lfunc_end0:			.Lfunc_end0:

	.section .text.foo2,"ax",@progbits			.section .text.foo2,"ax",@progbits, unique, 1
	.Lfunc_begin1:			.Lfunc_begin1:
	nop			nop
	nop			nop
	.Lfunc_end1:			.Lfunc_end1:

				.section .text.foo2,"ax",@progbits, unique, 2
				.Lfunc_begin2:
				nop
				nop
				nop
				.Lfunc_end2:

	.section .debug_abbrev,"",@progbits			.section .debug_abbrev,"",@progbits
	.byte 1 # Abbreviation Code			.byte 1 # Abbreviation Code
	.byte 17 # DW_TAG_compile_unit			.byte 17 # DW_TAG_compile_unit
	.byte 0 # DW_CHILDREN_no			.byte 0 # DW_CHILDREN_no
	.byte 37 # DW_AT_producer			.byte 37 # DW_AT_producer
	.byte 14 # DW_FORM_strp			.byte 14 # DW_FORM_strp
	.byte 19 # DW_AT_language			.byte 19 # DW_AT_language
	.byte 5 # DW_FORM_data2			.byte 5 # DW_FORM_data2
	Show All 27 Lines
	.long .Ldebug_ranges0 # DW_AT_ranges			.long .Ldebug_ranges0 # DW_AT_ranges

	.section .debug_ranges,"",@progbits			.section .debug_ranges,"",@progbits
	.Ldebug_ranges0:			.Ldebug_ranges0:
	.quad .Lfunc_begin0			.quad .Lfunc_begin0
	.quad .Lfunc_end0			.quad .Lfunc_end0
	.quad .Lfunc_begin1			.quad .Lfunc_begin1
	.quad .Lfunc_end1			.quad .Lfunc_end1
				.quad .Lfunc_begin2
				.quad .Lfunc_end2
	.quad 0			.quad 0
	.quad 0			.quad 0