summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Convert the easy cases of GetTempSymbol to createTempSymbol.Rafael Espindola2015-03-171-1/+1
| | | | | | | In these cases no code was depending on GetTempSymbol finding an existing symbol. llvm-svn: 232478
* Emit correct linkage-name attribute based on DWARF version.Paul Robinson2015-03-101-10/+1
| | | | | | | | | | There are still 4 tests that check for DW_AT_MIPS_linkage_name, because they specify DWARF 2 or 3 in the module metadata. So, I didn't create an explicit version-based test for the attribute. Differential Revision: http://reviews.llvm.org/D8227 llvm-svn: 231880
* Store an optional section start label in MCSection.Rafael Espindola2015-03-101-6/+10
| | | | | | | | | | | | This makes code that uses section relative expressions (debug info) simpler and less brittle. This is still a bit awkward as the symbol is created late and has to be stored in a mutable field. I will move the symbol creation earlier in the next patch. llvm-svn: 231802
* Use a better name for compile unit labels.Rafael Espindola2015-03-101-2/+1
| | | | | | | | | | | | | They mark the start of a compile unit, so name them .Lcu_*. Using Section->getLabelBeginName() makes it looks like they mark the start of the section. While at it, switch to createTempSymbol to avoid collisions with labels created in inline assembly. Not sure if a "don't crash" test is worth it. With this getLabelBeginName is dead, delete it. llvm-svn: 231750
* Move label creation close to emission. NFC.Rafael Espindola2015-03-101-2/+5
| | | | llvm-svn: 231744
* Use the existing begin and end symbol for debug info.Rafael Espindola2015-03-051-1/+1
| | | | llvm-svn: 231338
* Support standard DWARF TLS opcode; Darwin and PS4 use it.Paul Robinson2015-03-041-2/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D8018 llvm-svn: 231286
* Used the cached subtarget off of the MachineFunction.Eric Christopher2015-02-201-4/+2
| | | | llvm-svn: 230078
* AsmPrinter: Take range in DwarfExpression::AddExpression(), NFCDuncan P. N. Exon Smith2015-02-171-2/+5
| | | | | | | | | | Previously `DwarfExpression::AddExpression()` relied on default-constructing the end iterators for `DIExpression` -- once the operands are represented explicitly via `MDExpression` (instead of via the strange `StringRef` navigator in `DIHeaderIterator`) this won't work. Explicitly take an iterator for the end of the range. llvm-svn: 229572
* AsmPrinter: Use DIExpression default constructor, NFCDuncan P. N. Exon Smith2015-02-171-1/+1
| | | | llvm-svn: 229464
* Debug Info: Support variables that are described by more than one MMIAdrian Prantl2015-02-101-5/+12
| | | | | | | | | | table entry. This happens when SROA splits up an alloca and the resulting allocas cannot be lowered to SSA values because their address is passed to a function. Fixes PR22502. llvm-svn: 228764
* Debug info: Fix PR22296 by omitting the DW_AT_location if we lost theAdrian Prantl2015-01-251-4/+7
| | | | | | | | | | | physical register that is described in a DBG_VALUE. In the testcase the DBG_VALUE describing "p5" becomes unavailable because the register its address is in is clobbered and we (currently) aren't smart enough to realize that the value is rematerialized immediately after the DBG_VALUE and/or is actually a stack slot. llvm-svn: 227056
* Remove support for DIVariable's FlagIndirectVariable and expectAdrian Prantl2015-01-191-17/+6
| | | | | | | | | | | | | | | frontends to use a DIExpression with a DW_OP_deref instead. This is not only a much more natural place for this informationl; there is also a technical reason: The FlagIndirectVariable is used to mark a variable that is turned into a reference by virtue of the calling convention; this happens for example to aggregate return values. The inliner, for example, may actually need to undo this indirection to correctly represent the value in its new context. This is impossible to implement because the DIVariable can't be safely modified. We can however safely construct a new DIExpression on the fly. llvm-svn: 226476
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-2/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Debug Info: Implement DwarfCompileUnit::addComplexAddress() usingAdrian Prantl2015-01-141-47/+14
| | | | | | | | DIEDwarfExpression (and get rid of a bunch of redundant code). NFC llvm-svn: 225900
* Debug Info: Don't bother emitting DW_AT_frame_base if the function hasAdrian Prantl2015-01-141-1/+2
| | | | | | no frame register. "Tested" via an assertion triggered by DwarfExpression. llvm-svn: 225858
* Cleanup: Calls to getDwarfRegNum() may actually fail, if there isAdrian Prantl2014-12-051-13/+20
| | | | | | | | | | | | | no DWARF register number mapping, or if the register was a virtual register that was never materialized. Previously, we would just emit a bogus location, after this patch we don't emit a location at all by doing an early exit. After my bugfix in r223401 today, this doesn't actually happen on any target that I tested this with, but it's still preferable to make the possibility of a failure explicit. llvm-svn: 223428
* Debug Info: revert r222195, r222210 and r222239.Manman Ren2014-11-211-2/+2
| | | | | | | This is no longer needed after David's fix at r222377 + r222485. rdar://18958417 llvm-svn: 222563
* Allow DwarfCompileUnit::constructImportedEntityDIE to instanciate a ↵Frederic Riss2014-11-181-0/+2
| | | | | | | | | | | | | | | GlobalVariable DIE. Usually global variables are in a retain list and instanciated before any call to constructImportedEntityDIE is made. This isn't true for forward declarations though. The testcase for this change is generated by a clang patched to emit such forward declarations (patch at http://reviews.llvm.org/D6173 which will land soon). The updated testcase tests more than just global variables, it now tests every type of 'using' clause we support. llvm-svn: 222217
* Debug Info: In DIBuilder, the context field of a global variable is updated toManman Ren2014-11-181-2/+2
| | | | | | | | | | | use DIScopeRef. A paired commit at clang will follow to show cases where we will use an identifer for the context of a global variable. rdar://18958417 llvm-svn: 222195
* Provide gmlt-like inline scope information in the skeleton CU to facilitate ↵David Blaikie2014-11-041-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | symbolication without needing the .dwo files Clang -gsplit-dwarf self-host -O0, binary increases by 0.0005%, -O2, binary increases by 25%. A large binary inside Google, split-dwarf, -O0, and other internal flags (GDB index, etc) increases by 1.8%, optimized build is 35%. The size impact may be somewhat greater in .o files (I haven't measured that much - since the linked executable -O0 numbers seemed low enough) due to relocations. These relocations could be removed if we taught the llvm-symbolizer to handle indexed addressing in the .o file (GDB can't cope with this just yet, but GDB won't be reading this info anyway). Also debug_ranges could be shared between .o and .dwo, though ideally debug_ranges would get a schema that could used index(+offset) addressing, and move to the .dwo file, then we'd be back to sharing addresses in the address pool again. But for now, these sizes seem small enough to go ahead with this. Verified that no other DW_TAGs are produced into the .o file other than subprograms and inlined_subroutines. llvm-svn: 221306
* Use common range handling for the CU's rangesDavid Blaikie2014-11-031-20/+26
| | | | | | | | This generalizes the range handling for ranges in both the skeleton and full unit, laying the foundation for the addition of more ranges (rather than just the CU's special case) in the skeleton CU with fission+gmlt. llvm-svn: 221202
* Push the CURangeList down into the skeleton CU (where available) rather than ↵David Blaikie2014-11-031-1/+1
| | | | | | | | | | | | | | | | | the full CU So that it may be shared between skeleton/full compile unit, for CU ranges and other ranges to be added for fission+gmlt. (at some point we might want some kind of object shared between the skeleton and full compile units for all those things we only want one of in that scope, rather than having the full unit always look through to the skeleton... - alternatively, we might be able to have the skeleton pointer (or another, separate pointer) point to the skeleton or to the unit itself in non-fission, so we don't have to special case its absence) llvm-svn: 221186
* Add DwarfCompileUnit::BaseAddress to track the base address used by relative ↵David Blaikie2014-11-031-1/+1
| | | | | | | | | | | | | | addressing in debug_ranges and debug_loc This is one of a few steps to generalize range handling to include the CU range (thus the CU's range list will be moved into the range list list, losing track of the base address in the process), which means generalizing ranges from both the skeleton and full unit under fission. And... then I can used that generalized support for ranges in fission+gmlt where there'll be a bunch more ranges in the skeleton. llvm-svn: 221182
* Cleanup some unused or trivial functions in DwarfCompileUnitDavid Blaikie2014-11-031-1/+1
| | | | llvm-svn: 221164
* Add DwarfUnit::isDwoUnit and use it to generalize string creationDavid Blaikie2014-11-021-0/+4
| | | | | | | | | | | | | | | | | | | 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-021-1/+2
| | | | | | | | | | | | | | 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-021-0/+8
| | | | llvm-svn: 221092
* Sink DwarfUnit::addExpr into DwarfCompileUnitDavid Blaikie2014-11-021-0/+7
| | | | 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-021-0/+11
| | | | llvm-svn: 221088
* Sink DwarfUnit::addLocationList down into DwarfCompileUnitDavid Blaikie2014-11-021-0/+9
| | | | llvm-svn: 221087
* Sink DwarfUnit::addComplexAddress down into DwarfCompileUnitDavid Blaikie2014-11-021-0/+57
| | | | llvm-svn: 221086
* Push DwarfUnit::addAddress down into DwarfCompileUnitDavid Blaikie2014-11-021-0/+19
| | | | llvm-svn: 221085
* Sink DwarfUnit::addVariableAddress into DwarfCompileUnit since type units ↵David Blaikie2014-11-021-0/+12
| | | | | | don't have variables llvm-svn: 221084
* DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into ↵David Blaikie2014-11-021-0/+17
| | | | | | DwarfCompileUnit llvm-svn: 221083
* 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-021-2/+3
| | | | | | | | | | 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
* Sink dwarf unit length emission down into DwarfUnit::emitHeaderDavid Blaikie2014-11-011-0/+8
| | | | | | | | 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
* Sink DwarfUnit::Skeleton down into DwarfCompileUnitDavid Blaikie2014-11-011-1/+2
| | | | | | | | | 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-011-4/+4
| | | | | | | | | | | 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
* Sink some of DwarfDebug::collectDeadVariables down into DwarfCompileUnit.David Blaikie2014-10-311-0/+21
| | | | llvm-svn: 221010
* Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE into ↵David Blaikie2014-10-311-8/+11
| | | | | | DwarfCompileUnit llvm-svn: 221005
* Sink DwarfUnit::constructImportedEntityDIE into DwarfCompileUnit.Frederic Riss2014-10-241-0/+28
| | | | | | | | | | 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-241-1/+1
| | | | | | | | (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
* DebugInfo: Remove DwarfDebug::CurrentFnArguments since we have to handle ↵David Blaikie2014-10-231-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 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
* Sink the per-CU part of DwarfDebug::finishSubprogramDefinitions into ↵David Blaikie2014-10-101-0/+18
| | | | | | DwarfCompileUnit. llvm-svn: 219477
* Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE down into ↵David Blaikie2014-10-101-0/+29
| | | | | | DwarfCompileUnit. llvm-svn: 219476
* Sink DwarfDebug::createAndAddScopeChildren down into DwarfCompileUnit.David Blaikie2014-10-091-2/+14
| | | | llvm-svn: 219437
OpenPOWER on IntegriCloud