summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
* Testing commit access through minor formatting changeNilanjana Basu2019-07-011-2/+3
| | | | llvm-svn: 364843
* [DWARF] Handle the DW_OP_entry_value operandDjordje Todorovic2019-06-276-5/+53
| | | | | | | | | | | | | | | Add the IR and the AsmPrinter parts for handling of the DW_OP_entry_values DWARF operation. ([11/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60866 llvm-svn: 364542
* [IR] Add DISuprogram and DIE for a func declDjordje Todorovic2019-06-271-0/+5
| | | | | | | | | | | | | | | A unique DISubprogram may be attached to a function declaration used for call site debug info. ([6/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60713 llvm-svn: 364500
* CodeGen: Introduce a class for registersMatt Arsenault2019-06-241-2/+2
| | | | | | | | | Avoids using a plain unsigned for registers throughoug codegen. Doesn't attempt to change every register use, just something a little more than the set needed to build after changing the return type of MachineOperand::getReg(). llvm-svn: 364191
* Store a pointer to the return value in a static alloca and let the debugger ↵Amy Huang2019-06-201-2/+12
| | | | | | | | | | | | | | use that as the variable address for NRVO variables. Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63361 llvm-svn: 363952
* hwasan: Add a tag_offset DWARF attribute to instrumented stack variables.Peter Collingbourne2019-06-173-0/+8
| | | | | | | | | | | | | | | | | | | | | | | The goal is to improve hwasan's error reporting for stack use-after-return by recording enough information to allow the specific variable that was accessed to be identified based on the pointer's tag. Currently we record the PC and lower bits of SP for each stack frame we create (which will eventually be enough to derive the base tag used by the stack frame) but that's not enough to determine the specific tag for each variable, which is the stack frame's base tag XOR a value (the "tag offset") that is unique for each variable in a function. In IR, the tag offset is most naturally represented as part of a location expression on the llvm.dbg.declare instruction. However, the presence of the tag offset in the variable's actual location expression is likely to confuse debuggers which won't know about tag offsets, and moreover the tag offset is not required for a debugger to determine the location of the variable on the stack, so at the DWARF level it is represented as an attribute so that it will be ignored by debuggers that don't know about it. Differential Revision: https://reviews.llvm.org/D63119 llvm-svn: 363635
* DebugInfo: Include enumerators in pubnamesDavid Blaikie2019-06-141-0/+5
| | | | | | | | | | | This is consistent with GCC's behavior (which is the defacto standard for pubnames). Though I find the presence of enumerators from enum classes to be a bit confusing, possibly a bug on GCC's end (since they can't be named unqualified, unlike the other names - and names nested in classes don't go in pubnames, for instance - presumably because one must name the class first & that's enough to limit the scope of the search) llvm-svn: 363349
* Use fully qualified name when printing S_CONSTANT recordsAmy Huang2019-06-131-4/+5
| | | | | | | | | | | | | | | | Summary: Before it was using the fully qualified name only for static data members. Now it does for all variable names to match MSVC. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63012 llvm-svn: 363335
* [DebugInfo] Move Value struct out of DebugLocEntry as DbgValueLoc (NFC)Nikola Prica2019-06-133-106/+102
| | | | | | | | | | | | | Since the DebugLocEntry::Value is used as part of DwarfDebug and DebugLocEntry make it as the separate class. Reviewers: aprantl, dstenb Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D63213 llvm-svn: 363246
* [DebugInfo] Use FrameDestroy to extend stack locations to end-of-functionJeremy Morse2019-06-131-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | We aim to ignore changes in variable locations during the prologue and epilogue of functions, to avoid using space documenting location changes that aren't visible. However in D61940 / r362951 this got ripped out as the previous implementation was unsound. Instead, use the FrameDestroy flag to identify when we're in the epilogue of a function, and ignore variable location changes accordingly. This fits in with existing code that examines the FrameSetup flag. Some variable locations get shuffled in modified tests as they now cover greater ranges, which is what would be expected. Some additional single-location variables are generated too. Two tests are un-xfailed, they were only xfailed due to r362951 deleting functionality they depended on. Apparently some out-of-tree backends don't accurately maintain FrameDestroy flags -- if you're an out-of-tree maintainer and see changes in variable locations disappear due to a faulty FrameDestroy flag, it's safe to back this change out. The impact is just slightly more debug info than necessary. Differential Revision: https://reviews.llvm.org/D62314 llvm-svn: 363245
* [DebugInfo] Terminate all location-lists at end of blockJeremy Morse2019-06-101-105/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reapplies r359426 (which was reverted in r360301 due to performance problems) and rolls in D61940 to address the performance problem. I've combined the two to avoid creating a span of slow-performance, and to ease reverting if more problems crop up. The summary of D61940: This patch removes the "ChangingRegs" facility in DbgEntityHistoryCalculator, as its overapproximate nature can produce incorrect variable locations. An unchanging register doesn't mean a variable doesn't change its location. The patch kills off everything that calculates the ChangingRegs vector. Previously ChangingRegs spotted epilogues and marked registers as unchanging if they weren't modified outside the epilogue, increasing the chance that we can emit a single-location variable record. Without this feature, debug-loc-offset.mir and pr19307.mir become temporarily XFAIL. They'll be re-enabled by D62314, using the FrameDestroy flag to identify epilogues, I've split this into two steps as FrameDestroy isn't necessarily supported by all backends. The logic for terminating variable locations at the end of a basic block now becomes much more enjoyably simple: we just terminate them all. Other test changes: inlined-argument.ll becomes XFAIL, but for a longer term. The current algorithm for detecting that a variable has a single-location doesn't work in this scenario (inlined function in multiple blocks), only other bugs were making this test work. fission-ranges.ll gets slightly refreshed too, as the location of "p" is now correctly determined to be a single location. Differential Revision: https://reviews.llvm.org/D61940 llvm-svn: 362951
* [DebugInfo] More strict debug range for stack variablesNikola Prica2019-06-106-128/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | Variable's stack location can stretch longer than it should. If a variable is placed at the stack in a some nested basic block its range can be calculated to be up to the next occurrence of the variable's DBG_VALUE, or up to the end of the function, thus covering a basic blocks that should not be included in the variable’s location range. This happens because the DbgEntityHistoryCalculator ends register locations at the end of a basic block only if the variable’s location register has been changed throughout the function, which is not the case for the register used to reference stack objects. This patch also tries to produce a single value location if the location list builder managed to merge all the locations into one. Reviewers: aprantl, dstenb, jmorse Reviewed By: aprantl, dstenb, jmorse Subscribers: djtodoro, ivanbaev, asowda Tags: #debug-info Differential Revision: https://reviews.llvm.org/D61600 llvm-svn: 362923
* [Remarks][NFC] Move the serialization to lib/RemarksFrancis Visoiu Mistrih2019-05-301-10/+16
| | | | | | | | | | | | Separate the remark serialization to YAML from the LLVM Diagnostics. This adds a new serialization abstraction: remarks::Serializer. It's completely independent from lib/IR and it provides an easy way to replace YAML by providing a new remarks::Serializer. Differential Revision: https://reviews.llvm.org/D62632 llvm-svn: 362160
* CodeView - add static data members to global variable debug info.Amy Huang2019-05-291-1/+6
| | | | | | | | | | | | | | | | | | Summary: Add static data members to IR debug info's list of global variables so that they are emitted as S_CONSTANT records. Related to https://bugs.llvm.org/show_bug.cgi?id=41615. Reviewers: rnk Subscribers: aprantl, cfe-commits, llvm-commits, thakis Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62167 llvm-svn: 362038
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-291-0/+18
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* Stop undef fragments from closing non-overlapping fragmentsDavid Stenberg2019-05-282-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When DwarfDebug::buildLocationList() encountered an undef debug value, it would truncate all open values, regardless if they were overlapping or not. This patch fixes so that it only does that for overlapping fragments. This change unearthed a bug that I had introduced in D57511, which I have fixed in this patch. The code in DebugHandlerBase that changes labels for parameter debug values could break DwarfDebug's assumption that the labels for the entries in the debug value history are monotonically increasing. Before this patch, that bug could result in location list entries whose ending address was lower than the beginning address, and with the changes for undef debug values that this patch introduces it could trigger an assertion, due to attempting to emit location list entries with empty ranges. A reproducer for the bug is added in param-reg-const-mix.mir. Reviewers: aprantl, jmorse, probinson Reviewed By: aprantl Subscribers: javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D62379 llvm-svn: 361820
* [AsmPrinter] Treat a narrowing PtrToInt like TruncShoaib Meenai2019-05-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When printing assembly for PtrToInt, AsmPrinter::lowerConstant incorrectly assumed that if PtrToInt was not converting to an int with exactly the same number of bits, it must be widening to a larger int. But this isn't necessarily true; PtrToInt can also shrink the size, which is useful when you want to produce a known 32-bit pointer on a 64-bit platform (on x86_64 ELF this yields a R_X86_64_32 relocation). The old behavior of falling through to the widening case for a narrowing PtrToInt yields bogus assembly code like this, which fails to assemble because the no-op bit and it accidentally creates is not a valid relocation: ``` .long a&-1 ``` The fix is to treat a narrowing PtrToInt exactly the same as it already treats Trunc: just emit the expression and let the assembler deal with truncating it in the appropriate way. Patch by Mat Hostetter <mjh@fb.com>. Differential Revision: https://reviews.llvm.org/D61325 llvm-svn: 361508
* [DwarfExpression] Refactor dwarf expression (NFC)Petar Jovanovic2019-05-232-23/+44
| | | | | | | | | | | | Refactor location description kind in order to be easier for extensions (needed for D60866). In addition, cut off some bits from the other class fields. Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D62002 llvm-svn: 361480
* Emit global variables as S_CONSTANT records for codeview debug info.Amy Huang2019-05-162-34/+72
| | | | | | | | | | | | | | | | | | | | Summary: This emits S_CONSTANT records for global variables. Currently this emits records for the global variables already being tracked in the LLVM IR metadata, which are just constant global variables; we'll also want S_CONSTANTs for static data members and enums. Related to https://bugs.llvm.org/show_bug.cgi?id=41615 Reviewers: rnk Subscribers: aprantl, hiraditya, llvm-commits, thakis Tags: #llvm Differential Revision: https://reviews.llvm.org/D61926 llvm-svn: 360948
* [codeview] Fix SDNode representation of annotation labelsReid Kleckner2019-05-151-0/+1
| | | | | | | | | | | Before this change, they were erroneously constructed with the EH_LABEL SDNode opcode, which caused other passes to interact with them in incorrect ways. See the FIXME about fastisel that this addresses in the existing test case. Fixes PR41890 llvm-svn: 360818
* [IR] Disallow llvm.global_ctors and llvm.global_dtors of the 2-field form in ↵Fangrui Song2019-05-151-8/+6
| | | | | | | | | | | | | | | | | | | | textual format The 3-field form was introduced by D3499 in 2014 and the legacy 2-field form was planned to be removed in LLVM 4.0 For the textual format, this patch migrates the existing 2-field form to use the 3-field form and deletes the compatibility code. test/Verifier/global-ctors-2.ll checks we have a friendly error message. For bitcode, lib/IR/AutoUpgrade UpgradeGlobalVariables will upgrade the 2-field form (add i8* null as the third field). Reviewed By: rnk, dexonsmith Differential Revision: https://reviews.llvm.org/D61547 llvm-svn: 360742
* DWARF v5: emit DW_AT_addr_base if DW_AT_low_pc references .debug_addrFangrui Song2019-05-141-7/+7
| | | | | | | | | | | | | | | | The condition !AddrPool.empty() is tested before attachRangesOrLowHighPC(), which may add an entry to AddrPool. We emit DW_AT_low_pc (DW_FORM_addrx) but may incorrectly omit DW_AT_addr_base for LineTablesOnly. This can be easily reproduced: clang -gdwarf-5 -gmlt -c a.cc Fix this by moving !AddrPool.empty() below. This was discovered while investigating an lld crash (fixed by D61889) on such object files: ld.lld --gdb-index a.o Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D61891 llvm-svn: 360678
* DebugInfo: Only move types out of type units if they're named or type unitedDavid Blaikie2019-05-101-1/+2
| | | | | | | | | | | | | | | | | | Follow up to r359122, after a bug was reported in it - the original change too aggressively tried to move related types out of type units, which included unnamed types (like array types) which can't reasonably be declared-but-not-defined. A step beyond that is that some types in type units can be anonymous, if they are types with a name for linkage purposes (eg: "typedef struct { } x;"). So ensure those don't get turned into plain declarations (without signatures) because, lacking names, they can't be resolved to the definition. [Also include a fix for llvm-dwarfdump/libDebugInfoDWARF to pretty print types in type units] llvm-svn: 360458
* Temporarily Revert "[DebugInfo] Terminate more location-list ranges at the ↵Eric Christopher2019-05-081-35/+9
| | | | | | | | | | end of blocks" as it was causing significant compile time regressions. This reverts commit r359426 while we come up with testcases and additional ideas. llvm-svn: 360301
* Debug Info: Support address space attributes on rvalue references.Adrian Prantl2019-05-071-4/+4
| | | | | | | | | | | | | | | | | | | DWARF5, 2.12 20ff says that Any debugging information entry representing a pointer or reference type [may have a DW_AT_address_class attribute]. The existing code (https://reviews.llvm.org/D29670) seems to take a quite literal interpretation of that wording. I don't see a reason why an rvalue reference isn't a reference type in the spirit of that paragraph. This patch allows rvalue references to also have address spaces. rdar://problem/50511483 Differential Revision: https://reviews.llvm.org/D61625 llvm-svn: 360176
* [DebugInfo] Delete TypedDINodeRefFangrui Song2019-05-078-105/+72
| | | | | | | | | | | | | TypedDINodeRef<T> is a redundant wrapper of Metadata * that is actually a T *. Accordingly, change DI{Node,Scope,Type}Ref uses to DI{Node,Scope,Type} * or their const variants. This allows us to delete many resolve() calls that clutter the code. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D61369 llvm-svn: 360108
* Fix bug in getCompleteTypeIndex in codeview debug infoAmy Huang2019-05-061-4/+7
| | | | | | | | | | | | | | | | Summary: When there are multiple instances of a forward decl record type, only the first one is emitted with a type index, because the type is added to a map with a null type index. Avoid this by reordering so that forward decl types aren't added to the map. Reviewers: rnk Subscribers: aprantl, hiraditya, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61460 llvm-svn: 360101
* [AArch64][Windows] Compute function length correctly in unwind tables.Eli Friedman2019-05-032-3/+19
| | | | | | | | | | | | | | | | | | | | | | The primary fix here is to WinException.cpp: we need to exclude jump tables when computing the length of a function, or else we fail to correctly compute the length. (We can only compute the number of bytes consumed by certain assembler directives after the entire file is parsed. ".p2align" is one of those directives, and is used by jump table generation.) The secondary fix, to MCWin64EH, is to make sure we don't silently miscompile if we hit a similar situation in the future. It's possible we could extend ARM64EmitUnwindInfo so it allows function bodies that contain assembler directives, but that's a lot more complicated; see the FIXME in MCWin64EH.cpp. Fixes https://bugs.llvm.org/show_bug.cgi?id=41581 . Differential Revision: https://reviews.llvm.org/D61095 llvm-svn: 359849
* [AsmPrinter] Make AsmPrinter::HandlerInfo::Handler a unique_ptrFangrui Song2019-04-301-13/+13
| | | | | | | Handlers.clear() in AsmPrinter::doFinalization() will destroy these handlers. A unique_ptr makes the ownership clearer. llvm-svn: 359541
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-304-0/+16
| | | | | | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). This re-commit fixes issues reported in the first one. Namely deref was inserted under wrong conditions and additionally the deref_size argument was incorrectly encoded. Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 359535
* [DebugInfo] Terminate more location-list ranges at the end of blocksJeremy Morse2019-04-291-9/+35
| | | | | | | | | | | | | | | | This patch fixes PR40795, where constant-valued variable locations can "leak" into blocks placed at higher addresses. The root of this is that DbgEntityHistoryCalculator terminates all register variable locations at the end of each block, but not constant-value variable locations. Fixing this requires constant-valued DBG_VALUE instructions to be broadcast into all blocks where the variable location remains valid, as documented in the LiveDebugValues section of SourceLevelDebugging.rst, and correct termination in DbgEntityHistoryCalculator. Differential Revision: https://reviews.llvm.org/D59431 llvm-svn: 359426
* [AsmPrinter] refactor to support %c w/ GlobalAddress'Nick Desaulniers2019-04-261-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Targets like ARM, MSP430, PPC, and SystemZ have complex behavior when printing the address of a MachineOperand::MO_GlobalAddress. Move that handling into a new overriden method in each base class. A virtual method was added to the base class for handling the generic case. Refactors a few subclasses to support the target independent %a, %c, and %n. The patch also contains small cleanups for AVRAsmPrinter and SystemZAsmPrinter. It seems that NVPTXTargetLowering is possibly missing some logic to transform GlobalAddressSDNodes for TargetLowering::LowerAsmOperandForConstraint to handle with "i" extended inline assembly asm constraints. Fixes: - https://bugs.llvm.org/show_bug.cgi?id=41402 - https://github.com/ClangBuiltLinux/linux/issues/449 Reviewers: echristo, void Reviewed By: void Subscribers: void, craig.topper, jholewinski, dschuff, jyknight, dylanmckay, sdardis, nemanjai, javed.absar, sbc100, jgravelle-google, eraman, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, jrtc27, atanasyan, jsji, llvm-commits, kees, tpimh, nathanchance, peter.smith, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60887 llvm-svn: 359337
* Recommitting r358783 and r358786 "[MS] Emit S_HEAPALLOCSITE debug info" with ↵Amy Huang2019-04-242-0/+24
| | | | | | | | | | | | | | | | | | | fixes for buildbot error (undefined assembler label). Summary: This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug info in codeview. Currently only changes FastISel, so emitting labels still needs to be implemented in SelectionDAG. Reviewers: rnk Subscribers: aprantl, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D61083 llvm-svn: 359149
* DebugInfo: Emit only declarations (not whole definitions) of non-unit user ↵David Blaikie2019-04-246-13/+63
| | | | | | | | | | | | | | | | | | | | defined types into type units While this doesn't come up in reasonable cases currently (the only user defined types not in type units are ones without linkage - which makes for near-ODR violations, because it'd be a type with linkage referencing a type without linkage - such a type can't be validly defined in more than one TU, so arguably it shouldn't be in a type unit to begin with - but it's a convenient way to demonstrate an issue that will become more revalent with homed modular debug info type definitions - which also don't need to be in type units but more legitimately so). Precursor to the Clang change to de-type-unit (by omitting the 'identifier') types homed due to strong linkage vtables. (making that change without this one would lead to major type duplication in type units) llvm-svn: 359122
* [Remarks] Add string deduplication using a string tableFrancis Visoiu Mistrih2019-04-242-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add support for uniquing strings in the remark streamer and emitting the string table in the remarks section. * Add parsing support for the string table in the RemarkParser. From this remark: ``` --- !Missed Pass: inline Name: NoDefinition DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 7, Column: 3 } Function: printArgsNoRet Args: - Callee: printf - String: ' will not be inlined into ' - Caller: printArgsNoRet DebugLoc: { File: 'test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c', Line: 6, Column: 0 } - String: ' because its definition is unavailable' ... ``` to: ``` --- !Missed Pass: 0 Name: 1 DebugLoc: { File: 3, Line: 7, Column: 3 } Function: 2 Args: - Callee: 4 - String: 5 - Caller: 2 DebugLoc: { File: 3, Line: 6, Column: 0 } - String: 6 ... ``` And the string table in the .remarks/__remarks section containing: ``` inline\0NoDefinition\0printArgsNoRet\0 test-suite/SingleSource/UnitTests/2002-04-17-PrintfChar.c\0printf\0 will not be inlined into \0 because its definition is unavailable\0 ``` This is mostly supposed to be used for testing purposes, but it gives us a 2x reduction in the remark size, and is an incremental change for the updates to the remarks file format. Differential Revision: https://reviews.llvm.org/D60227 llvm-svn: 359050
* Revert "[MS] Emit S_HEAPALLOCSITE debug info" because of ToTWin64(db)Amy Huang2019-04-232-19/+0
| | | | | | | | | buildbot failure. This reverts commit d07d6d617713bececf57f3547434dd52f0f13f9e and c774f687b6880484a126ed3e3d737e74c926f0ae. llvm-svn: 359034
* Reapply: "DebugInfo: Emit only one kind of accelerated access/name table""David Blaikie2019-04-233-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r358931 Reverted in r358997 Seems this change made Apple accelerator tables miss names (because names started respecting the CU NameTableKind GNU & assuming that shouldn't produce accelerated names too), which is never correct (apple accelerator tables don't have separators or CU lists - if present, they must describe all names in all CUs). Original Description: Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 359026
* Revert "DebugInfo: Emit only one kind of accelerated access/name table"David Blaikie2019-04-233-8/+3
| | | | | | | | Regresses some apple_names situations - still investigating. This reverts commit r358931. llvm-svn: 358997
* Use llvm::stable_sortFangrui Song2019-04-233-24/+22
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* DebugInfo: Emit only one kind of accelerated access/name tableDavid Blaikie2019-04-223-3/+8
| | | | | | | | | | | | | | | Currently to opt in to debug_names in DWARFv5, the IR must contain 'nameTableKind: Default' which also enables debug_pubnames. Instead, only allow one of {debug_names, apple_names, debug_pubnames, debug_gnu_pubnames}. nameTableKind: Default gives debug_names in DWARFv5 and greater, debug_pubnames in v4 and earlier - and apple_names when tuning for lldb on MachO. nameTableKind: GNU always gives gnu_pubnames llvm-svn: 358931
* [MS] Emit S_HEAPALLOCSITE debug infoAmy Huang2019-04-192-0/+19
| | | | | | | | | | | | | | | | | Summary: This emits labels around heapallocsite calls and S_HEAPALLOCSITE debug info in codeview. Currently only changes FastISel, so emitting labels still needs to be implemented in SelectionDAG. Reviewers: hans, rnk Subscribers: aprantl, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60800 llvm-svn: 358783
* [llvm] Prevent duplicate files in debug line header in dwarf 5: another attemptAli Tamur2019-04-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another attempt to land the changes in debug line header to prevent duplicate files in Dwarf 5. I rolled back my previous commit because of a mistake in generating the object file in a test. Meanwhile, I addressed some offline comments and changed the implementation; the largest difference is that MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I also merged the patch to fix two lld tests that will strt to fail into this patch. Original Commit: https://reviews.llvm.org/D59515 Original Message: Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. llvm-svn: 358732
* Fix a typo in comments. [NFC]Ali Tamur2019-04-181-1/+1
| | | | llvm-svn: 358639
* [AsmPrinter] hoist %a output template to base class for ARM+Aarch64Nick Desaulniers2019-04-171-4/+11
| | | | | | | | | | | | | | | | | | | | | Summary: X86 is quite complicated; so I intend to leave it as is. ARM+Aarch64 do basically the same thing (Aarch64 did not correctly handle immediates, ARM has a test llvm/test/CodeGen/ARM/2009-04-06-AsmModifier.ll that uses %a with an immediate) for a flag that should be target independent anyways. Reviewers: echristo, peter.smith Reviewed By: echristo Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60841 llvm-svn: 358618
* [AsmPrinter] defer %c to base class for ARM, PPC, and Hexagon. NFCNick Desaulniers2019-04-171-0/+3
| | | | | | | | | | | | | | | | | | | Summary: None of these derived classes do anything that the base class cannot. If we remove these case statements, then the base class can handle them just fine. Reviewers: peter.smith, echristo Reviewed By: echristo Subscribers: nemanjai, javed.absar, eraman, kristof.beyls, hiraditya, kbarton, jsji, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60803 llvm-svn: 358603
* Revert r358268 "[DebugInfo] DW_OP_deref_size in PrologEpilogInserter."Hans Wennborg2019-04-121-4/+0
| | | | | | | | | | | | | | | | | | | It causes clang to crash while building Chromium. See https://crbug.com/952230 for reproducer. > The PrologEpilogInserter need to insert a DW_OP_deref_size before > prepending a memory location expression to an already implicit > expression to avoid having the existing expression act on the memory > address instead of the value behind it. > > The reason for using DW_OP_deref_size and not plain DW_OP_deref is that > big-endian targets need to read the right size as simply truncating a > larger read would yield the wrong result (LSB bytes are not at the lower > address). > > Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358281
* [DebugInfo] DW_OP_deref_size in PrologEpilogInserter.Markus Lavin2019-04-121-0/+4
| | | | | | | | | | | | | | | | The PrologEpilogInserter need to insert a DW_OP_deref_size before prepending a memory location expression to an already implicit expression to avoid having the existing expression act on the memory address instead of the value behind it. The reason for using DW_OP_deref_size and not plain DW_OP_deref is that big-endian targets need to read the right size as simply truncating a larger read would yield the wrong result (LSB bytes are not at the lower address). Differential Revision: https://reviews.llvm.org/D59687 llvm-svn: 358268
* Add explicit dependencies on MCSection.h and MCDwarf.h to the .cppEric Christopher2019-04-121-0/+1
| | | | | | files rather than rely on transitive includes from MCStreamer.h. llvm-svn: 358263
* [RISCV] Put data smaller than eight bytes to small data sectionShiva Chen2019-04-111-0/+3
| | | | | | | | | | | Because of gp = sdata_start_address + 0x800, gp with signed twelve-bit offset could covert most of the small data section. Linker relaxation could transfer the multiple data accessing instructions to a gp base with signed twelve-bit offset instruction. Differential Revision: https://reviews.llvm.org/D57493 llvm-svn: 358150
* [AsmPrinter] refactor to remove remove AsmVariant. NFCNick Desaulniers2019-04-101-22/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The InlineAsm::AsmDialect is only required for X86; no architecture makes use of it and as such it gets passed around between arch-specific and general code while being unused for all architectures but X86. Since the AsmDialect is queried from a MachineInstr, which we also pass around, remove the additional AsmDialect parameter and query for it deep in the X86AsmPrinter only when needed/as late as possible. This refactor should help later planned refactors to AsmPrinter, as this difference in the X86AsmPrinter makes it harder to make AsmPrinter more generic. Reviewers: craig.topper Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, llvm-commits, peter.smith, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D60488 llvm-svn: 358101
OpenPOWER on IntegriCloud