Commit Graph

132 Commits

Author SHA1 Message Date
Adrian Prantl ab255fcd09 Cleanup: Calls to getDwarfRegNum() may actually fail, if there is
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
2014-12-05 01:02:46 +00:00
David Blaikie 3a443c29b9 Provide gmlt-like inline scope information in the skeleton CU to facilitate 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
2014-11-04 22:12:25 +00:00
David Blaikie 5b02a19f90 Use common range handling for the CU's ranges
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
2014-11-03 23:10:59 +00:00
David Blaikie bc532b44a0 Sink DwarfUnit::CURanges into DwarfCompileUnit
llvm-svn: 221161
2014-11-03 16:40:43 +00:00
David Blaikie 89a26f012a Sink range list handling down from DwarfUnit into its only use, in DwarfCompileUnit.
llvm-svn: 221123
2014-11-03 02:41:49 +00:00
David Blaikie cafd962d97 Add DwarfUnit::isDwoUnit and use it to generalize string creation
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
2014-11-02 08:51:37 +00:00
David Blaikie 279c451c0b Remove the last mention of LineTablesOnly from DwarfUnit, sinking it into 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
2014-11-02 08:18:06 +00:00
David Blaikie 3363a57c8e Sink DwarfUnit::applySubprogramAttributesToDefinition into DwarfCompileUnit
llvm-svn: 221092
2014-11-02 08:09:09 +00:00
David Blaikie 978020807a Sink DwarfUnit::addExpr into DwarfCompileUnit
llvm-svn: 221090
2014-11-02 07:11:55 +00:00
David Blaikie 02a6333ba7 Sink DwarfUnit::applyVariableAttributes into DwarfCompileUnit
llvm-svn: 221088
2014-11-02 07:06:51 +00:00
David Blaikie 4bc0881ac7 Sink DwarfUnit::addLocationList down into DwarfCompileUnit
llvm-svn: 221087
2014-11-02 07:03:19 +00:00
David Blaikie 77895fb276 Sink DwarfUnit::addComplexAddress down into DwarfCompileUnit
llvm-svn: 221086
2014-11-02 06:58:44 +00:00
David Blaikie f7435ee6ce Push DwarfUnit::addAddress down into DwarfCompileUnit
llvm-svn: 221085
2014-11-02 06:46:40 +00:00
David Blaikie 7d48be2b7b Sink DwarfUnit::addVariableAddress into DwarfCompileUnit since type units don't have variables
llvm-svn: 221084
2014-11-02 06:37:23 +00:00
David Blaikie 192b45c1ef DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into DwarfCompileUnit
llvm-svn: 221083
2014-11-02 06:16:39 +00:00
David Blaikie 98cf172175 Add DwarfUnit::addGlobalType to match DwarfUnit::addGlobalName
(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
2014-11-02 06:06:14 +00:00
David Blaikie 871c2d9d63 DebugInfo: Refactor index type DIE initialization by rolling it into the accessor
llvm-svn: 221080
2014-11-02 03:09:13 +00:00
David Blaikie f4bdc31271 Sink DwarfUnit::LabelBegin down into DwarfCompileUnit since that's the only place it's needed.
llvm-svn: 221075
2014-11-02 01:21:40 +00:00
David Blaikie 983bfea0d0 Remove DwarfUnit::LabelEnd in favor of computing the length of the section 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
2014-11-01 23:07:14 +00:00
David Blaikie a34568b220 Sink DwarfUnit::SectionSym into DwarfCompileUnit as it's only needed/used there.
llvm-svn: 221062
2014-11-01 20:06:28 +00:00
David Blaikie 7cbf58af15 Sink DwarfUnit::Skeleton down into DwarfCompileUnit
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
2014-11-01 18:18:07 +00:00
David Blaikie 2f08093dda Remove unused function
llvm-svn: 221037
2014-11-01 01:15:26 +00:00
Frederic Riss 987fe22789 Sink DwarfUnit::constructImportedEntityDIE into DwarfCompileUnit.
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
2014-10-24 21:31:09 +00:00
David Blaikie 58410f241e Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE down into DwarfCompileUnit.
llvm-svn: 219476
2014-10-10 06:39:26 +00:00
David Blaikie ee7df55306 Move DwarfUnit::constructVariableDIE down to DwarfCompileUnit, since it's only needed there.
llvm-svn: 219418
2014-10-09 17:56:36 +00:00
David Blaikie e5feec502d Sink DwarfUnit::addSectionDelta into DwarfCompileUnit, the only place it's needed.
llvm-svn: 219364
2014-10-08 23:30:05 +00:00
David Blaikie 6c0ee4ece3 Sink and coalesce DwarfDebug.cpp::addSectionLabel and DwarfUnit::addSectionLabel down into DwarfCompileUnit::addSectionLabel
llvm-svn: 219351
2014-10-08 22:46:27 +00:00
David Blaikie febfafd13a DebugInfo: Sink constructImportedEntityDIE down into DwarfUnit from DwarfDebug.
It was just calling a bunch of DwarfUnit functions anyway, as can be
seen by the simplification of removing "TheCU" from all the function
calls in the implementation.

llvm-svn: 219103
2014-10-06 05:37:24 +00:00
Benjamin Kramer c6cc58e703 Remove unnecessary copying or replace it with moves in a bunch of places.
NFC.

llvm-svn: 219061
2014-10-04 16:55:56 +00:00
David Blaikie 37c5231051 Move DwarfCompileUnit from DwarfUnit.h to its own header (DwarfCompileUnit.h)
In preparation for sinking all the subprogram emission code down from
DwarfDebug into DwarfCompileUnit, this will avoid bloating
DwarfUnit.h/cpp greatly and make concerns a bit more clear/isolated.

(sinking this handling down is part of the work to handle emitting
minimal subprograms for -gmlt-like data into the skeleton CU under
fission)

llvm-svn: 219057
2014-10-04 15:49:50 +00:00
Frederic Riss 9ba9efff56 Change DwarfCompileUnit::createGlobalVariable to getOrCreateGlobalVariable.
Summary:
This will allow to request the creation of a forward delacred variable
at is point of use (for imported declarations, this will be
DwarfDebug::constructImportedEntityDIE) rather than having to put the
forward decl in a retention list.

Note that getOrCreateGlobalVariable returns the actual definition DIE when the
routine creates a declaration and a definition DIE. If you agree this is the
right behavior, then I'll have a followup patch that registers the definition
in the DIE map instead of the declaration as it is today (this 'breaks' only
one test, where we test that the imported entity is the declaration). I'm
not sure what's best here, but it's easy enough for a consumer to follow the
DW_AT_specification link to get to the declaration, whereas it takes more
work to find the actual definition from a declaration DIE.

Reviewers: echristo, dblaikie, aprantl

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5381

llvm-svn: 218126
2014-09-19 15:12:03 +00:00
David Blaikie d0f103775a Sink PrevCU updating into DwarfUnit::addRange to ensure consistency
So that the two operations in DwarfDebug couldn't get separated (because
I accidentally separated them in some work in progress), put them
together. While we're here, move DwarfUnit::addRange to
DwarfCompileUnit, since it's not relevant to type units.

