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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207442 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207441 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207323 91177308-0d34-0410-b5e6-96231b3b80d8
Sinking addition of the declaration attribute down to where the
signature is added. So that if the signature is not added neither is the
declaration attribute (this will come in handy when aborting type unit
construction to instead emit the type into the CU directly in some
cases)
Pull out type unit identifier hashing just to simplify the function a
little, it'll be getting longer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207321 91177308-0d34-0410-b5e6-96231b3b80d8
This also avoids the need for subtly side-effecting calls to manifest
strings in the string table at the point where items are added to the
accelerator tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207281 91177308-0d34-0410-b5e6-96231b3b80d8
Pulls out some more code from some of the rather monolithic DWARF
classes. Unlike the address table, the string table won't move up into
DwarfDebug - each DWARF file has its own string table (but there can be
only one address table).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207277 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207263 91177308-0d34-0410-b5e6-96231b3b80d8
Makes some more cases (the unit tests, specifically), lexically
compatible with a change to unique_ptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207261 91177308-0d34-0410-b5e6-96231b3b80d8
Since this doesn't return ownership (the DIE has been added to the
specified parent already) nor return null, just return by reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207259 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207253 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207026 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207010 91177308-0d34-0410-b5e6-96231b3b80d8
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...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206925 91177308-0d34-0410-b5e6-96231b3b80d8
So Chandler - how about those range algorithms? (would really love a
dereferencing range adapter for this sort of stuff)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206921 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206867 91177308-0d34-0410-b5e6-96231b3b80d8
define below all header includes in the lib/CodeGen/... tree. While the
current modules implementation doesn't check for this kind of ODR
violation yet, it is likely to grow support for it in the future. It
also removes one layer of macro pollution across all the included
headers.
Other sub-trees will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206837 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206780 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This prevents the discriminator generation pass from triggering if
the DWARF version being used in the module is prior to 4.
Reviewers: echristo, dblaikie
CC: llvm-commits
Differential Revision: http://reviews.llvm.org/D3413
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206507 91177308-0d34-0410-b5e6-96231b3b80d8
Got bored, removed some manual memory management.
Pushed references (rather than pointers) through a few APIs rather than
replacing *x with x.get().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206222 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206098 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not sure the comment in the implementation really adds a lot of
value (it's clear that we emit zero when no symbol is provided, but it
doesn't explain why we would do that). Happy to iterate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205386 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205382 91177308-0d34-0410-b5e6-96231b3b80d8
No other functionality changes, DIBuilder testcase is included in a paired
CFE commit.
This relaxes the assertion in isScopeRef to also accept subclasses of
DIScope.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205279 91177308-0d34-0410-b5e6-96231b3b80d8
Implement debug_loc.dwo, as well as llvm-dwarfdump support for dumping
this section.
Outlined in the DWARF5 spec and http://gcc.gnu.org/wiki/DebugFission the
debug_loc.dwo section has more variation than the standard debug_loc,
allowing 3 different forms of entry (plus the end of list entry). GCC
seems to, and Clang certainly, only use one form, so I've just
implemented dumping support for that for now.
It wasn't immediately obvious that there was a good refactoring to share
the implementation of dumping support between debug_loc and
debug_loc.dwo, so they're separate for now - ideas welcome or I may come
back to it at some point.
As per a comment in the code, we could choose different forms that may
reduce the number of debug_addr entries we emit, but that will require
further study.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204697 91177308-0d34-0410-b5e6-96231b3b80d8
This seems excessive - switching section isn't expensive (or if it is
we're already being wasteful, since we emitted the debug_loc section
symbol earlier anyway) and otherwise there's no work that happens in
this function when the list is empty.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204696 91177308-0d34-0410-b5e6-96231b3b80d8
