summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter
Commit message (Collapse)AuthorAgeFilesLines
...
* Sink DwarfUnit::CURanges into DwarfCompileUnitDavid Blaikie2014-11-033-8/+7
| | | | llvm-svn: 221161
* Revert r221150, as it broke sanitizer testsOliver Stannard2014-11-032-2/+2
| | | | llvm-svn: 221151
* Emit .eh_frame with relocations to functions, rather than sectionsOliver Stannard2014-11-032-2/+2
| | | | | | | | | | | | | | | | | | | | | | | When LLVM emits DWARF call frame information, it currently creates a local, section-relative symbol in the code section, which is pointed to by a relocation on the .eh_frame section. However, for C++ we emit some functions in section groups, and the SysV ABI has some rules to make it easier to remove these sections (http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_group_rules): A symbol table entry with STB_LOCAL binding that is defined relative to one of a group's sections, and that is contained in a symbol table section that is not part of the group, must be discarded if the group members are discarded. References to this symbol table entry from outside the group are not allowed. This means that we need to use the function symbol for the relocation, not a temporary symbol. There was a comment in the code claiming that the local symbol was used to avoid creating a relocation, but a relocation must be created anyway as the code and CFI are in different sections. llvm-svn: 221150
* Sink range list handling down from DwarfUnit into its only use, in ↵David Blaikie2014-11-032-15/+15
| | | | | | DwarfCompileUnit. llvm-svn: 221123
* FormattingDavid Blaikie2014-11-021-1/+1
| | | | llvm-svn: 221095
* Add DwarfUnit::isDwoUnit and use it to generalize string creationDavid Blaikie2014-11-025-15/+34
| | | | | | | | | | | | | | | | | | | Currently we only need to emit skeleton strings into the CU header and we do this by explicitly calling "addLocalString". With gmlt-in-fission, we'll be emitting a bunch of other strings from other codepaths where it's not statically known that these strings will be local or not. Introduce a virtual function to indicate whether this unit is a DWO unit or not (I'm not sure if we have a good term for this, the opposite/alternative to 'skeleton' unit) and use that to generalize the string emission logic so that strings can be correctly emitted in both the skeleton and dwo unit when in split dwarf mode. And to demonstrate that this works, switch the existing special callers of addLocalString in the skeleton builder to addString - and they still work. Yay. llvm-svn: 221094
* Remove the last mention of LineTablesOnly from DwarfUnit, sinking it into ↵David Blaikie2014-11-023-4/+7
| | | | | | | | | | | | | | DwarfCompileUnit This is a useful distinction/invariant/delination to make because LineTablesOnly mode is never relevant to type units, so it's clear that we're not doing weird line-tables-only-with-types by making this API choice. It also lays the foundations nicely for adding gmlt-like data to fission skeleton CUs while limiting the effects to CUs and not TUs. llvm-svn: 221093
* Sink DwarfUnit::applySubprogramAttributesToDefinition into DwarfCompileUnitDavid Blaikie2014-11-024-8/+10
| | | | llvm-svn: 221092
* Sink DwarfUnit::addExpr into DwarfCompileUnitDavid Blaikie2014-11-024-10/+10
| | | | llvm-svn: 221090
* Fix the build from the last commitDavid Blaikie2014-11-021-2/+2
| | | | llvm-svn: 221089
* Sink DwarfUnit::applyVariableAttributes into DwarfCompileUnitDavid Blaikie2014-11-024-12/+12
| | | | llvm-svn: 221088
* Sink DwarfUnit::addLocationList down into DwarfCompileUnitDavid Blaikie2014-11-024-13/+12
| | | | llvm-svn: 221087
* Sink DwarfUnit::addComplexAddress down into DwarfCompileUnitDavid Blaikie2014-11-024-67/+65
| | | | llvm-svn: 221086
* Push DwarfUnit::addAddress down into DwarfCompileUnitDavid Blaikie2014-11-024-24/+22
| | | | llvm-svn: 221085
* Sink DwarfUnit::addVariableAddress into DwarfCompileUnit since type units ↵David Blaikie2014-11-024-18/+17
| | | | | | don't have variables llvm-svn: 221084
* DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into ↵David Blaikie2014-11-026-33/+42
| | | | | | DwarfCompileUnit llvm-svn: 221083
* Add DwarfUnit::addGlobalType to match DwarfUnit::addGlobalNameDavid Blaikie2014-11-022-7/+15
| | | | | | | | | (these will shortly become virtual, with a null implementation in DwarfUnit (since type units don't have accelerator tables in the current schema) and the current implementation down in DwarfCompileUnit, moving the actual maps there too) llvm-svn: 221082
* DebugInfo: Refactor index type DIE initialization by rolling it into the ↵David Blaikie2014-11-022-10/+13
| | | | | | accessor llvm-svn: 221080
* Be sure to initialize DwarfCompileUnit::LabelBegin now that it may be ↵David Blaikie2014-11-021-1/+1
| | | | | | skipped in initSection llvm-svn: 221079
* Don't bother creating LabelBegin for .dwo unitsDavid Blaikie2014-11-022-4/+8
| | | | | | | | | | This would help catch cases where we might otherwise try to reference a dwo CU label, which would be weird - because without relocations in the dwo file it's not generally meaningful to talk about the CU offsets there (or, if it is, we can do so in absolute terms without using a relocation to compute it). llvm-svn: 221078
* Drop DwarfCompileUnit::getLocalLabel* in favor of just mapping through the ↵David Blaikie2014-11-022-17/+5
| | | | | | | | | skeleton explicitly. Confusing to do this two different ways - I'm not too wedded to either one, but here goes. llvm-svn: 221076
* Sink DwarfUnit::LabelBegin down into DwarfCompileUnit since that's the only ↵David Blaikie2014-11-023-10/+10
| | | | | | place it's needed. llvm-svn: 221075
* Sink dwarf unit length emission down into DwarfUnit::emitHeaderDavid Blaikie2014-11-014-7/+14
| | | | | | | | This allows the CU label to be emitted only for compile units, as they're the only ones that need it (so they can be referenced from pubnames) llvm-svn: 221072
* Remove DwarfUnit::LabelEnd in favor of computing the length of the section ↵David Blaikie2014-11-015-12/+5
| | | | | | | | | | directly This was a compile-unit specific label (unused in type units) and seems unnecessary anyway when we can more easily directly compute the size of the compile unit. llvm-svn: 221067
* Sink DwarfUnit::SectionSym into DwarfCompileUnit as it's only needed/used there.David Blaikie2014-11-014-40/+28
| | | | llvm-svn: 221062
* Make DwarfCompileUnit::Skeleton more narrowly typed (DwarfCompileUnit* ↵David Blaikie2014-11-011-3/+3
| | | | | | instead of DwarfUnit*) now that it's specific to DwarfCompileUnit anyway. llvm-svn: 221060
* Sink DwarfUnit::Skeleton down into DwarfCompileUnitDavid Blaikie2014-11-014-25/+25
| | | | | | | | | Type units no longer have skeletons and it's misleading to be able to query for a type unit's skeleton (it might incorrectly lead one to conclude that if a unit doesn't have a skeleton it's not in a .dwo file... ). llvm-svn: 221055
* Sink DwarfDebug::AbstractSPDies down into DwarfFileDavid Blaikie2014-11-013-11/+11
| | | | | | | | | | | This is the first big step to allowing gmlt-like inline scope information in the skeleton CU. While this commit doesn't change the functionality, it's only a small step to call "constructAbstractSubprogramDIE" on both the InfoHolder and the SkeletonHolder (when in use) and that will at least create the abstract SP dies in that case, though still not creating the other subprograms. llvm-svn: 221051
* Remove unused functionDavid Blaikie2014-11-011-3/+0
| | | | llvm-svn: 221037
* And... fix the build some more.David Blaikie2014-11-011-1/+1
| | | | llvm-svn: 221036
* Just iterate the DwarfCompileUnits rather than trying to filter them out of ↵David Blaikie2014-11-011-49/+46
| | | | | | the list of all units. llvm-svn: 221034
* Add '*' to auto variable that is a pointer, as per the coding conventions.David Blaikie2014-11-011-1/+1
| | | | llvm-svn: 221033
* Add DwarfCompileUnit::getSkeleton that returns DwarfCompileUnit* to avoid ↵David Blaikie2014-11-012-3/+6
| | | | | | having to cast from DwarfUnit* on every call. llvm-svn: 221031
* Sink some of DwarfDebug::collectDeadVariables down into DwarfCompileUnit.David Blaikie2014-10-314-20/+25
| | | | llvm-svn: 221010
* Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE into ↵David Blaikie2014-10-313-14/+13
| | | | | | DwarfCompileUnit llvm-svn: 221005
* Correct assert text from r220923David Blaikie2014-10-311-1/+1
| | | | | | Noticed in post-commit review by Adrian Prantl. llvm-svn: 220967
* PR21408: Workaround the appearance of duplicate variables due to problems ↵David Blaikie2014-10-301-1/+6
| | | | | | when inlining two calls to the same function from the same call site. llvm-svn: 220923
* Minimize the scope of some variables, NFC.David Blaikie2014-10-281-2/+2
| | | | llvm-svn: 220759
* Remove some unnecessary casts.David Blaikie2014-10-261-2/+2
| | | | llvm-svn: 220658
* Sink DwarfUnit::constructImportedEntityDIE into DwarfCompileUnit.Frederic Riss2014-10-244-32/+32
| | | | | | | | | | So that it has access to getOrCreateGlobalVariableDIE. If we ever support decsribing using directive in C++ classes (thus requiring support in type units), it will certainly use another mechanism anyway. Differential Revision: http://reviews.llvm.org/D5975 llvm-svn: 220594
* DebugInfo: Sink DwarfDebug::ScopeVariables down into DwarfFileDavid Blaikie2014-10-245-11/+11
| | | | | | | | (part of refactoring to allow subprogram emission in both the skeleton and main units to enable -gmlt-like data to be included in the skeleton for live inlined backtracing purposes) llvm-svn: 220578
* Remove DwarfDebug::FirstCU as it has no useDavid Blaikie2014-10-242-17/+5
| | | | | | | It was only being used as a flag to identify the lack of debug info from within endModule - use the section labels for that instead. llvm-svn: 220575
* Fix PR21189 -- Emit symbol subsection required to debug LLVM-built binaries ↵Timur Iskhodzhanov2014-10-241-9/+47
| | | | | | | | with VS2012+ Reviewed at http://reviews.llvm.org/D5772 llvm-svn: 220544
* DebugInfo: Remove DwarfDebug::addScopeVariable now that it's just a trivial ↵David Blaikie2014-10-244-13/+6
| | | | | | wrapper llvm-svn: 220542
* DebugInfo: Remove DwarfDebug::CurrentFnArguments since we have to handle ↵David Blaikie2014-10-235-51/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument ordering of other arguments (abstract arguments) in the same way and already have code for that too. While refactoring this code I was confused by both the name I had introduced (addNonArgumentVariable... but it has all this logic to handle argument numbering and keep things in order?) and by the redundancy. Seems when I fixed the misordered inlined argument handling, I didn't realize it was mostly redundant with the argument ordering code (which I may've also written, I'm not sure). So let's just rely on the more general case. The only oddity in output this produces is that it means when we emit all the variables for the current function, we don't track when we've finished the argument variables and are about to start the local variables and insert DW_AT_unspecified_parameters (for varargs functions) there. Instead it ends up after the local variables, scopes, etc. But this isn't invalid and doesn't cause DWARF consumers problems that I know of... so we'll just go with that because it makes the code nice & simple. (though, let's see what the buildbots have to say about this - *crosses fingers*) There will be some cleanup commits to follow to remove the now trivial wrappers, etc. llvm-svn: 220527
* DebugInfo: Sink DwarfDebug::addNonArgumentScopeVariable into DwarfFile.David Blaikie2014-10-234-35/+35
| | | | llvm-svn: 220520
* DebugInfo: Remove DwarfDebug::addCurrentFnArgument declaration now that it's ↵David Blaikie2014-10-231-4/+0
| | | | | | moved to DwarfFile. llvm-svn: 220515
* DebugInfo: Simplify/tidy/correct global variable decl/def emission handling.David Blaikie2014-10-231-51/+26
| | | | | | | | | | | | | | | | | | | | | | | This fixes a bug (introduced by fixing the IR emitted from Clang where the definition of a static member would be scoped within the class, rather than within its lexical decl context) where the definition of a static variable would be placed inside a class. It also improves source fidelity by scoping static class member definitions inside the lexical decl context in which tehy are written (eg: namespace n { class foo { static int i; } int foo::i; } - the definition of 'i' will be within the namespace 'n' in the DWARF output now). Lastly, and the original goal, this reduces debug info size slightly (and makes debug info easier to read, etc) by placing the definitions of non-member global variables within their namespace, rather than using a separate namespace-scoped declaration along with a definition at global scope. Based on patches and discussion with Frédéric. llvm-svn: 220497
* Remove explicit (void) use of DwarfFile::DD that was accidentally left in ↵David Blaikie2014-10-231-3/+1
| | | | | | | | r220452. Caught in post-commit review by Frédéric. llvm-svn: 220487
* [DebugInfo] Sink DwarfDebug::addCurrentFnArgument down into DwarfFile.David Blaikie2014-10-233-24/+28
| | | | | | | | Variable handling will be sunk into DwarfFile so that abstract variables and the like can be shared across multiple CUs (to handle cross-CU inlining, for example). llvm-svn: 220453
OpenPOWER on IntegriCloud