summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
* MachineModuleInfo: Initialize DbgInfoAvailable depending on debug_cus existingMatthias Braun2018-10-311-2/+5
| | | | | | | | | | | | | | | | Before this patch DbgInfoAvailable was set to true in DwarfDebug::beginModule() or CodeViewDebug::CodeViewDebug(). This made MIR testing weird since passes would suddenly stop dealing with debug info just because we stopped the pipeline before the debug printers. This patch changes the logic to initialize DbgInfoAvailable based on the fact that debug_compile_units exist in the llvm Module. The debug printers may then override it with false in case of debug printing being disabled. Differential Revision: https://reviews.llvm.org/D53885 llvm-svn: 345740
* [Codegen] - Implement basic .debug_loclists section emission (DWARF5).George Rimar2018-10-261-51/+133
| | | | | | | | | .debug_loclists is the DWARF 5 version of the .debug_loc. With that patch, it will be emitted when DWARF 5 is used. Differential revision: https://reviews.llvm.org/D53365 llvm-svn: 345377
* DebugInfo: Explain why DW_LLE_(GNU_)startx_length is usedDavid Blaikie2018-10-251-4/+7
| | | | | | | | | | This isn't the most object-size efficient encoding, but it's the only one GDB supports for the pre-standard fission format. I've written fixes for this twice now... - so perhaps this comment will help me remember why neither of these have been committed and why I shouldn't try to write a third fix another year from now... llvm-svn: 345326
* DebugInfo: Reuse common addresses for rnglist base address selectionsDavid Blaikie2018-10-241-0/+9
| | | | | | | | | | | | | | | | | | This makes the offsets larger (since they are further from the base address) but those are in the .dwo - and allows removing addresses and relocations from the .o file. This could be built into the AddressPool more fundamentally, perhaps - when you ask for an AddressPool entry you could say "or give me some other entry and an offset I need to use" - though what to do about situations where the first use of an address in a section is not the earliest address in that section... is tricky. At least with range addresses we can be fairly sure we've seen the earliest address first because we see the start address for the function. llvm-svn: 345224
* [DWARF] Use a function-local offset for AT_call_return_pcVedant Kumar2018-10-221-3/+4
| | | | | | | | | | | | | | | | | | | Logs provided by @stella.stamenova indicate that on Linux, lldb adds a spurious slide offset to the return PC it loads from AT_call_return_pc attributes (see the list thread: "[PATCH] D50478: Add support for artificial tail call frames"). This patch side-steps the issue by getting rid of the load address calculation in lldb's CallEdge::GetReturnPCAddress. The idea is to have the DWARF writer emit function-local offsets to the instruction after a call. I.e. return-pc = label-after-call-insn - function-entry. LLDB can simply add this offset to the base address of a function to get the return PC. Differential Revision: https://reviews.llvm.org/D53469 llvm-svn: 344960
* DebugInfo: Use base address specifiers more aggressivelyDavid Blaikie2018-10-201-1/+1
| | | | | | | | | | Using a base address specifier even for a single-element range is a size win for object files (7 words versus 8 words - more significant savings if the debug info is compressed (since it's 3 words of uncompressable reloc + 4 compressable words compared to 6 uncompressable reloc + 2 compressable words) - does trade off executable size increase though. llvm-svn: 344841
* DebugInfo: Implement debug_rnglists.dwoDavid Blaikie2018-10-201-0/+26
| | | | | | | Save space/relocations in .o files by keeping dwo ranges in the dwo file rather than the .o file. llvm-svn: 344837
* DebugInfo: Use address pool forms in debug_rnglistsDavid Blaikie2018-10-201-58/+51
| | | | | | Save no relocations by reusing addresses from the address pool. llvm-svn: 344836
* DebugInfo: Use debug_addr for non-dwo addresses in DWARF 5David Blaikie2018-10-201-7/+9
| | | | | | | | Putting addresses in the address pool, even with non-fission, can reduce relocations - reusing the addresses from debug_info and debug_rnglists (the latter coming soon) llvm-svn: 344834
* Revert BTF commit series.Eli Friedman2018-10-121-10/+0
| | | | | | | | | | The initial patch was not reviewed, and does not have any tests; it should not have been merged. This reverts 344395, 344390, 344387, 344385, 344381, 344376, and 344366. llvm-svn: 344405
* [BPF] Add BTF generation for BPF targetYonghong Song2018-10-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BTF is the debug format for BPF, a kernel virtual machine and widely used for tracing, networking and security, etc ([1]). Currently only instruction streams are passed to kernel, the kernel verifier verifies them before execution. In order to provide better visibility of bpf programs to user space tools, some debug information, e.g., function names and debug line information are desirable for kernel so tools can get such information with better annotation for jited instructions for performance or other reasons. The dwarf is too complicated in kernel and for BPF. Hence, BTF is designed to be the debug format for BPF ([2]). Right now, pahole supports BTF for types, which are generated based on dwarf sections in the ELF file. In order to annotate performance metrics for jited bpf insns, it is necessary to pass debug line info to the kernel. Furthermore, we want to pass the actual code to the kernel because of the following reasons: . bpf program typically is small so storage overhead should be small. . in bpf land, it is totally possible that an application loads the bpf program into the kernel and then that application quits, so holding debug info by the user space application is not practical. . having source codes directly kept by kernel would ease deployment since the original source code does not need ship on every hosts and kernel-devel package does not need to be deployed even if kernel headers are used. The only reliable time to get the source code is during compilation time. This will result in both more accurate information and easier deployment as stated in the above. Another consideration is for JIT. The project like bcc use MCJIT to compile a C program into bpf insns and load them to the kernel ([3]). The generated BTF sections will be readily available for such cases as well. This patch implemented generation of BTF info in llvm compiler. The BTF related sections will be generated when both -target bpf and -g are specified. Two sections are generated: .BTF contains all the type and string information, and .BTF.ext contains the func_info and line_info. The separation is related to how two sections are used differently in bpf loader, e.g., linux libbpf ([4]). The .BTF section can be loaded into the kernel directly while .BTF.ext needs loader manipulation before loading to the kernel. The format of the each section is roughly defined in llvm:include/llvm/MC/MCBTFContext.h and from the implementation in llvm:lib/MC/MCBTFContext.cpp. A later example also shows the contents in each section. The type and func_info are gathered during CodeGen/AsmPrinter by traversing dwarf debug_info. The line_info is gathered in MCObjectStreamer before writing to the object file. After all the information is gathered, the two sections are emitted in MCObjectStreamer::finishImpl. With cmake CMAKE_BUILD_TYPE=Debug, the compiler can dump out all the tables except insn offset, which will be resolved later as relocation records. The debug type "btf" is used for BTFContext dump. Dwarf tests the debug info generation with llvm-dwarfdump to decode the binary sections and check whether the result is expected. Currently we do not have such a tool yet. We will implement btf dump functionality in bpftool ([5]) as the bpftool is considered the recommended tool for bpf introspection. The implementation for type and func_info is tested with linux kernel test cases. The line_info is visually checked with dump from linux kernel libbpf ([4]) and checked with readelf dumping section raw data. Note that the .BTF and .BTF.ext information will not be emitted to assembly code and there is no assembler support for BTF either. In the below, with a clang/llvm built with CMAKE_BUILD_TYPE=Debug, Each table contents are shown for a simple C program. -bash-4.2$ cat -n test.c 1 struct A { 2 int a; 3 char b; 4 }; 5 6 int test(struct A *t) { 7 return t->a; 8 } -bash-4.2$ clang -O2 -target bpf -g -mllvm -debug-only=btf -c test.c Type Table: [1] FUNC name_off=1 info=0x0c000001 size/type=2 param_type=3 [2] INT name_off=12 info=0x01000000 size/type=4 desc=0x01000020 [3] PTR name_off=0 info=0x02000000 size/type=4 [4] STRUCT name_off=16 info=0x04000002 size/type=8 name_off=18 type=2 bit_offset=0 name_off=20 type=5 bit_offset=32 [5] INT name_off=22 info=0x01000000 size/type=1 desc=0x02000008 String Table: 0 : 1 : test 6 : .text 12 : int 16 : A 18 : a 20 : b 22 : char 27 : test.c 34 : int test(struct A *t) { 58 : return t->a; FuncInfo Table: sec_name_off=6 insn_offset=<Omitted> type_id=1 LineInfo Table: sec_name_off=6 insn_offset=<Omitted> file_name_off=27 line_off=34 line_num=6 column_num=0 insn_offset=<Omitted> file_name_off=27 line_off=58 line_num=7 column_num=3 -bash-4.2$ readelf -S test.o ...... [12] .BTF PROGBITS 0000000000000000 0000028d 00000000000000c1 0000000000000000 0 0 1 [13] .BTF.ext PROGBITS 0000000000000000 0000034e 0000000000000050 0000000000000000 0 0 1 [14] .rel.BTF.ext REL 0000000000000000 00000648 0000000000000030 0000000000000010 16 13 8 ...... -bash-4.2$ The latest linux kernel ([6]) can already support .BTF with type information. The [7] has the reference implementation in linux kernel side to support .BTF.ext func_info. The .BTF.ext line_info support is not implemented yet. If you have difficulty accessing [6], you can manually do the following to access the code: git clone https://github.com/yonghong-song/bpf-next-linux.git cd bpf-next-linux git checkout btf The change will push to linux kernel soon once this patch is landed. References: [1]. https://www.kernel.org/doc/Documentation/networking/filter.txt [2]. https://lwn.net/Articles/750695/ [3]. https://github.com/iovisor/bcc [4]. https://github.com/torvalds/linux/tree/master/tools/lib/bpf [5]. https://github.com/torvalds/linux/tree/master/tools/bpf/bpftool [6]. https://github.com/torvalds/linux [7]. https://github.com/yonghong-song/bpf-next-linux/tree/btf Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Yonghong Song <yhs@fb.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Differential Revision: https://reviews.llvm.org/D52950 llvm-svn: 344366
* Revert "DwarfDebug: Pick next location in case of missing location at block ↵Matthias Braun2018-10-111-71/+41
| | | | | | | | | | | | | | | begin" It originally triggered a stepping problem in the debugger, which could be fixed by adjusting CodeGen/LexicalScopes.cpp however it seems we prefer the previous behavior anyway. See the discussion for details: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181008/593833.html This reverts commit r343880. This reverts commit r343874. llvm-svn: 344318
* [DebugInfo] Add support for DWARF5 call site-related attributesVedant Kumar2018-10-051-1/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF v5 introduces DW_AT_call_all_calls, a subprogram attribute which indicates that all calls (both regular and tail) within the subprogram have call site entries. The information within these call site entries can be used by a debugger to populate backtraces with synthetic tail call frames. Tail calling frames go missing in backtraces because the frame of the caller is reused by the callee. Call site entries allow a debugger to reconstruct a sequence of (tail) calls which led from one function to another. This improves backtrace quality. There are limitations: tail recursion isn't handled, variables within synthetic frames may not survive to be inspected, etc. This approach is not novel, see: https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf This patch adds an IR-level flag (DIFlagAllCallsDescribed) which lowers to DW_AT_call_all_calls. It adds the minimal amount of DWARF generation support needed to emit standards-compliant call site entries. For easier deployment, when the debugger tuning is LLDB, the DWARF requirement is adjusted to v4. Testing: Apart from check-{llvm, clang}, I built a stage2 RelWithDebInfo clang binary. Its dSYM passed verification and grew by 1.4% compared to the baseline. 151,879 call site entries were added. rdar://42001377 Differential Revision: https://reviews.llvm.org/D49887 llvm-svn: 343883
* DwarfDebug: Pick next location in case of missing location at block beginMatthias Braun2018-10-051-41/+71
| | | | | | | | | | | | | | | | | Context: Compiler generated instructions do not have a debug location assigned to them. However emitting 0-line records for all of them bloats the line tables for very little benefit so we usually avoid doing that. Not emitting anything will lead to the previous debug location getting applied to the locationless instructions. This is not desirable for block begin and after labels. Previously we would emit simply emit line-0 records in this case, this patch changes the behavior to do a forward search for a debug location in these cases before emitting a line-0 record to further reduce line table bloat. Inspired by the discussion in https://reviews.llvm.org/D52862 llvm-svn: 343874
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-21/+19
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [DWARF] - Emit the correct value for DW_AT_addr_base.George Rimar2018-09-201-5/+7
| | | | | | | | | | | | | | Currently, we emit DW_AT_addr_base that points to the beginning of the .debug_addr section. That is not correct for the DWARF5 case because address table contains the header and the attribute should point to the first entry following the header. This is currently the reason why LLDB does not work with such executables correctly. Patch fixes the issue. Differential revision: https://reviews.llvm.org/D52168 llvm-svn: 342635
* [DebugInfo] Fix build when std::vector::iterator is a pointerKristina Brooks2018-09-161-1/+1
| | | | | | | | | | | | std::vector::iterator type may be a pointer, then iterator::value_type fails to compile since iterator is not a class, namespace, or enumeration. Patch by orivej (Orivej Desh) Differential Revision: https://reviews.llvm.org/D52142 llvm-svn: 342354
* [DebugInfo] Do not generate label debug info if it has been processed.Hsiangkai Wang2018-09-061-29/+38
| | | | | | | | In DwarfDebug::collectEntityInfo(), if the label entity is processed in DbgLabels list, it means the label is not optimized out. There is no need to generate debug info for it with null position. llvm-svn: 341513
* [DebugInfo] Generate DWARF debug information for labels. (Fix leak problems)Hsiangkai Wang2018-08-171-45/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 340039
* DebugInfo: Remove command line (& target-based) disabling of pubnames in ↵David Blaikie2018-08-161-6/+0
| | | | | | | | | favor of metadata Now that Clang disables NVPTX pubnames via metadata there's no need for this fallback to target detection in the backend. llvm-svn: 339970
* DebugInfo: Add metadata support for disabling DWARF pub sectionsDavid Blaikie2018-08-161-18/+31
| | | | | | | | | | | | | | | | | | | | | | | In cases where the debugger load time is a worthwhile tradeoff (or less costly - such as loading from a DWP instead of a variety of DWOs (possibly over a high-latency/distributed filesystem)) against object file size, it can be reasonable to disable pubnames and corresponding gdb-index creation in the linker. A backend-flag version of this was implemented for NVPTX in D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match CUs. Now that it's going to be a user-facing option (likely powered by "-gno-pubnames", the same as GCC) it should be encoded in the DICompileUnit so it can vary per-CU. After this, likely the NVPTX support should be migrated to the metadata & the previous flag implementation should be removed. Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D50213 llvm-svn: 339939
* Revert "[DebugInfo] Generate DWARF debug information for labels. (Fix leak ↵Bruno Cardoso Lopes2018-08-141-90/+45
| | | | | | | | | | | | problems)" This reverts commit cb8c5e417d55141f3f079a8a876e786f44308336 / r339676. This causing a test to fail in http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/48406/ LLVM :: DebugInfo/Generic/debug-label.ll llvm-svn: 339700
* [DebugInfo] Generate DWARF debug information for labels. (Fix leak problems)Hsiangkai Wang2018-08-141-45/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 339676
* [DebugInfo] Fine tune emitting flags as part of the producerJonas Devlieghere2018-08-081-1/+1
| | | | | | | | | When using APPLE extensions, don't duplicate the compiler invocation's flags both in AT_producer and AT_APPLE_flags. Differential revision: https://reviews.llvm.org/D50453 llvm-svn: 339268
* [DebugInfo] Reduce debug_str_offsets section sizePavel Labath2018-08-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The accelerator tables use the debug_str section to store their strings. However, they do not support the indirect method of access that is available for the debug_info section (DW_FORM_strx et al.). Currently our code is assuming that all strings can/will be referenced indirectly, and puts all of them into the debug_str_offsets section. This is generally true for regular (unsplit) dwarf, but in the DWO case, most of the strings in the debug_str section will only be used from the accelerator tables. Therefore the contents of the debug_str_offsets section will be largely unused and bloating the main executable. This patch rectifies this by teaching the DwarfStringPool to differentiate between strings accessed directly and indirectly. When a user inserts a string into the pool it has to declare whether that string will be referenced directly or not. If at least one user requsts indirect access, that string will be assigned an index ID and put into debug_str_offsets table. Otherwise, the offset table is skipped. This approach reduces the overall binary size (when compiled with -gdwarf-5 -gsplit-dwarf) in my tests by about 2% (debug_str_offsets is shrunk by 99%). Reviewers: probinson, dblaikie, JDevlieghere Subscribers: aprantl, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D49493 llvm-svn: 339122
* [DEBUGINFO] Disable emission of the dwarf sections, but allow directives.Alexey Bataev2018-08-011-0/+23
| | | | | | | | | | | | | | | | Summary: Added an option that allows to emit only '.loc' and '.file' kind debug directives, but disables emission of the DWARF sections. Required for NVPTX target to support profiling. It requires '.loc' and '.file' directives, but does not require any DWARF sections for the profiler. Reviewers: probinson, echristo, dblaikie Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46021 llvm-svn: 338616
* [MC] Report fatal error for DWARF types for non-ELF object filesJonas Devlieghere2018-08-011-1/+3
| | | | | | | | | | | | | | Getting the DWARF types section is only implemented for ELF object files. We already disabled emitting debug types in clang (r337717), but now we also report an fatal error (rather than crashing) when trying to obtain this section in MC. Additionally we ignore the generate debug types flag for unsupported target triples. See PR38190 for more information. Differential revision: https://reviews.llvm.org/D50057 llvm-svn: 338527
* [DWARF] Basic support for producing DWARFv5 .debug_addr sectionVictor Leschuk2018-08-011-2/+7
| | | | | | | | | | | | | | This revision implements support for generating DWARFv5 .debug_addr section. The implementation is pretty straight-forward: we just check the dwarf version and emit section header if needed. Reviewers: aprantl, dblaikie, probinson Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D50005 llvm-svn: 338487
* [DWARF] Do not create a .debug_ranges section when no ranges are needed.Wolfgang Pieb2018-07-311-1/+1
| | | | | | | | Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D50089 llvm-svn: 338437
* Revert "[DebugInfo] Generate DWARF debug information for labels."Vlad Tsyrklevich2018-07-311-90/+45
| | | | | | | This reverts commits r338390 and r338398, they were causing LSan failures on the ASan bot. llvm-svn: 338408
* [DebugInfo] Generate DWARF debug information for labels.Hsiangkai Wang2018-07-311-45/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 338390
* [DWARF v5] Reposting r337981, which was reverted in r337997 due to a test ↵Wolfgang Pieb2018-07-261-47/+34
| | | | | | | | | failure in debuginfo_tests. The test failure was caused by the compiler not emitting a __debug_ranges section with DWARF 4 and earlier when no ranges are needed. The test checks for the existence regardless. llvm-svn: 338081
* dwarfgen: Add support for generating the debug_str_offsets section, take 3Pavel Labath2018-07-261-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous version of this patch failed on darwin targets because of different handling of cross-debug-section relocations. This fixes the tests to emit the DW_AT_str_offsets_base attribute correctly in both cases. Since doing this is a non-trivial amount of code, and I'm going to need it in more than one test, I've added a helper function to the dwarfgen DIE class to do it. Original commit message follows: The motivation for this is D49493, where we'd like to test details of debug_str_offsets behavior which is difficult to trigger from a traditional test. This adds the plubming necessary for dwarfgen to generate this section. The more interesting changes are: - I've moved emitStringOffsetsTableHeader function from DwarfFile to DwarfStringPool, so I can generate the section header more easily from the unit test. - added a new addAttribute overload taking an MCExpr*. This is used to generate the DW_AT_str_offsets_base, which links a compile unit to the offset table. I've also added a basic test for reading and writing DW_form_strx forms. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D49670 llvm-svn: 338031
* Revert r337981: it breaks the debuginfo-testsAlex Lorenz2018-07-261-34/+47
| | | | | | | This commit caused a regression in the debuginfo-tests: FAIL: debuginfo-tests :: apple-accel.cpp (40748 of 46595) llvm-svn: 337997
* [DWARF v5] Don't emit multiple DW_AT_rnglists_base attributes. Some ↵Wolfgang Pieb2018-07-251-47/+34
| | | | | | | | | | | | refactoring of range lists emissions and added test cases. Reviewer: dblaikie Differential Revision: https://reviews.llvm.org/D49522 llvm-svn: 337981
* Revert "dwarfgen: Add support for generating the debug_str_offsets section, ↵Pavel Labath2018-07-251-6/+4
| | | | | | | | | take 2" This reverts commit r337933. The build error is fixed but the test now fails on the darwin buildbots. Investigating... llvm-svn: 337935
* dwarfgen: Add support for generating the debug_str_offsets section, take 2Pavel Labath2018-07-251-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This recommits r337910 after fixing an "ambiguous call to addAttribute" error with some compilers (gcc circa 4.9 and MSVC). It seems that these compilers will consider a "false -> pointer" conversion during overload resolution. This creates ambiguity because one I added an overload which takes a MCExpr * as an argument. I fix this by making the new overload take MCExpr&, which avoids the conversion. It also documents the fact that we expect a valid MCExpr object. Original commit message follows: The motivation for this is D49493, where we'd like to test details of debug_str_offsets behavior which is difficult to trigger from a traditional test. This adds the plubming necessary for dwarfgen to generate this section. The more interesting changes are: - I've moved emitStringOffsetsTableHeader function from DwarfFile to DwarfStringPool, so I can generate the section header more easily from the unit test. - added a new addAttribute overload taking an MCExpr*. This is used to generate the DW_AT_str_offsets_base, which links a compile unit to the offset table. I've also added a basic test for reading and writing DW_form_strx forms. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D49670 llvm-svn: 337933
* Revert "dwarfgen: Add support for generating the debug_str_offsets section"Pavel Labath2018-07-251-6/+4
| | | | | | | | | This reverts commit r337910 as it's generating "ambiguous call to addAttribute" errors on some bots. Will resubmit once I get a chance to look into the problem. llvm-svn: 337924
* dwarfgen: Add support for generating the debug_str_offsets sectionPavel Labath2018-07-251-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The motivation for this is D49493, where we'd like to test details of debug_str_offsets behavior which is difficult to trigger from a traditional test. This adds the plubming necessary for dwarfgen to generate this section. The more interesting changes are: - I've moved emitStringOffsetsTableHeader function from DwarfFile to DwarfStringPool, so I can generate the section header more easily from the unit test. - added a new addAttribute overload taking an MCExpr*. This is used to generate the DW_AT_str_offsets_base, which links a compile unit to the offset table. I've also added a basic test for reading and writing DW_form_strx forms. Reviewers: dblaikie, JDevlieghere, probinson Subscribers: llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D49670 llvm-svn: 337910
* Revert "[DebugInfo] Generate DWARF debug information for labels."Shiva Chen2018-07-241-90/+45
| | | | | | This reverts commit b454fa1b4079b6c0a5b1565982d16516385838d7. llvm-svn: 337812
* [DebugInfo] Generate DWARF debug information for labels.Shiva Chen2018-07-241-45/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. Differential Revision: https://reviews.llvm.org/D45556 Patch by Hsiangkai Wang. llvm-svn: 337799
* DwarfDebug: Reduce duplication in addAccel*** methodsPavel Labath2018-07-201-41/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Each of the four methods had a dozen lines and was doing almost exactly the same thing: get the appropriate accelerator table kind and insert an entry into it. I move this common logic to a helper function and make these methods delegate to it. This came up in the context of D49493, where I've needed to make adding a string to a string pool slightly more complicated, and it seemed to make sense to do it in one place instead of five. To make this work I've needed to unify the interface of the AccelTable data types, as some used to store DIE& and others DIE*. I chose to unify to a reference as that's what the caller uses. This technically isn't NFC, because it changes the StringPool used for apple tables in the DWO case (now it uses the main file like DWARF v5 instead of the DWO file). However, that shouldn't matter, as DWO is not a thing on apple targets (clang frontend simply ignores -gsplit-dwarf). Reviewers: JDevlieghere, aprantl, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49542 llvm-svn: 337562
* [DebugInfo] Generate .debug_names section when it makes sensePavel Labath2018-07-201-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes us generate the debug_names section in response to some user-facing commands (previously it was only generated if explicitly selected via the -accel-tables option). My goal was to make this work for DWARF>=5 (as it's an official part of that standard), and also, as an extension, for DWARF<5 if one is explicitly tuning for lldb as a debugger (because it brings a large performance improvement there). This is slightly complicated by the fact that the debug_names tables are incompatible with the DWARF v4 type units (they assume that the type units are in the debug_info section), and unfortunately, right now we generate DWARF v4-style type units even for -gdwarf-5. For this reason, I disable all accelerator tables if the user requested type unit generation. I do this even for apple tables, as they have the same problem (in fact generating type units for apple targets makes us crash even before we get around to emitting the accelerator tables). Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49420 llvm-svn: 337544
* [DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglistsDavid Blaikie2018-07-181-10/+18
| | | | | | | | | | | | Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
* [DWARF v5] Generate range list tables into the .debug_rnglists section. No ↵Wolfgang Pieb2018-07-121-12/+97
| | | | | | | | | | | | support for split DWARF and no use of DW_FORM_rnglistx with the DW_AT_ranges attribute. Reviewer: aprantl Differential Revision: https://reviews.llvm.org/D49214 llvm-svn: 336927
* [DWARF][NFC] Refactor range list emission to use a static helperWolfgang Pieb2018-07-101-57/+59
| | | | | | | | | | | This is prep for DWARF v5 range list emission. Emission of a single range list is moved to a static helper function. Reviewer: jdevlieghere Differential Revision: https://reviews.llvm.org/D49098 llvm-svn: 336621
* [DEBUG_INFO, NVPTX] Do not emit .debug_loc section.Alexey Bataev2018-06-291-0/+5
| | | | | | | | | | | | | | | Summary: .debug_loc section is not supported for NVPTX target. If there is an object whose location can change during its lifetime, we do not generate debug location info for this variable. Reviewers: echristo Subscribers: jholewinski, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D48730 llvm-svn: 335976
* [DwarfDebug] Remove unused argument (NFC)Petar Jovanovic2018-06-281-3/+2
| | | | | | | | | | Remove unused ByteStreamer argument from function emitDebugLocValue. Patch by Nikola Prica. Differential Revision: https://reviews.llvm.org/D48590 llvm-svn: 335811
* [DWARFv5] Put the DWO ID in its place.Paul Robinson2018-05-221-5/+9
| | | | | | | | | | | | In DWARF v5, the DWO ID is in the (split/skeleton) CU header, not an attribute on the CU DIE. This changes the size of those headers, so use the parsed size whenever we have one, for simplicitly. Differential Revision: https://reviews.llvm.org/D47158 llvm-svn: 333004
* Revert "Temporarily revert "[DEBUG] Initial adaptation of NVPTX target for ↵Eric Christopher2018-05-181-7/+15
| | | | | | | | | | | | | | | debug info emission."" This reapplies commits: r330271, r330592, r330779. [DEBUG] Initial adaptation of NVPTX target for debug info emission. Summary: Patch adds initial emission of the debug info for NVPTX target. Currently, only .file and .loc directives are emitted, everything else is commented out to not break the compilation of Cuda. llvm-svn: 332689
OpenPOWER on IntegriCloud