summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* [DebugInfo] Allow creation of DBG_VALUEs in blocks where the operand is not usedJeremy Morse2019-01-161-0/+60
| | | | | | | | | | | | | dbg.value intrinsics can appear in blocks where their operand is not used, meaning the operand never receives an SDNode, and thus no DBG_VALUE will be created. Get around this by looking to see whether the operand has already been allocated a virtual register. This allows dbg.values of Phi node and Values that are used across basic blocks to successfully be translated into DBG_VALUEs. Differential Revision: https://reviews.llvm.org/D56678 llvm-svn: 351358
* [llvm-symbolizer] Add -C as a short alias to -demangleDmitry Venikov2019-01-161-0/+2
| | | | | | | | | | | | | | Summary: Provides -C as alias to -demangle. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40069. Reviewers: jhenderson, ruiu, rnk, fjricci Reviewed By: jhenderson, ruiu Subscribers: rupprecht, erik.pilkington, llvm-commits Differential Revision: https://reviews.llvm.org/D56591 llvm-svn: 351300
* [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfpMandeep Singh Grang2019-01-161-2/+2
| | | | | | | | | | | | | | | | Summary: Make recoverfp intrinsic target-independent so that it can be implemented for AArch64, etc. Refer D53541 for the context. Clang counterpart D56748. Reviewers: rnk, efriedma Reviewed By: rnk, efriedma Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D56747 llvm-svn: 351281
* [WebAssembly] Fix updating/moving DBG_VALUEs in RegStackifyYury Delendik2019-01-152-0/+125
| | | | | | | | | | | | | | Summary: As described in PR40209, there can be issues in DBG_VALUEs handling when multiple defs present in a BB. This patch adds logic for detection of related to def DBG_VALUEs and localizes register update and movement to found DBG_VALUEs. Reviewers: aheejin Subscribers: mgorny, dschuff, sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D56401 llvm-svn: 351216
* Remove irrelevant references to legacy git repositories fromJames Y Knight2019-01-1524-45/+45
| | | | | | | | | compiler identification lines in test-cases. (Doing so only because it's then easier to search for references which are actually important and need fixing.) llvm-svn: 351200
* Replace "no-frame-pointer-*" function attributes with "frame-pointer"Francis Visoiu Mistrih2019-01-149-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of the effort to refactoring frame pointer code generation. We used to use two function attributes "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" to represent three kinds of frame pointer usage: (all) frames use frame pointer, (non-leaf) frames use frame pointer, (none) frame use frame pointer. This CL makes the idea explicit by using only one enum function attribute "frame-pointer" Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such as llc. "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are still supported for easy migration to "frame-pointer". tests are mostly updated with // replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’ grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g" // replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’ grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g" Patch by Yuanfang Chen (tabloid.adroit)! Differential Revision: https://reviews.llvm.org/D56351 llvm-svn: 351049
* [DEBUGINFO][NVPTX]Make tests more strict, NFC.Alexey Bataev2019-01-095-5238/+5240
| | | | | | | NVPTX format requires that no labels/label arithmetics is used in the debug info sections. To avoid possible problems with the adding/modifying the debug info functionality, made these tests more strict. llvm-svn: 350731
* [DebugInfo] Omit location list entries with empty rangesDavid Stenberg2019-01-093-19/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR39710. In that case we emitted a location list looking like this: .Ldebug_loc0: .quad .Lfunc_begin0-.Lfunc_begin0 .quad .Lfunc_begin0-.Lfunc_begin0 .short 1 # Loc expr size .byte 85 # DW_OP_reg5 .quad .Lfunc_begin0-.Lfunc_begin0 .quad .Lfunc_end0-.Lfunc_begin0 .short 1 # Loc expr size .byte 85 # super-register DW_OP_reg5 .quad 0 .quad 0 As seen, the first entry's beginning and ending addresses evalute to 0, which meant that the entry inadvertently became an "end of list" entry, resulting in the location list ending sooner than expected. To fix this, omit all entries with empty ranges. Location list entries with empty ranges do not have any effect, as specified by DWARF, so we might as well drop them: "A location list entry (but not a base address selection or end of list entry) whose beginning and ending addresses are equal has no effect because the size of the range covered by such an entry is zero." Reviewers: davide, aprantl, dblaikie Reviewed By: aprantl Subscribers: javed.absar, JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D55919 llvm-svn: 350698
* [WebAssembly] Rename StoreResults to MemIntrinsicResultsHeejin Ahn2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | | Summary: StoreResults pass does not optimize store instructions anymore because store instructions don't return results values anymore. Now this pass is used solely for memory intrinsics, so update the pass name accordingly and fix outdated pass descriptions as well. This patch does not change any meaningful behavior, but not marked as NFC because it changes a comment check line in a test case. Reviewers: dschuff Subscribers: mgorny, sbc100, jgravelle-google, sunfiish, llvm-commits Differential Revision: https://reviews.llvm.org/D56093 llvm-svn: 350669
* Rename DIFlagFixedEnum to DIFlagEnumClass. NFCPaul Robinson2019-01-083-13/+13
| | | | llvm-svn: 350641
* [Verifier] Reject invalid type for DILocalVariable.Davide Italiano2019-01-071-1/+1
| | | | | | | | | | Reviewers: aprantl Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D56414 llvm-svn: 350578
* [codeview] Check if this 'this' type of a method is a pointerReid Kleckner2018-12-261-0/+45
| | | | | | | | | Fixes crash reported after r347354 for frontends that don't always emit 'this' pointers for methods. Now we will silently produce debug info that makes functions like this look like static methods, which seems reasonable. llvm-svn: 350073
* Revert rL350048 and rL350050Max Kazantsev2018-12-241-9/+7
| | | | | | | These patches have broken almost all buildbots on test DebugInfo/X86/addr_comments.ll. Reverting to green. llvm-svn: 350052
* DebugInfo: Use assembly label arithmetic for address pool size for easier ↵David Blaikie2018-12-241-7/+9
| | | | | | reading/editing llvm-svn: 350048
* DebugInfo: Add assembly comments for debug_addr contribution header fieldsDavid Blaikie2018-12-241-0/+33
| | | | llvm-svn: 350047
* llvm-dwarfdump: Dump the section name/number for addr attributesDavid Blaikie2018-12-224-7/+7
| | | | llvm-svn: 350009
* llvm-dwarfdump: Remove extraneous space between '(' and 'indexed'David Blaikie2018-12-2210-61/+61
| | | | | | When dumping string or address indexes llvm-svn: 349997
* llvm-dwarfdump: Print the section name/number for addr_index attributesDavid Blaikie2018-12-221-1/+1
| | | | | | (addr attributes coming shortly) llvm-svn: 349996
* Reapply: DebugInfo: Assume an absence of ranges or high_pc on a CU means the ↵David Blaikie2018-12-218-54/+26
| | | | | | | | | | | | | | | | | | | | | CU is empty (devoid of code addresses) Originally committed in r349333, reverted in r349353. GCC emitted these unconditionally on/before 4.4/March 2012 Clang emitted these unconditionally on/before 3.5/March 2014 This improves performance when parsing CUs (especially those using split DWARF) that contain no code ranges (such as the mini CUs that may be created by ThinLTO importing - though generally they should be/are avoided, especially for Split DWARF because it produces a lot of very small CUs, which don't scale well in a bunch of other ways too (including size)). The revert was due to a (Google internal) test that had some checked in old object files missing DW_AT_ranges. That's since been fixed. llvm-svn: 349968
* [Dwarf/AArch64] Return address signing B key dwarf supportLuke Cheeseman2018-12-211-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | - When signing return addresses with -msign-return-address=<scope>{+<key>}, either the A key instructions or the B key instructions can be used. To correctly authenticate the return address, the unwinder/debugger must know which key was used to sign the return address. - When and exception is thrown or a break point reached, it may be necessary to unwind the stack. To accomplish this, the unwinder/debugger must be able to first authenticate an the return address if it has been signed. - To enable this, the augmentation string of CIEs has been extended to allow inclusion of a 'B' character. Functions that are signed using the B key variant of the instructions should have and FDE whose associated CIE has a 'B' in the augmentation string. - One must also be able to preserve these semantics when first stepping from a high level language into assembly and then, as a second step, into an object file. To achieve this, I have introduced a new assembly directive '.cfi_b_key_frame ', that tells the assembler the current frame uses return address signing with the B key. - This ensures that the FDE is associated with a CIE that has 'B' in the augmentation string. Differential Revision: https://reviews.llvm.org/D51798 llvm-svn: 349895
* DebugInfo: Fix for missing comp_dir handling with r349207David Blaikie2018-12-201-0/+32
| | | | | | | | | | | When deciding lazily whether a CU would be split or non-split I accidentally dropped some handling for the line tables comp_dir (by doing it lazily it was too late to be handled properly by the MC line table code). Move that bit of the code back to the non-lazy place. llvm-svn: 349819
* [CodeView] Emit global variables within lexical scopes to limit visibilityBrock Wyma2018-12-202-41/+317
| | | | | | | | | Emit static locals within the correct lexical scope so variables with the same name will not confuse the debugger into getting the wrong value. Differential Revision: https://reviews.llvm.org/D55336 llvm-svn: 349777
* DebugInfo: Fix missing local imported entities after r349207David Blaikie2018-12-181-0/+33
| | | | | | Post commit review/bug reported by Pavel Labath - thanks! llvm-svn: 349528
* [codeview] Align symbol records to save 441MB during linking clang.pdbReid Kleckner2018-12-188-46/+64
| | | | | | | | | | | | | | | | | | | | In PDBs, symbol records must be aligned to four bytes. However, in the object file, symbol records may not be aligned. MSVC does not pad out symbol records to make sure they are aligned. That means the linker has to do extra work to insert the padding. Currently, LLD calculates the required space with alignment, and copies each record one at a time while padding them out to the correct size. It has a fast path that avoids this copy when the records are already aligned. This change fixes a bug in that codepath so that the copy is actually saved, and tweaks LLVM's symbol record emission to align symbol records. Here's how things compare when doing a plain clang Release+PDB build: - objs are 0.65% bigger (negligible) - link is 3.3% faster (negligible) - saves allocating 441MB - new LLD high water mark is ~1.05GB llvm-svn: 349431
* Recommit r348806: DebugInfo: Use symbol difference for CU length to simplify ↵David Blaikie2018-12-181-0/+30
| | | | | | | | | | | | | | assembly reading/editing Mucking about simplifying a test case ( https://reviews.llvm.org/D55261 ) I stumbled across something I've hit before - that LLVM's (GCC's does too, FWIW) assembly output includes a hardcode length for a DWARF unit in its header. Instead we could emit a label difference - making the assembly easier to read/edit (though potentially at a slight (I haven't tried to observe it) performance cost of delaying/sinking the length computation into the MC layer). Fix: Predicated all the changes (including creating the labels, even if they aren't used/needed) behind the NVPTX useSectionsAsReferences, avoiding emitting labels in NVPTX where ptxas can't parse them. Reviewers: JDevlieghere, probinson, ABataev Differential Revision: https://reviews.llvm.org/D55281 llvm-svn: 349430
* Revert "DebugInfo: Assume an absence of ranges or high_pc on a CU means the ↵Eric Liu2018-12-178-26/+54
| | | | | | | | | CU is empty (devoid of code addresses)" This reverts commit r349333. It caused internal test to fail. I have sent more information to the author. llvm-svn: 349353
* DebugInfo: Assume an absence of ranges or high_pc on a CU means the CU is ↵David Blaikie2018-12-178-54/+26
| | | | | | | | | | | | | | | | empty (devoid of code addresses) GCC emitted these unconditionally on/before 4.4/March 2012 Clang emitted these unconditionally on/before 3.5/March 2014 This improves performance when parsing CUs (especially those using split DWARF) that contain no code ranges (such as the mini CUs that may be created by ThinLTO importing - though generally they should be/are avoided, especially for Split DWARF because it produces a lot of very small CUs, which don't scale well in a bunch of other ways too (including size)). llvm-svn: 349333
* DebugInfo: Avoid using split DWARF when the split unit would be empty.David Blaikie2018-12-144-35/+35
| | | | | | | | | | | | | | | | | | | | | In ThinLTO many split CUs may be effectively empty because of the lack of support for cross-unit references in split DWARF. Using a split unit in those cases is just a waste/overhead - and turned out to be one contributor to a significant symbolizer performance issue when global variable debug info was being imported (see r348416 for the primary fix) due to symbolizers seeing CUs with no ranges, assuming there might still be addresses covered and walking into the split CU to see if there are any ranges (when that split CU was in a DWP file, that meant loading the DWP and its index, the index was extra large because of all these fractured/empty CUs... and so was very expensive to load). (the 3rd fix which will follow, is to assume that a CU with no ranges is empty rather than merely missing its CU level range data - and to not walk into its DIEs (split or otherwise) in search of address information that is generally not present) llvm-svn: 349207
* [codeview] Look through typedefs in getCompleteTypeIndexReid Kleckner2018-12-111-0/+72
| | | | | | | | | | | | | | | | | Summary: Any time a symbol record, whether it's S_UDT, S_LOCAL, or S_[GL]DATA32, references a record type, it should use the complete type index, even if there's a typedef in the way. Fixes the compiler part of PR39853. Reviewers: zturner, aganea Subscribers: hiraditya, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D55236 llvm-svn: 348902
* Revert "debuginfo: Use symbol difference for CU length to simplify assembly ↵Jordan Rupprecht2018-12-111-9/+2
| | | | | | | | reading/editing" Temporarily reverts commit r348806 due to strange asm compilation issues in certain modes (combination of asan+cuda+other things). Will provide repro soon. llvm-svn: 348898
* [Debuginfo] Prevent CodeGenPrepare from dropping debuginfo references.Wolfgang Pieb2018-12-111-0/+75
| | | | | | | | | | | | | | This fixes PR39845. CodeGenPrepare employs a transactional model when performing optimizations, i.e. it changes the IR to attempt an optimization and rolls back the change when it finds the change inadequate. It is during the rollback that references to locals were dropped from debug value intrinsics. This patch reinstates debuginfo references during rollbacks. Reviewers: aprantl, vsk Differential Revision: https://reviews.llvm.org/D55396 llvm-svn: 348896
* debuginfo: Use symbol difference for CU length to simplify assembly ↵David Blaikie2018-12-101-2/+9
| | | | | | | | | | | | reading/editing Mucking about simplifying a test case ( https://reviews.llvm.org/D55261 ) I stumbled across something I've hit before - that LLVM's (GCC's does too, FWIW) assembly output includes a hardcode length for a DWARF unit in its header. Instead we could emit a label difference - making the assembly easier to read/edit (though potentially at a slight (I haven't tried to observe it) performance cost of delaying/sinking the length computation into the MC layer). Reviewers: JDevlieghere, probinson, ABataev Differential Revision: https://reviews.llvm.org/D55281 llvm-svn: 348806
* [DebugInfo] Don't drop dbg.value's of nullptrJeremy Morse2018-12-101-6/+3
| | | | | | | | | | | | | | | | | | | Currently, dbg.value's of "nullptr" are dropped when entering a SelectionDAG -- apparently just because of an oversight when recognising Values that are constant (see PR39787). This patch adds ConstantPointerNull to the list of constants that can be turned into DBG_VALUEs. The matter of what bit-value a null pointer constant in LLVM has was raised in this mailing list thread: http://lists.llvm.org/pipermail/llvm-dev/2018-December/128234.html Where it transpires LLVM relies on (IR) null pointers being zero valued, thus I've baked this assumption into the patch. Differential Revision: https://reviews.llvm.org/D55227 llvm-svn: 348753
* [DebugInfo] Emit undef DBG_VALUEs when SDNodes are optimised outJeremy Morse2018-12-103-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR39896, where dbg.value's of SDNodes that have been optimised out do not lead to "DBG_VALUE undef" instructions being created. Such undef instructions are necessary to terminate earlier variable ranges, otherwise variable values leak past the point where they're valid. The "invalidated" flag of SDDbgValue is currently being abused to mean two things: * The corresponding SDNode is now invalid * This SDDbgValue should not be emitted Of which there are several legitimate combinations of meaning: * The SDNode has been invalidated and we should emit "DBG_VALUE undef" * The SDNode has been invalidated but the debug data was salvaged, don't emit anything for this SDDbgValue * This SDDbgValue has been emitted This patch introduces distinct "Emitted" and "Invalidated" fields to the SDDbgValue class, updates users accordingly, and generates "undef" DBG_VALUEs for invalidated records. Awkwardly, there are circumstances where we emit SDDbgValue's twice, specifically DebugInfo/X86/dbg-addr-dse.ll which I've preserved. Differential Revision: https://reviews.llvm.org/D55372 llvm-svn: 348751
* Support skewed stream arrays.Zachary Turner2018-12-061-30/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VarStreamArray was built on the assumption that it is backed by a StreamRef, and offset 0 of that StreamRef is the first byte of the first record in the array. This is a logical and intuitive assumption, but unfortunately we have use cases where it doesn't hold. Specifically, a PDB module's symbol stream is prefixed by 4 bytes containing a magic value, and the first byte of record data in the array is actually at offset 4 of this byte sequence. Previously, we would just truncate the first 4 bytes and then construct the VarStreamArray with the resulting StreamRef, so that offset 0 of the underlying stream did correspond to the first byte of the first record, but this is problematic, because symbol records reference other symbol records by the absolute offset including that initial magic 4 bytes. So if another record wants to refer to the first record in the array, it would say "the record at offset 4". This led to extremely confusing hacks and semantics in loading code, and after spending 30 minutes trying to get some math right and failing, I decided to fix this in the underlying implementation of VarStreamArray. Now, we can say that a stream is skewed by a particular amount. This way, when we access a record by absolute offset, we can use the same values that the records themselves contain, instead of having to do fixups. Differential Revision: https://reviews.llvm.org/D55344 llvm-svn: 348499
* [DEBUGINFO, NVPTX] Disable emission of ',debug' option if only debug ↵Alexey Bataev2018-12-061-1/+1
| | | | | | | | | | | | | | | | | directives are allowed. Summary: If the output of debug directives only is requested, we should drop emission of ',debug' option from the target directive. Required for supporting of nvprof profiler. Reviewers: echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46061 llvm-svn: 348497
* [DEBUGINFO, NVPTX]Emit last debugging directives.Alexey Bataev2018-12-061-0/+48
| | | | | | | | | | | | | | | Summary: We may end up with not emitted debug directives at the end of the module emission. Patch fixes this problem emitting those last directives the end of the module emission. Reviewers: echristo Subscribers: jholewinski, llvm-commits Differential Revision: https://reviews.llvm.org/D54320 llvm-svn: 348495
* Revert "[BTF] Add BTF DebugInfo"Yonghong Song2018-11-3038-2617/+0
| | | | | | This reverts commit 9c6b970db8bc63b28ce58a129bb1580a6a3c6caf. llvm-svn: 348004
* [BTF] Add BTF DebugInfoYonghong Song2018-11-3038-0/+2617
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds BPF Debug Format (BTF) as a standalone LLVM debuginfo. The BTF related sections are directly generated from IR. The BTF debuginfo is generated only when the compilation target is BPF. What is BTF? ============ First, the BPF is a linux kernel virtual machine and widely used for tracing, networking and security. https://www.kernel.org/doc/Documentation/networking/filter.txt https://cilium.readthedocs.io/en/v1.2/bpf/ BTF is the debug info format for BPF, introduced in the below linux patch https://github.com/torvalds/linux/commit/69b693f0aefa0ed521e8bd02260523b5ae446ad7#diff-06fb1c8825f653d7e539058b72c83332 in the patch set mentioned in the below lwn article. https://lwn.net/Articles/752047/ The BTF format is specified in the above github commit. In summary, its layout looks like struct btf_header type subsection (a list of types) string subsection (a list of strings) With such information, the kernel and the user space is able to pretty print a particular bpf map key/value. One possible example below: Withtout BTF: key: [ 0x01, 0x01, 0x00, 0x00 ] With BTF: key: struct t { a : 1; b : 1; c : 0} where struct is defined as struct t { char a; char b; short c; }; How BTF is generated? ===================== Currently, the BTF is generated through pahole. https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=68645f7facc2eb69d0aeb2dd7d2f0cac0feb4d69 and available in pahole v1.12 https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=4a21c5c8db0fcd2a279d067ecfb731596de822d4 Basically, the bpf program needs to be compiled with -g with dwarf sections generated. The pahole is enhanced such that a .BTF section can be generated based on dwarf. This format of the .BTF section matches the format expected by the kernel, so a bpf loader can just take the .BTF section and load it into the kernel. https://github.com/torvalds/linux/commit/8a138aed4a807ceb143882fb23a423d524dcdb35 The .BTF section layout is also specified in this patch: with file include/llvm/BinaryFormat/BTF.h. What use cases this patch tries to address? =========================================== Currently, only the bpf instruction stream is required to pass to the kernel. The kernel verifies it, jits it if configured to do so, attaches it to a particular kernel attachment point, and later executes when a particular event happens. This patch tries to expand BTF to support two more use cases below: (1). BPF supports subroutine calls. During performance analysis, it would be good to differentiate which call is hot instead of just providing a virtual address. This would require to pass a unique identifier for each subroutine to the kernel, the subroutine name is a natual choice. (2). If a particular jitted instruction is hot, we want user to know which source line this jitted instruction belongs to. This would require the source information is available to various profiling tools. Note that in a single ELF file, . there may be multiple loadable bpf programs, . for a particular to-be-loaded bpf instruction stream, its instructions may come from multiple PROGBITS sections, the bpf loader needs to merge them together to a single consecutive insn stream before loading to the kernel. For example: section .text: subroutines funcFoo section _progA: calling funcFoo section _progB: calling funcFoo The bpf loader could construct two loadable bpf instruction streams and load them into the kernel: . _progA funcFoo . _progB funcFoo So per ELF section function offset and instruction offset will need to be adjusted before passing to the kernel, and the kernel essentially expect only one code section regardless of how many in the ELF file. What do we propose and Why? =========================== To support the above two use cases, we propose to add an additional section, .BTF.ext, to the ELF file which is the input of the bpf loader. A different section is preferred since loader may need to manipulate it before loading part of its data to the kernel. The .BTF.ext section has a similar header to the .BTF section and it contains two subsections for func_info and line_info. . the func_info maps the func insn byte offset to a func type in the .BTF type subsection. . the line_info maps the insn byte offset to a line info. . both func_info and line_info subsections are organized by ELF PROGBITS AX sections. pahole is not a good place to implement .BTF.ext as pahole is mostly for structure hole information and more importantly, we want to pass the actual code to the kernel. . 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 as you may not even know who loads this bpf program. . 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. LLVM is a good place to implement. . 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 (https://github.com/iovisor/bcc) use MCJIT to compile a C program into bpf insns and load them to the kernel. The llvm generated BTF sections will be readily available for such cases as well. Design and implementation of emiting .BTF/.BTF.ext sections =========================================================== The BTF debuginfo format is defined. Both .BTF and .BTF.ext sections are generated directly from IR when both "-target bpf" and "-g" are specified. Note that dwarf sections are still generated as dwarf is used by user space tools like llvm-objdump etc. for BPF target. This patch also contains tests to verify generated .BTF and .BTF.ext sections for all supported types, func_info and line_info subsections. The patch is also tested against linux kernel bpf sample tests and selftests. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D53736 llvm-svn: 347999
* [DebugInfo] IR/Bitcode changes for DISubprogram flags.Paul Robinson2018-11-282-4/+4
| | | | | | | | | Packing the flags into one bitcode word will save effort in adding new flags in the future. Differential Revision: https://reviews.llvm.org/D54755 llvm-svn: 347806
* [CodeView] Add support for ref-qualified member functions.Zachary Turner2018-11-201-0/+205
| | | | | | | | | | | | | | | | | | | | | | When you have a member function with a ref-qualifier, for example: struct Foo { void Func() &; void Func2() &&; }; clang-cl was not emitting this information. Doing so is a bit awkward, because it's not a property of the LF_MFUNCTION type, which is what you'd expect. Instead, it's a property of the this pointer which is actually an LF_POINTER. This record has an attributes bitmask on it, and our handling of this bitmask was all wrong. We had some parts of the bitmask defined incorrectly, but importantly for this bug, we didn't know about these extra 2 bits that represent the ref qualifier at all. Differential Revision: https://reviews.llvm.org/D54667 llvm-svn: 347354
* [CodeView] Mark this pointers as const.Zachary Turner2018-11-2010-49/+77
| | | | | | | | | | | This is for compatibility with MSVC, which also marks this pointers as being const-qualified. Fixes llvm.org/pr36526 Differential Revision: https://reviews.llvm.org/D54736 llvm-svn: 347353
* [CodeView] Don't print PointerAttributes when dumping.Zachary Turner2018-11-2010-36/+0
| | | | | | | | PointerAttributes is a bitwise-or of several other fields, each of which is already printed on its own line with a better explanation. So this doesn't really help much. llvm-svn: 347275
* [codeview] Expose -gcodeview-ghash for global type hashingReid Kleckner2018-11-161-4/+5
| | | | | | | | | | | | | | | | | | | | | Summary: Experience has shown that the functionality is useful. It makes linking optimized clang with debug info for me a lot faster, 20s to 13s. The type merging phase of PDB writing goes from 10s to 3s. This removes the LLVM cl::opt and replaces it with a metadata flag. After this change, users can do the following to use ghash: - add -gcodeview-ghash to compiler flags - replace /DEBUG with /DEBUG:GHASH in linker flags Reviewers: zturner, hans, thakis, takuto.ikuta Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D54370 llvm-svn: 347072
* Bias physical register immediate assignmentsNirav Dave2018-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
* [AsmPrinter] Fix DebugInfo/X86/gnu-public-names.ll after rL346790Fangrui Song2018-11-131-1/+1
| | | | llvm-svn: 346797
* [AsmPrinter] Rename a comment of .debug_gnu_pubnames entryFangrui Song2018-11-131-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: The comment refers to the field as "Kind:". However, in gdb, https://sourceware.org/gdb//onlinedocs/gdb/Index-Section-Format.html names it "attributes", gdb/dwarf2read.c:dw2_symtab_iter_next refers to the whole value as "cu_index_and_attrs" Change it to `Attributes:` for consistency. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: aprantl, JDevlieghere, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54480 llvm-svn: 346790
* DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address ↵David Blaikie2018-11-131-67/+103
| | | | | | | | | | | | | | | | | | | | | | | | | specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
* [DWARF] Change pubnames to use DWARFSection instead of StringRefFangrui Song2018-11-111-0/+35
| | | | | | | | | | | | | | Summary: The debug_info_offset values in .debug_{,gnu_}pub{name,types} may be relocated. Change it to DWARFSection so that we can get relocated values. Reviewers: ruiu, dblaikie, grimar, JDevlieghere Reviewed By: JDevlieghere Subscribers: aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D54375 llvm-svn: 346615
* [DWARFv5] Emit normal type units in .debug_info comdats.Paul Robinson2018-11-091-27/+28
| | | | | | Differential Revision: https://reviews.llvm.org/D54282 llvm-svn: 346540
OpenPOWER on IntegriCloud