| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Post commit review feedback from Paul Robinson regarding r207777.
llvm-svn: 207782
|
| |
|
|
|
|
|
|
| |
This the LLVM portion that will allow Clang and other frontends to emit
typedefs of void by providing a null type for the typedef's underlying
type.
llvm-svn: 207777
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
DW_AT_object_pointer to go missing on blocks
Noticed by inspection. Test coverage added.
llvm-svn: 207333
|
| |
|
|
| |
llvm-svn: 207324
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 207284
|
| |
|
|
|
|
|
|
| |
low_pc similar to location lists.
Fixes PR19563
llvm-svn: 207283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildbot - do not insert debug intrinsics before phi nodes.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207269
|
| |
|
|
|
|
|
|
| |
check for"
This reverts commit 207235 to investigate msan buildbot breakage.
llvm-svn: 207250
|
| |
|
|
|
|
|
|
|
|
| |
Debug info: Let dbg.values inserted by LowerDbgDeclare inherit the location
of the dbg.value. This gets rid of tons of redundant variable DIEs in
subscopes.
rdar://problem/14874886, rdar://problem/16679936
llvm-svn: 207236
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AllocaInst that was missing in one location.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207235
|
| |
|
|
|
|
|
|
| |
check for"
Typo in testcase.
llvm-svn: 207166
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AllocaInst that was missing in one location.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207165
|
| |
|
|
|
|
|
|
| |
stack and"
This reverts commit 207130 for buildbot breakage.
llvm-svn: 207162
|
| |
|
|
|
|
|
|
| |
location"
This reverts commit 207130 for buildbot breakage.
llvm-svn: 207159
|
| |
|
|
|
|
|
|
|
| |
of the dbg.value. This gets rid of tons of redundant variable DIEs in
subscopes.
rdar://problem/14874886, rdar://problem/16679936
llvm-svn: 207135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine-intrinsics testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207130
|
| |
|
|
|
|
|
| |
Emit the flag to indicate to the assembler that a section contains data if there
is pre-populated data present.
llvm-svn: 207028
|
| |
|
|
|
|
|
|
|
|
|
| |
describing it.
This is important for symbolizing executables with debug info in
unavailable .dwo files. Even if all DIE entries are missing, we can
still symbolize an address: function name can be fetched from symbol table,
and file/line info can be fetched from line table.
llvm-svn: 206665
|
| |
|
|
|
|
| |
Changes requested in code review by Eric Christopher of r206130.
llvm-svn: 206219
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I found this from a particular GDB test suite case of inlining
(something similar is provided as a test case) but came across a few
other related cases (other callers of the same functions, and one other
instance of the same coding mistake in a separate function).
I'm not sure what the best way to test this is (let alone to cover the
other cases I discovered), so hopefully this sufficies - open to ideas.
llvm-svn: 206130
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 206046
|
| |
|
|
|
|
|
|
| |
so DwarfDebug::emitDebugLocEntry can emit them with the correct signedness.
rdar://problem/15928306
llvm-svn: 206042
|
| |
|
|
| |
llvm-svn: 205899
|
| |
|
|
|
|
|
| |
DW_LNE_set_address was misemitted on x64.
FIXME: I haven't investigate whether CalleeSaveStackSlotSize should be 8.
llvm-svn: 205772
|
| |
|
|
|
|
| |
that at least failed reliably.
llvm-svn: 205711
|
| |
|
|
|
|
|
|
|
| |
cygwin has llvm-dwarfdump problems and isn't paying attention to the
specific xfail there.
s390x isn't matching for an unknown reason.
llvm-svn: 205708
|
| |
|
|
|
|
| |
it's being investigated for those.
llvm-svn: 205704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of DW_TAG_imported_module
I really should read the spec more often (and test GCC more often too).
I just assumed that namespace aliases would be the same as using
directives, except with a name. But apparently that's not how the DWARF
standards suggests they be implemented. DWARF4 provides an example and
other non-normative text suggesting that namespace aliases be
implemented by named imported declarations intsead of named imported
modules.
So be it.
llvm-svn: 205685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86_64-mingw32.
Sorry for the breakage.
For now, it will fail in two ways:
1. To fail for targeting x86_64-mingw32.
<stdin>:131:8: note: possible intended match here
0x30830a0100000002 3 0 1 0 0 is_stmt
2. To fail not to find the target x86.
llc: : error: unable to get target for 'x86_64-unknown-unknown',
see --version and --triple.
llvm-svn: 205621
|
| |
|
|
| |
llvm-svn: 205581
|
| |
|
|
|
|
| |
explicit triple for now.
llvm-svn: 205563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fail on cygming.
That said, it emits errors to the stderr (with exit(0));
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_DIR32
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_DIR32
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_SECREL
error: failed to compute relocation: IMAGE_REL_I386_DIR32
llvm-svn: 205560
|
| |
|
|
|
|
|
|
|
|
|
|
| |
these is very much off and is more than just the branch
from this bug incorrect:
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x30830a0100000002 3 0 1 0 0 is_stmt
0x30830a0100000008 3 0 1 0 0 is_stmt end_sequence
llvm-svn: 205551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
slightly more verbose than needed line tables, e.g.:
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
0x0000000000000000 1 0 1 0 0 is_stmt
0x0000000000000000 1 0 1 0 0 is_stmt prologue_end
0x0000000000000010 2 0 1 0 0 is_stmt
0x0000000000000018 4 0 1 0 0 is_stmt
these should probably be looked at, but it isn't affecting the correctness
of the testcase.
llvm-svn: 205546
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llc doesn't generate nodes for unconditional fall-through branches for targets
without FastISel implementation (X86 has it, but can be disabled by
"-fast-isel=false") in SelectionDAGBuilder::visitBr().
So for line 4 in the following testcase
1: void foo(int i){
2: switch(i){
3: default:
4: break;
5: }
6: return;
7: }
there is no corresponding line in .debug_line section, and a debugger
cannot set a breakpoint at line 4.
Fix this by always emitting a branch when we're not optimizing and add a
testcase to ensure that there's code on every line we'd want to break.
Patch by Daniil Fukalov.
llvm-svn: 205529
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This should bring the arm buildbots back.
llvm-svn: 205502
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
constants into only the first one.
rdar://14874886.
llvm-svn: 205357
|
| |
|
|
|
|
|
|
|
|
|
|
| |
special case of '0' in DwarfCompileUnit::initStmtList by just always using a label difference
This moves one case of raw text checking down into the MCStreamer
interfaces in the form of a virtual function, even if we ultimately end
up consolidating on the one-or-many line tables issue one day, this is
nicer in the interim. This just generally streamlines a bunch of use
cases into a common code path.
llvm-svn: 205287
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
|