llvm-svn: 217468
2014-09-09 23:13:01 +00:00
Craig Topper 6dc4a8bc2c Fix some cases where StringRef was being passed by const reference. Remove const from some other StringRefs since its implicitly const already.
llvm-svn: 216820
2014-08-30 16:48:02 +00:00
Benjamin Kramer a7c40ef022 Canonicalize header guards into a common format.
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

llvm-svn: 215558
2014-08-13 16:26:38 +00:00
Adrian Prantl b1416837f9 Debug info: Infrastructure to support debug locations for fragmented
variables (for example, by-value struct arguments passed in registers, or
large integer values split across several smaller registers).
On the IR level, this adds a new type of complex address operation OpPiece
to DIVariable that describes size and offset of a variable fragment.
On the DWARF emitter level, all pieces describing the same variable are
collected, sorted and emitted as DWARF expressions using the DW_OP_piece
and DW_OP_bit_piece operators.

http://reviews.llvm.org/D3373
rdar://problem/15928306

What this patch doesn't do / Future work:
- This patch only adds the backend machinery to make this work, patches
  that change SROA and SelectionDAG's type legalizer to actually create
  such debug info will follow. (http://reviews.llvm.org/D2680)
- Making the DIVariable complex expressions into an argument of dbg.value
  will reduce the memory footprint of the debug metadata.
- The sorting/uniquing of pieces should be moved into DebugLocEntry,
  to facilitate the merging of multi-piece entries.

llvm-svn: 214576
2014-08-01 22:11:58 +00:00
Manman Ren f8a1967c8c [Debug Info] add DISubroutineType and its creation takes DITypeArray.
DITypeArray is an array of DITypeRef, at its creation, we will create
DITypeRef (i.e use the identifier if the type node has an identifier).

This is the last patch to unique the type array of a subroutine type.

rdar://17628609

llvm-svn: 214132
2014-07-28 22:24:06 +00:00
David Blaikie 29459ae83c Reapply "DebugInfo: Don't put fission type units in comdat sections."
This recommits r208930, r208933, and r208975 (by reverting r209338) and
reverts r209529 (the FIXME to readd this functionality once the tools
were fixed) now that DWP has been fixed to cope with a single section
for all fission type units.

Original commit message:

"Since type units in the dwo file are handled by a debug aware tool,
they don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization."

llvm-svn: 213956
2014-07-25 17:11:58 +00:00
David Blaikie eb1a27239c DebugInfo: Following up to r209677, refactor local variable emission to delay the choice between emitting the definition attributes or using DW_AT_abstract_definition
This doesn't fix the abstract variable handling yet, but it introduces a
similar delay mechanism as was added for subprograms, causing
DW_AT_location to be reordered to the beginning of the attribute list
for local variables, and fixes all the test fallout for that.

A subsequent commit will remove the abstract variable handling in
DbgVariable and just do the abstract variable lookup at module end to
ensure that abstract variables introduced after their concrete
counterparts are appropriately referenced by the concrete variable.

llvm-svn: 210943
2014-06-13 22:18:23 +00:00
David Blaikie 3dca59902b DebugInfo: Use the scope of the function declaration, if any, to name a function in DWARF pubnames
This ensures that member functions, for example, are entered into
pubnames with their fully qualified name, rather than inside the global
namespace.

llvm-svn: 210379
2014-06-06 22:29:05 +00:00
David Blaikie b85f0080e7 DebugInfo: Simplify solution to avoid DW_AT_artificial on inlined parameters.
Originally committed in r207717, I clearly didn't look very closely at
the code to understand how existing things were working...

llvm-svn: 209680
2014-05-27 19:34:32 +00:00
David Blaikie 7f91686f07 DebugInfo: Separate out the addition of subprogram attribute additions so that they can be added later depending on whether or not the function is inlined.
llvm-svn: 209673
2014-05-27 18:37:38 +00:00
David Blaikie 2da282b860 Revert "DebugInfo: Don't put fission type units in comdat sections."
This reverts commit r208930, r208933, and r208975.

It seems not all fission consumers are ready to handle this behavior.
Reverting until tools are brought up to spec.

llvm-svn: 209338
2014-05-21 23:27:41 +00:00
David Blaikie 962c9a2d54 DebugInfo: Follow up to r208930, comment usage of 'using' to bring in base class overload.
Code review feedback from Eric Christopher.

llvm-svn: 208933
2014-05-15 23:29:53 +00:00
David Blaikie bc094f387b DebugInfo: Don't put fission type units in comdat sections.
Since type units in the dwo file are handled by a debug aware tool, they
don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization.

llvm-svn: 208930
2014-05-15 23:18:15 +00:00
David Blaikie 60cae1ba49 DwarfUnit: Pick a winner between isTypeSigned and isUnsignedDIType.
And the winner by a nose is isUnsignedDIType, for no particular reason.

These two functions were just complements of each other and used in very
related code, so refactor callers to just use one of them.

llvm-svn: 208500
2014-05-11 16:08:41 +00:00
David Blaikie c0a2841e2f DwarfUnit: Factor out calling isUnsignedDIType into a utility function so each caller of emitConstantValue doesn't have to call it separately.
llvm-svn: 208496
2014-05-11 15:56:59 +00:00
David Blaikie c05c8f483b DwarfUnit: Share common constant value emission between APInts of small (<= 64 bit) and MCOperand immediates.
Doesn't seem a good reason to duplicate this code (it was more literally
duplicated prior to r208494, and while the dataN code /does/ actually
fire in this case, it doesn't seem necessary (and the DWARF standard
recommends using udata/sdata pervasively instead of dataN, so as to
indicate signedness of the values))

