RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 03:33:20 +01:00
Code Issues Projects Releases Wiki Activity
1e3e46f404
llvm-mirror/test/MC/MachO/gen-dwarf.s

123 lines
4.7 KiB
ArmAsm
Raw Normal View History

The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// RUN: llvm-mc -g -triple i386-apple-darwin10 %s -filetype=obj -o %t
Now that llvm-dwarfdump supports flags to specify which DWARF section to dump, use them in tests that run llvm-dwarfdump. This is in order to make tests as specific as possible. llvm-svn: 173498
2013-01-25 22:44:53 +01:00
// RUN: llvm-dwarfdump -debug-dump=all %t | FileCheck %s
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
.globl _bar
_bar:
movl $0, %eax
L1: leave
ret
_foo:
Various crash reporting tools have a problem with the dwarf generated for assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 llvm-svn: 147860
2012-01-10 18:52:29 +01:00
_baz:
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
nop
.data
_x: .long 1
// CHECK: file format Mach-O 32-bit i386
// CHECK: .debug_abbrev contents:
// CHECK: Abbrev table for offset: 0x00000000
// CHECK: [1] DW_TAG_compile_unit DW_CHILDREN_yes
// CHECK: DW_AT_stmt_list DW_FORM_data4
// CHECK: DW_AT_low_pc DW_FORM_addr
// CHECK: DW_AT_high_pc DW_FORM_addr
// CHECK: DW_AT_name DW_FORM_string
// CHECK: DW_AT_comp_dir DW_FORM_string
// CHECK: DW_AT_producer DW_FORM_string
// CHECK: DW_AT_language DW_FORM_data2
Various crash reporting tools have a problem with the dwarf generated for assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 llvm-svn: 147860
2012-01-10 18:52:29 +01:00
// CHECK: [2] DW_TAG_label DW_CHILDREN_yes
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: DW_AT_name DW_FORM_string
// CHECK: DW_AT_decl_file DW_FORM_data4
// CHECK: DW_AT_decl_line DW_FORM_data4
// CHECK: DW_AT_low_pc DW_FORM_addr
// CHECK: DW_AT_prototyped DW_FORM_flag
// CHECK: [3] DW_TAG_unspecified_parameters DW_CHILDREN_no
// CHECK: .debug_info contents:
// We don't check the leading addresses these are at.
// CHECK: DW_TAG_compile_unit [1] *
// CHECK: DW_AT_stmt_list [DW_FORM_data4] (0x00000000)
// CHECK: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000000)
// CHECK: DW_AT_high_pc [DW_FORM_addr] (0x0000000000000008)
// We don't check the file name as it is a temp directory
// CHECK: DW_AT_name [DW_FORM_string]
// We don't check the DW_AT_comp_dir which is the current working directory
Don't rely on a particular version string for llvm. llvm-svn: 146456
2011-12-13 01:34:14 +01:00
// CHECK: DW_AT_producer [DW_FORM_string] ("llvm-mc (based on {{.*}})")
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: DW_AT_language [DW_FORM_data2] (0x8001)
Various crash reporting tools have a problem with the dwarf generated for assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 llvm-svn: 147860
2012-01-10 18:52:29 +01:00
// CHECK: DW_TAG_label [2] *
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: DW_AT_name [DW_FORM_string] ("bar")
// CHECK: DW_AT_decl_file [DW_FORM_data4] (0x00000001)
// CHECK: DW_AT_decl_line [DW_FORM_data4] (0x00000005)
// CHECK: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000000)
// CHECK: DW_AT_prototyped [DW_FORM_flag] (0x00)
// CHECK: DW_TAG_unspecified_parameters [3]
// CHECK: NULL
Various crash reporting tools have a problem with the dwarf generated for assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 llvm-svn: 147860
2012-01-10 18:52:29 +01:00
// CHECK: DW_TAG_label [2] *
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: DW_AT_name [DW_FORM_string] ("foo")
// CHECK: DW_AT_decl_file [DW_FORM_data4] (0x00000001)
// CHECK: DW_AT_decl_line [DW_FORM_data4] (0x00000009)
// CHECK: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000007)
Various crash reporting tools have a problem with the dwarf generated for assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 llvm-svn: 147860
2012-01-10 18:52:29 +01:00
// CHECK: DW_AT_prototyped [DW_FORM_flag] (0x00)
// CHECK: DW_TAG_unspecified_parameters [3]
// CHECK: NULL
// CHECK: DW_TAG_label [2] *
// CHECK: DW_AT_name [DW_FORM_string] ("baz")
// CHECK: DW_AT_decl_file [DW_FORM_data4] (0x00000001)
// CHECK: DW_AT_decl_line [DW_FORM_data4] (0x0000000a)
// CHECK: DW_AT_low_pc [DW_FORM_addr] (0x0000000000000007)
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: DW_AT_prototyped [DW_FORM_flag] (0x00)
// CHECK: DW_TAG_unspecified_parameters [3]
// CHECK: NULL
// CHECK: NULL
// CHECK: .debug_aranges contents:
// CHECK: Address Range Header: length = 0x0000001c, version = 0x0002, cu_offset = 0x00000000, addr_size = 0x04, seg_size = 0x00
The section is .debug_line. llvm-svn: 168666
2012-11-27 02:40:36 +01:00
// CHECK: .debug_line contents:
The second part of support for generating dwarf for assembly source files. This generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each non-temporary label. The next part will be to get the clang driver to enable this when assembling a .s file. rdar://9275556 llvm-svn: 146262
2011-12-09 19:09:40 +01:00
// CHECK: Line table prologue:
// We don't check the total_length as it includes lengths of temp paths
// CHECK: version: 2
// We don't check the prologue_length as it too includes lengths of temp paths
// CHECK: min_inst_length: 1
// CHECK: default_is_stmt: 1
// CHECK: line_base: -5
// CHECK: line_range: 14
// CHECK: opcode_base: 13
// CHECK: standard_opcode_lengths[DW_LNS_copy] = 0
// CHECK: standard_opcode_lengths[DW_LNS_advance_pc] = 1
// CHECK: standard_opcode_lengths[DW_LNS_advance_line] = 1
// CHECK: standard_opcode_lengths[DW_LNS_set_file] = 1
// CHECK: standard_opcode_lengths[DW_LNS_set_column] = 1
// CHECK: standard_opcode_lengths[DW_LNS_negate_stmt] = 0
// CHECK: standard_opcode_lengths[DW_LNS_set_basic_block] = 0
// CHECK: standard_opcode_lengths[DW_LNS_const_add_pc] = 0
// CHECK: standard_opcode_lengths[DW_LNS_fixed_advance_pc] = 1
// CHECK: standard_opcode_lengths[DW_LNS_set_prologue_end] = 0
// CHECK: standard_opcode_lengths[DW_LNS_set_epilogue_begin] = 0
// CHECK: standard_opcode_lengths[DW_LNS_set_isa] = 1
// We don't check include_directories as it has a temp path
// CHECK: Dir Mod Time File Len File Name
// CHECK: ---- ---------- ---------- ---------------------------
// CHECK: file_names[ 1] 1 0x00000000 0x00000000 gen-dwarf.s
Support DWARF discriminators in object streamer. Summary: This adds support for emitting DWARF path discriminator values in the object streamer. It also changes the DWARF dumper to show discriminator values in the line table output. Reviewers: echristo CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2794 llvm-svn: 201427
2014-02-14 20:27:53 +01:00
// CHECK: Address Line Column File ISA Discriminator Flags
// CHECK: ------------------ ------ ------ ------ --- ------------- -------------
// CHECK: 0x0000000000000000 6 0 1 0 0 is_stmt
// CHECK: 0x0000000000000005 7 0 1 0 0 is_stmt
// CHECK: 0x0000000000000006 8 0 1 0 0 is_stmt
// CHECK: 0x0000000000000007 11 0 1 0 0 is_stmt
// CHECK: 0x0000000000000008 11 0 1 0 0 is_stmt end_sequence
Reference in New Issue Copy Permalink