| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 207264
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Makes some more cases (the unit tests, specifically), lexically
compatible with a change to unique_ptr.
llvm-svn: 207261
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207255
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Code review feedback from Paul Robinson on r207022
llvm-svn: 207198
|
|
|
|
| |
llvm-svn: 207083
|
|
|
|
| |
llvm-svn: 207061
|
|
|
|
| |
llvm-svn: 207060
|
|
|
|
| |
llvm-svn: 207059
|
|
|
|
| |
llvm-svn: 207057
|
|
|
|
|
|
| |
Fix for r207049 which would've emitted no accelerated names at all...
llvm-svn: 207051
|
|
|
|
| |
llvm-svn: 207050
|
|
|
|
|
|
| |
(similar changes coming for the other accelerator tables)
llvm-svn: 207049
|
|
|
|
| |
llvm-svn: 207044
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207025
|
|
|
|
| |
llvm-svn: 207022
|
|
|
|
| |
llvm-svn: 207016
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
For now it contains a single flag, SanitizeAddress, which enables
AddressSanitizer instrumentation of inline assembly.
Patch by Yuri Gorshenin.
llvm-svn: 206971
|
|
|
|
| |
llvm-svn: 206927
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 206837
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 206507
|
|
|
|
|
|
|
| |
Range'ify loops and tidy up some by-reference handling. No functional
change.
llvm-svn: 206422
|
|
|
|
| |
llvm-svn: 206248
|
|
|
|
| |
llvm-svn: 206246
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to dblaikie for updating the testcase!
Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions,
therefore, their declaration cannot have one DW_AT_linkage_name.
The specific instances however can and should have that attribute.
This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE()
to emit linkage names for C/Dtors.
rdar://problem/16362674.
llvm-svn: 206210
|
|
|
|
|
|
|
| |
DWARF3 introduced DW_TAG_restrict_type, so avoid using it in prior
versions.
llvm-svn: 206105
|
|
|
|
|
|
|
| |
This reverts commit 206096 while I investigate why this broke the gdb
buildbot.
llvm-svn: 206103
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
therefore, their declaration cannot have one DW_AT_linkage_name.
The specific instances however can and should have that attribute.
This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE()
to emit linkage names for C/Dtors.
rdar://problem/16362674.
llvm-svn: 206096
|
|
|
|
|
|
|
|
| |
so DwarfDebug::emitDebugLocEntry can emit them with the correct signedness.
rdar://problem/15928306
llvm-svn: 206042
|
|
|
|
|
|
| |
into a function.
llvm-svn: 205973
|
|
|
|
|
|
|
|
|
|
|
| |
While we were encoding 64 bit values (data8) in the subrange itself,
using a 32 bit type for the subrange was still confusing the gdb. Oh,
and make it unsigned too.
As the comment points out, this could be pushed into the frontend so
that it would be 32 or 64 bit as appropriate, etc.
llvm-svn: 205512
|
|
|
|
|
|
| |
Patch by Alex Crichton, ILyoan, Luqman Aden and Svetoslav.
llvm-svn: 205430
|
|
|
|
| |
llvm-svn: 205429
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 205386
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 205374
|
|
|
|
|
|
|
|
|
|
| |
Seems we didn't have any test coverage for merging... awesome. So I
added some - but hit an llvm-objdump bug while I was there. I'm choosing
not to shave that yak right now.
Code review feedback/bug catch by Adrian Prantl in r205360.
llvm-svn: 205373
|