| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
functions that do not have top level debug information." as it appears to be breaking some LTO constructs.
This reverts commit r212203.
llvm-svn: 212298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not have top level debug information.
If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.
While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.
Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.
Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).
llvm-svn: 212203
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
solely on the delayed handling introduced in r210946
Now that we handle finding abstract variables at the end of the module,
remove the upfront handling and just ensure the abstract variable is
built when necessary.
In theory we could have a split implementation, where inlined variables
are immediately constructed referencing the abstract definition, and
concrete variables are delayed - but let's go with one solution for now
unless there's a reason not to.
llvm-svn: 210961
|
| |
|
|
|
|
|
|
|
|
|
|
| |
definitions that preceed their first inline definition.
Rather than relying on abstract variables looked up at the time the
concrete variable is created, look them up at the end of the module to
ensure they're referenced even if they're created after the concrete
definition. This completes/matches the work done in r209677 to handle
this for the subprograms themselves.
llvm-svn: 210946
|
| |
|
|
|
|
| |
parameter that didn't need to be mutated.
llvm-svn: 210944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
rather than looking it up through the DebugLoc.
No functional change intended, just streamlines the abstract variable
lookup/construction to use a common entry point.
llvm-svn: 210234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DbgVariables have DIEs.
Abstract variables within abstract scopes that are entirely optimized
away in their first inlining are omitted because their scope is not
present so the variable is never created. Instead, we should ensure the
scope is created so the variable can be added, even if it's been
optimized away in its first inlining.
This fixes the incorrect debug info in missing-abstract-variable.ll
(added in r210143) and passes an asserts self-hosting build, so
hopefully there's not more of these issues left behind... *fingers
crossed*.
llvm-svn: 210221
|
| |
|
|
| |
llvm-svn: 209920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definitions preceed inline definitions.
After much puppetry, here's the major piece of the work to ensure that
even when a concrete definition preceeds all inline definitions, an
abstract definition is still created and referenced from both concrete
and inline definitions.
Variables are still broken in this case (see comment in
dbg-value-inlined-parameter.ll test case) and will be addressed in
follow up work.
llvm-svn: 209677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a precursor to fixing inlined debug info where the concrete,
out-of-line definition may preceed any inlined usage. To cope with this,
the attributes that may appear on the concrete definition or the
abstract definition are delayed until the end of the module. Then, if an
abstract definition was created, it is referenced (and no other
attributes are added to the out-of-line definition), otherwise the
attributes are added directly to the out-of-line definition.
In a couple of cases this causes not just reordering of attributes, but
reordering of types. When the creation of the attribute is delayed, if
that creation would create a type (such as for a DW_AT_type attribute)
then other top level DIEs may've been constructed during the delay,
causing the referenced type to be created and added after those
intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this
actually causes the DW_TAG_basic_type for "int" to move from one CU to
another.
llvm-svn: 209674
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
reference their abstract origins.
llvm-svn: 209327
|
| |
|
|
|
|
| |
function.
llvm-svn: 208997
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
definitions.
This is just unneccessary - we only create abstract definitions when
we're inlining anyway, so there's no reason to delay this to see if
we're going to inline anything.
llvm-svn: 208798
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Get rid of UserVariables set, and turn DbgValues into MapVector
to get a fixed ordering, as suggested in review for http://reviews.llvm.org/D3573.
Test Plan: llvm regression tests
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3579
llvm-svn: 207720
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No functionality change.
Test Plan: llvm regression test suite.
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: echristo, llvm-commits
Differential Revision: http://reviews.llvm.org/D3573
llvm-svn: 207708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
DwarfDebug.h has a SmallVector member containing a unique_ptr of an
incomplete type. MSVC doesn't have key functions, so the vtable and
dtor are emitted in AsmPrinter.cpp, where DwarfDebug's ctor is called.
AsmPrinter.cpp include DwarfUnit.h and doesn't get a complete definition
of DwarfTypeUnit. We could fix the problem by including DwarfUnit.h in
DwarfDebug.h, but that would increase header bloat. Instead, define
~DwarfDebug out of line.
llvm-svn: 207701
|
| |
|
|
|
|
| |
Caught by Eric Christopher in post-commit review.
llvm-svn: 207595
|
| |
|
|
|
|
|
|
|
|
|
| |
DIEs.
These were called from distinct places and had significant distinct
behavior. No need to make that a dynamic check inside the function
rather than just having two functions (refactoring some common code into
a helper function to be called from the two separate functions).
llvm-svn: 207539
|
| |
|
|
|
|
|
|
|
|
| |
Now that the subtle constructScopeDIE has been refactored into two
functions - one returning memory to take ownership of, one returning a
pointer to already owning memory - push unique_ptr through more APIs.
I think this completes most of the unique_ptr ownership of DIEs.
llvm-svn: 207442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While refactoring out constructScopeDIE into two functions I realized we
were emitting DW_AT_object_pointer in the inlined subroutine when we
didn't need to (GCC doesn't, and the abstract subprogram definition has
the information already).
So here's the refactoring and the bug fix. This is one step of
refactoring to remove some subtle memory ownership semantics. It turns
out the original constructScopeDIE returned ownership in its return
value in some cases and not in others. The split into two functions now
separates those two semantics - further cleanup (unique_ptr, etc) will
follow.
llvm-svn: 207441
|
| |
|
|
| |
llvm-svn: 207394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
requires an address.
Since there's no way to ensure the type unit in the .dwo and the type
unit skeleton in the .o are correlated, this cannot work.
This implementation is a bit inefficient for a few reasons, called out
in comments.
llvm-svn: 207323
|
| |
|
|
|
|
|
|
|
|
|
| |
This should reduce the chance of memory leaks like those fixed in
r207240.
There's still some unclear ownership of DIEs happening in DwarfDebug.
Pushing unique_ptr and references through more APIs should help expose
the cases where ownership is a bit fuzzy.
llvm-svn: 207263
|
| |
|
|
|
|
|
| |
Since this doesn't return ownership (the DIE has been added to the
specified parent already) nor return null, just return by reference.
llvm-svn: 207259
|
| |
|
|
|
|
|
|
| |
This'll make changing to unique_ptr ownership of DIEs easier since the
usages will now have '*' on them making them textually compatible
between unique_ptr and raw pointer.
llvm-svn: 207253
|
| |
|
|
|
|
| |
non-null DIE by reference to DbgVariable::setDIE
llvm-svn: 207244
|
| |
|
|
| |
llvm-svn: 207061
|
| |
|
|
| |
llvm-svn: 207060
|
| |
|
|
| |
llvm-svn: 207059
|
| |
|
|
| |
llvm-svn: 207057
|
| |
|
|
|
|
| |
(similar changes coming for the other accelerator tables)
llvm-svn: 207049
|
| |
|
|
|
|
|
|
|
| |
There's only ever one address pool, not one per DWARF output file, so
let's just have one.
(similar refactoring of the string pool to come soon)
llvm-svn: 207026
|
| |
|
|
|
|
|
|
| |
Some of these types (DwarfDebug in particular) are quite large to begin
with (and I keep forgetting whether DwarfFile is in DwarfDebug or
DwarfUnit... ) so having a few smaller files seems like goodness.
llvm-svn: 207010
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This prompted me to push references through most of DwarfDebug. Sorry
for the churn.
Honestly it's a bit silly that we're passing around units all over the
place like that anyway and I think it's mostly due to the DIE attribute
adding utility functions being utilities in DwarfUnit. I should have
another go at moving them out of DwarfUnit...
llvm-svn: 206925
|
| |
|
|
|
|
|
| |
So Chandler - how about those range algorithms? (would really love a
dereferencing range adapter for this sort of stuff)
llvm-svn: 206921
|
| |
|
|
| |
llvm-svn: 206905
|
| |
|
|
|
|
|
|
|
|
|
| |
allocation/pointers."
This reverts commit r206780.
This commit was regressing gdb.opt/inline-locals.exp in the GDB 7.5 test
suite. Reverting until I can fix the issue.
llvm-svn: 206867
|
| |
|
|
|
|
|
|
|
|
| |
allocation/pointers.
Requires switching some vectors to lists to maintain pointer validity.
These could be changed to forward_lists (singly linked) with a bit more
work - I've left comments to that effect.
llvm-svn: 206780
|
| |
|
|
|
|
|
|
|
| |
Got bored, removed some manual memory management.
Pushed references (rather than pointers) through a few APIs rather than
replacing *x with x.get().
llvm-svn: 206222
|
| |
|
|
|
|
|
|
|
|
|
| |
Nice to be able to just print out the Tag and have the debugger print
dwarf::DW_TAG_subprogram or whatever, rather than an int.
It's a bit finicky (for example DIDescriptor::getTag still returns
unsigned) because some places still handle real dwarf tags + our fake
tags (one day we'll remove the fake tags, hopefully).
llvm-svn: 206098
|
| |
|
|
|
|
| |
Based on code review feedback from Eric Christopher on r204697
llvm-svn: 205385
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and an MC Label to refer to them
This removes the magic-number-esque code creating/retrieving the same
label for a debug_loc entry from two places and removes the last small
piece of reusable logic from emitDebugLoc so that there will be less
duplication when refactoring it into two functions (one for debug_loc,
the other for debug_loc.dwo).
llvm-svn: 205382
|
| |
|
|
|
|
|
| |
It seems big enough that it deserves its own file - but it is header
only, so there's no need for another cpp file, etc.
llvm-svn: 205360
|
| |
|
|
|
|
|
|
| |
constants into only the first one.
rdar://14874886.
llvm-svn: 205357
|
| |
|
|
|
|
|
|
|
| |
debug_loc.dwo location list entries
In preparation for refactoring this function into two, one for
debug_loc, one for debug_loc.dwo.
llvm-svn: 205324
|