summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
Commit message (Collapse)AuthorAgeFilesLines
* [CodeView] Emit global variables within lexical scopes to limit visibilityBrock Wyma2018-12-201-4/+25
| | | | | | | | | 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] Move several private headers to include directoryYonghong Song2018-12-181-2/+2
| | | | | | | | | | | | | | | | | This patch moved the following files in lib/CodeGen/AsmPrinter/ AsmPrinterHandler.h DbgEntityHistoryCalculator.h DebugHandlerBase.h to include/llvm/CodeGen directory. Such a change will enable Target to extend DebugHandlerBase and emit Target specific debug info sections. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D55755 llvm-svn: 349564
* [codeview] Add begin/endSymbolRecord helpers, NFCReid Kleckner2018-12-141-1/+10
| | | | | | | Previously beginning a symbol record was excessively verbose. Now it's a bit simpler. This follows the same pattern as begin/endCVSubsection. llvm-svn: 349205
* [CodeView] Add support for ref-qualified member functions.Zachary Turner2018-11-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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] Expose -gcodeview-ghash for global type hashingReid Kleckner2018-11-161-0/+3
| | | | | | | | | | | | | | | | | | | | | 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
* [codeview] Let the X86 backend tell us the VFRAME offset adjustmentReid Kleckner2018-11-031-0/+3
| | | | | | | | | | | Use MachineFrameInfo's OffsetAdjustment field to pass this information from the target to CodeViewDebug.cpp. The X86 backend doesn't use it for any other purpose. This fixes PR38857 in the case where there is a non-aligned quantity of CSRs and a non-aligned quantity of locals. llvm-svn: 346062
* [codeview] Emit S_BUILDINFO and LF_BUILDINFO with cwd and source fileReid Kleckner2018-10-121-0/+2
| | | | | | | | | | | | Summary: We can fill in the command line and compiler path later if we want. Reviewers: zturner Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D53179 llvm-svn: 344393
* [CodeView] Emit function options for subprogram and member functionsAaron Smith2018-10-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use the newly added DebugInfo (DI) Trivial flag, which indicates if a C++ record is trivial or not, to determine Codeview::FunctionOptions. Clang and MSVC generate slightly different Codeview for C++ records. For example, here is the C++ code for a class with a defaulted ctor, class C { public: C() = default; }; Clang will produce a LF for the defaulted ctor while MSVC does not. For more details, refer to FIXMEs in the test cases in "function-options.ll" included with this set of changes. Reviewers: zturner, rnk, llvm-commits, aleksandr.urakov Reviewed By: rnk Subscribers: Hui, JDevlieghere Differential Revision: https://reviews.llvm.org/D45123 llvm-svn: 343626
* [codeview] Fix 32-bit x86 variable locations in realigned stack framesReid Kleckner2018-10-021-0/+2
| | | | | | | | | | | | | | | | | | Add the .cv_fpo_stackalign directive so that we can define $T0, or the VFRAME virtual register, with it. This was overlooked in the initial implementation because unlike MSVC, we push CSRs before allocating stack space, so this value is only needed to describe local variable locations. Variables that the compiler now addresses via ESP are instead described as being stored at offsets from VFRAME, which for us is ESP after alignment in the prologue. This adds tests that show that we use the VFRAME register properly in our S_DEFRANGE records, and that we emit the correct FPO data to define it. Fixes PR38857 llvm-svn: 343603
* [codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_RELReid Kleckner2018-10-011-2/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, LLVM would always describe locals on the stack as being relative to some specific register, RSP, ESP, EBP, ESI, etc. Variables in stack memory are pretty common, so there is a special S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to reduce the size of our debug info. On top of the size savings, there are cases on 32-bit x86 where local variables are addressed from ESP, but ESP changes across the function. Unlike in DWARF, there is no FPO data to describe the stack adjustments made to push arguments onto the stack and pop them off after the call, which makes it hard for the debugger to find the local variables in frames further up the stack. To handle this, CodeView has a special VFRAME register, which corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets to local variables are instead relative to this value. This is part of PR38857. Reviewers: hans, zturner, javed.absar Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D52217 llvm-svn: 343543
* [codeview] Remove dead codeReid Kleckner2018-09-141-4/+0
| | | | llvm-svn: 342285
* [DebugInfo] Do not generate label debug info if it has been processed.Hsiangkai Wang2018-09-061-2/+2
| | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[DebugInfo] Generate DWARF debug information for labels. (Fix leak ↵Bruno Cardoso Lopes2018-08-141-1/+1
| | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[DebugInfo] Generate DWARF debug information for labels."Vlad Tsyrklevich2018-07-311-1/+1
| | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[DebugInfo] Generate DWARF debug information for labels."Shiva Chen2018-07-241-1/+1
| | | | | | This reverts commit b454fa1b4079b6c0a5b1565982d16516385838d7. llvm-svn: 337812
* [DebugInfo] Generate DWARF debug information for labels.Shiva Chen2018-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeGen] Fix inconsistent declaration parameter nameFangrui Song2018-07-161-2/+2
| | | | llvm-svn: 337200
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-5/+5
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...Brock Wyma2018-04-161-0/+4
| | | | | | | | | | | When emitting CodeView debug information, compiler-generated thunk routines should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so Visual Studio can properly step into the user code. This initial support only handles standard thunk ordinals. Differential Revision: https://reviews.llvm.org/D43838 llvm-svn: 330132
* [Debuginfo][COFF] Minimal serialization support for precompiled types recordsAlexandre Ganea2018-04-091-1/+2
| | | | | | | | | | | | | This change adds support for the LF_PRECOMP and LF_ENDPRECOMP records required to read/write Microsoft precompiled types .objs. See https://en.wikipedia.org/wiki/Precompiled_header#Microsoft_Visual_C_and_C++ This also adds handling for the .debug$P section, which is actually a .debug$T section in disguise, found only in precompiled .objs. Differential Revision: https://reviews.llvm.org/D45283 llvm-svn: 329613
* Re-land r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-151-1/+37
| | | | | | | | | for lexical scopes" This is safe to land now that we don't copy FunctionInfo when rehashing the DenseMap. llvm-svn: 327670
* [codeview] Delete FunctionInfo copy ctor and move out of DenseMapReid Kleckner2018-03-151-1/+6
| | | | | | | | | | | | | We were unnecessarily copying a bunch of these FunctionInfo objects around when rehashing the DenseMap. Furthermore, r327620 introduced pointers referring to objects owned by FunctionInfo, and the default copy ctor did the wrong thing in this case, leading to use-after-free when the DenseMap gets rehashed. I will rebase r327620 on this next and recommit it. llvm-svn: 327665
* Revert r327620 "[CodeView] Initial support for emitting S_BLOCK32 symbols ↵Reid Kleckner2018-03-151-37/+1
| | | | | | | | | | for lexical scopes" It is causing crashes when compiling Chrome in debug mode. I'll try to debug it in a second. llvm-svn: 327657
* [CodeView] Initial support for emitting S_BLOCK32 symbols for lexical scopesBrock Wyma2018-03-151-1/+37
| | | | | | | | | This patch sorts local variables by lexical scope and emits them inside an appropriate S_BLOCK32 CodeView symbol. Differential Revision: https://reviews.llvm.org/D42926 llvm-svn: 327620
* [CodeView] Emit UdtSourceLine information for enumsAaron Smith2018-03-061-0/+2
| | | | | | | | | | | | | | | | | Summary: - Emit UdtSourceLine information for enums to match MSVC - Add a method to add UDTSrcLine and call it for all Class/Struct/Union/Enum - Update test cases to verify the changes Reviewers: zturner, llvm-commits, rnk Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D44116 llvm-svn: 326824
* [CodeView] Lower __restrict and other pointer qualifiers correctlyReid Kleckner2018-02-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualifiers on a pointer or reference type may apply to either the pointee or the pointer itself. Consider 'const char *' and 'char * const'. In the first example, the pointee data may not be modified without casts, and in the second example, the pointer may not be updated to point to new data. In the general case, qualifiers are applied to types with LF_MODIFIER records, which support the usual const and volatile qualifiers as well as the __unaligned extension qualifier. However, LF_POINTER records, which are used for pointers, references, and member pointers, have flags for qualifiers applying to the *pointer*. In fact, this is the only way to represent the restrict qualifier, which can only apply to pointers, and cannot qualify regular data types. This patch causes LLVM to correctly fold 'const' and 'volatile' pointer qualifiers into the pointer record, as well as adding support for '__restrict' qualifiers in the same place. Based on a patch from Aaron Smith Differential Revision: https://reviews.llvm.org/D43060 llvm-svn: 326260
* [CodeView] Teach clang to emit the .debug$H COFF section.Zachary Turner2017-12-131-2/+4
| | | | | | | | | | | | | | | Currently this is an LLVM extension to the COFF spec which is experimental and intended to speed up linking. For now it is behind a hidden cl::opt flag, but in the future we can move it to a "real" cc1 flag and have the driver pass it through whenever it is appropriate. The patch to actually make use of this section in lld will come in a followup. Differential Revision: https://reviews.llvm.org/D40917 llvm-svn: 320649
* Split TypeTableBuilder into two classes.Zachary Turner2017-11-301-2/+2
| | | | llvm-svn: 319456
* [codeview] Merge file checksum entries for DIFiles with the same absolute pathReid Kleckner2017-10-311-2/+3
| | | | | | | | Change the map key from DIFile* to the absolute path string. Computing the absolute path isn't expensive because we already have a map that caches the full path keyed on DIFile*. llvm-svn: 317041
* Mark static member functions as static in CodeViewDebugAdrian McCarthy2017-09-131-1/+2
| | | | | | | | | | | | | | Summary: To improve CodeView quality for static member functions, we need to make the static explicit. In addition to a small change in LLVM's CodeViewDebug to return the appropriate MethodKind, this requires a small change in Clang to note the staticness in the debug info metadata. Subscribers: aprantl, hiraditya Differential Revision: https://reviews.llvm.org/D37715 llvm-svn: 313192
* Add llvm.codeview.annotation to implement MSVC __annotationReid Kleckner2017-09-051-0/+2
| | | | | | | | | | | | | | | | | | Summary: This intrinsic represents a label with a list of associated metadata strings. It is modelled as reading and writing inaccessible memory so that it won't be removed as dead code. I think the intention is that the annotation strings should appear at most once in the debug info, so I marked it noduplicate. We are allowed to inline code with annotations as long as we strip the annotation, but that can be done later. Reviewers: majnemer Subscribers: eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D36904 llvm-svn: 312569
* [codeview] Generalize DIExpression parsing to handle load chainsReid Kleckner2017-08-311-1/+1
| | | | | | | | | | | | | | | Summary: Hopefully this also clarifies exactly when and why we're rewriting certiain S_LOCALs using reference types: We're using the reference type to stand in for a zero-offset load. Reviewers: inglorion Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37309 llvm-svn: 312247
* Reland r311957 [codeview] support more DW_OPs for more complete debug infoBob Haarman2017-08-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some variables show up in Visual Studio as "optimized out" even in -O0 -Od builds. This change fixes two issues that would cause this to happen. The first issue is that not all DIExpressions we generate were recognized by the CodeView writer. This has been addressed by adding support for DW_OP_constu, DW_OP_minus, and DW_OP_plus. The second issue is that we had no way to encode DW_OP_deref in CodeView. We get around that by changinge the type we encode in the debug info to be a reference to the type in the source code. This fixes PR34261. The reland adds two extra checks to the original: It checks if the DbgVariableLocation is valid before checking any of its fields, and it only emits ranges with nonzero registers. Reviewers: aprantl, rnk, zturner Reviewed By: rnk Subscribers: mgorny, llvm-commits, aprantl, hiraditya Differential Revision: https://reviews.llvm.org/D36907 llvm-svn: 312034
* Revert "[codeview] support more DW_OPs for more complete debug info"Bob Haarman2017-08-291-6/+0
| | | | | | This reverts commit e160912f53f047bc97e572add179e08e33f4df48. llvm-svn: 311977
* [codeview] support more DW_OPs for more complete debug infoBob Haarman2017-08-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Some variables show up in Visual Studio as "optimized out" even in -O0 -Od builds. This change fixes two issues that would cause this to happen. The first issue is that not all DIExpressions we generate were recognized by the CodeView writer. This has been addressed by adding support for DW_OP_constu, DW_OP_minus, and DW_OP_plus. The second issue is that we had no way to encode DW_OP_deref in CodeView. We get around that by changinge the type we encode in the debug info to be a reference to the type in the source code. This fixes PR34261. Reviewers: aprantl, rnk, zturner Reviewed By: rnk Subscribers: mgorny, llvm-commits, aprantl, hiraditya Differential Revision: https://reviews.llvm.org/D36907 llvm-svn: 311957
* [CodeView] Don't output S_UDT symbols for forward decls.Zachary Turner2017-08-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | S_UDT symbols are the debugger's "index" for all the structs, typedefs, classes, and enums in a program. If any of those structs/classes don't have a complete declaration, or if there is a typedef to something that doesn't have a complete definition, then emitting the S_UDT is unhelpful because it doesn't give the debugger enough information to do anything useful. On the other hand, it results in a huge size blow-up in the resulting PDB, which is exacerbated by an order of magnitude when linking with /DEBUG:FASTLINK. With this patch, we drop S_UDT records for types that refer either directly or indirectly (e.g. through a typedef, pointer, etc) to a class/struct/union/enum without a complete definition. This brings us about 50% of the way towards parity with /DEBUG:FASTLINK PDBs generated from cl-compiled object files. Differential Revision: https://reviews.llvm.org/D37162 llvm-svn: 311904
* [codeview] Use the first valid source location at the top of every MBBReid Kleckner2017-06-301-1/+0
| | | | | | | | | | | | | | | | If the instructions at the beginning of the block have no location, we're better off using the location of the first instruction in the current basic block. At the very least, that instruction post-dominates this one, whereas if we don't emit a .cv_loc directive, we end up using the potentially invalid location that falls through from the previous block. We could probably do better here by emitting some kind of ".cv_loc end" directive that stops the line table entry of the previous .cv_loc directive from bleeding out of its basic block. This would improve the line table when an entire MBB has no valid location info. llvm-svn: 306889
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-06-061-17/+34
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 304839
* [CodeView] Rename ModuleDebugFragment -> DebugSubsection.Zachary Turner2017-05-301-1/+1
| | | | | | | This is more concise, and matches the terminology used in other parts of the codebase more closely. llvm-svn: 304218
* Rename some PDB classes.Zachary Turner2017-04-271-1/+1
| | | | | | | | | | | | | | | | | | | We have a lot of very similarly named classes related to dealing with module debug info. This patch has NFC, it just renames some classes to be more descriptive (albeit slightly more to type). The mapping from old to new class names is as follows: Old | New ModInfo | DbiModuleDescriptor ModuleSubstream | ModuleDebugFragment ModStream | ModuleDebugStream With the corresponding Builder classes renamed accordingly. Differential Revision: https://reviews.llvm.org/D32506 llvm-svn: 301555
* Refactor DebugHandlerBase a bit to common non-debug-having-function filteringDavid Blaikie2017-02-161-6/+7
| | | | llvm-svn: 295354
* Move VariableDbgInfo from MachineModuleInfo to MachineFunctionMatthias Braun2016-11-301-1/+1
| | | | | | | | | | | VariableDbgInfo is per function data, so it makes sense to have it with the function instead of the module. This is a necessary step to have machine module passes work properly. Differential Revision: https://reviews.llvm.org/D27186 llvm-svn: 288292
* [CodeView] Hook up CodeViewRecordIO to type serialization path.Zachary Turner2016-11-081-2/+2
| | | | | | | | | | | | Previously support had been added for using CodeViewRecordIO to read (deserialize) CodeView type records. This patch adds support for writing those same records. With this patch, reading and writing of CodeView type records finally uses a single codepath. Differential Revision: https://reviews.llvm.org/D26253 llvm-svn: 286304
* [codeview] Translate bitpiece metadata to DEFRANGE_SUBFIELD* recordsReid Kleckner2016-10-051-5/+11
| | | | | | | | | | | | | This allows LLVM to describe locations of aggregate variables that have been split by SROA. Fixes PR29141 Reviewers: amccarth, majnemer Differential Revision: https://reviews.llvm.org/D25253 llvm-svn: 283388
* Emit S_COMPILE3 CodeView recordAdrian McCarthy2016-09-201-0/+2
| | | | | | | | | | CodeView has an S_COMPILE3 record to identify the compiler and source language of the compiland. This record comes first in the debug$S section for the compiland. The debuggers rely on this record to know the source language of the code. There was a little test fallout from introducing a new record into the symbols subsection. Differential Revision: https://reviews.llvm.org/D24317 llvm-svn: 281990
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-1/+2
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* [pdb] Write PDB TPI Stream from Yaml.Zachary Turner2016-09-091-0/+1
| | | | | | | | | | This writes the full sequence of type records described in Yaml to the TPI stream of the PDB file. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D24316 llvm-svn: 281063
OpenPOWER on IntegriCloud