llvm-svn: 208495
2014-05-11 15:47:39 +00:00
David Blaikie 899ae61fee Revert "Emit DW_AT_object_pointer once, on the declaration, for each function."
Breaks GDB buildbot
(http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/14517)

GCC emits DW_AT_object_pointer /everywhere/ (declaration, abstract
definition, inlined subroutine), but it looks like GCC relies on it
being somewhere other than the declaration, at least. I'll experiment
further & can hopefully still remove it from the inlined_subroutine.

This reverts commit r207705.

llvm-svn: 207719
2014-04-30 22:58:19 +00:00
David Blaikie 44078b3260 DebugInfo: Omit DW_AT_artificial on DW_TAG_formal_parameters in DW_TAG_inlined_subroutines.
They just don't need to be there - they're inherited from the abstract
definition. In theory I would like them to be inherited from the
declaration, but the DWARF standard doesn't quite say that... we can
probably do it anyway but I'm less confident about that so I'll leave it
for a separate commit.

llvm-svn: 207717
2014-04-30 22:41:33 +00:00
David Blaikie 3b2a53a437 Emit DW_AT_object_pointer once, on the declaration, for each function.
This effectively reverts r164326, but adds some comments and
justification and ensures we /don't/ emit the DW_AT_object_pointer on
the (abstract and concrete) definitions. (while still preserving it on
standalone definitions involving ObjC Blocks)

This does increase the size of member function declarations from 7 to 11
bytes, unfortunately, but still seems like the Right Thing to do so that
callers that see only the declaration still have the information about
the object pointer. That said, I don't know what, if any, DWARF
consumers don't have a heuristic to guess this in the case of normal
C++ member functions - perhaps we can remove it entirely.

llvm-svn: 207705
2014-04-30 21:29:41 +00:00