With the added debug assertions this fix is covered by existing Clang
tests. (& found some other issues, also fixed)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189495 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the noise in diffs making it more likely that, at least for
LLVM revision-over-revision, diffs will actually yield usable results.
This is consistent with objdump's DWARF dumping behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188650 91177308-0d34-0410-b5e6-96231b3b80d8
We check this in many/all other cases, just missed this one it seems.
Perhaps it'd be worth unifying this so we never emit zero-length
DW_AT_names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188649 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary to allow Clang to only emit implicit members when
there is code generated for them, rather than whenever they are ODR
used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188082 91177308-0d34-0410-b5e6-96231b3b80d8
Since the pool indexes are necessarily sequential and contiguous, just
insert things in the right place rather than having to sort the sequence
after the fact.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185842 91177308-0d34-0410-b5e6-96231b3b80d8
We were being a bit too aggresive here in classifying global variables
with no global reference or constant value to be invalid - this would
cause LLVM to not emit the DWARF description of the global variable if
it had been optimized away, which isn't helpful for users who might
benefit from the global variable's description even if there's no
location information.
This also fixes a crasher issue here that I was unable to reduce a test
case for - involving a using decl (& subsequent
DW_TAG_imported_declaration ) of such a global variable that, once
optimized away, would crash when an attempt to emit the imported
declaration was made.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185675 91177308-0d34-0410-b5e6-96231b3b80d8
Restrict the current TLS support to X86 ELF for now. Test that we don't
produce it on PPC & we can flesh that test case out with the right thing
once someone implements it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185389 91177308-0d34-0410-b5e6-96231b3b80d8
Based on GCC's output for TLS variables (OP_constNu, x@dtpoff,
OP_lo_user), this implements debug info support for TLS in ELF. Verified
that this output is correct/sufficient on Linux (using gold - if you're
using binutils-ld, you'll need something with the fix for
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 in it).
Support on non-ELF is sort of "arbitrary" at the moment - if Apple folks
want to discuss (or just go ahead & implement) how this should work in
MachO, etc, I'm open.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185203 91177308-0d34-0410-b5e6-96231b3b80d8
This is a precursor to adding debug info support for TLS which requires
non-default relocations applied to TLS symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185202 91177308-0d34-0410-b5e6-96231b3b80d8
Representing enumerators by int64 instead of uint64 for now. At some
point we need to address the underlying issue of representation
depending on the specific enumeration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184761 91177308-0d34-0410-b5e6-96231b3b80d8
A FastISel optimization was causing us to emit no information for such
parameters & when they go missing we end up emitting a different
function type. By avoiding that shortcut we not only get types correct
(very important) but also location information (handy) - even if it's
only live at the start of a function & may be clobbered later.
Reviewed/discussion by Evan Cheng & Dan Gohman.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184604 91177308-0d34-0410-b5e6-96231b3b80d8
Fix up three tests - one that was relying on abbreviation number,
another relying on a location list in this case (& testing raw asm,
changed that to use dwarfdump on the debug_info now that that's where
the location is), and another which was added in r184368 - exposing a
bug in that fix that is exposed when we emit the location inline rather
than through a location list. Fix that bug while I'm here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184387 91177308-0d34-0410-b5e6-96231b3b80d8
We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.
Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184368 91177308-0d34-0410-b5e6-96231b3b80d8
This is a precursor to fix a regression caused by PR14763/r183329 where
the location of a non-trivial pass-by-value parameter ends up
incorrectly referring directly to the parameter (a pointer) rather than
the object pointed to by the pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184365 91177308-0d34-0410-b5e6-96231b3b80d8
This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184361 91177308-0d34-0410-b5e6-96231b3b80d8
Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184067 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.
Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184066 91177308-0d34-0410-b5e6-96231b3b80d8
This currently unused function appeared to be asserting in the wrong
direction - DebugValues are never definitions of registers, only uses.
Curiously we don't perform any of these checks for the more common (&
actually used) case of MachineOperand::CreateReg (or other Create
functions).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184065 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the PRED_BAD has been removed, this is failing the Clang
-Werror build due to -Wcovered-switch-default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183863 91177308-0d34-0410-b5e6-96231b3b80d8
Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183446 91177308-0d34-0410-b5e6-96231b3b80d8
When a function is inlined we lazily construct the variables
representing the function's parameters. After that, we add any remaining
unused parameters.
If the function doesn't use all the parameters, or uses them out of
order, then the DWARF would produce them in that order, producing a
parameter order that doesn't match the source.
This fix causes us to always keep the arg variables at the start of the
variable list & in the original order from the source.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183297 91177308-0d34-0410-b5e6-96231b3b80d8
This updates the debug info metadata schema documentation for various
schema changes made recently surrounding filename information for
scopes and the representation of imported entities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182817 91177308-0d34-0410-b5e6-96231b3b80d8
There were bits & pieces of code lying around that may've given the
impression that debug info metadata supported the possibility that a
subprogram's type could be specified by a non-subroutine type describing
the return type of a void function. This support was incomplete &
unnecessary. Asserts & API have been changed to make the desired usage
more clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182532 91177308-0d34-0410-b5e6-96231b3b80d8
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite by implementing an optional name field for
DW_TAG_imported_modules/DIImportedEntities and using that to implement
C++ namespace aliases (eg: "namespace X = Y;").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182328 91177308-0d34-0410-b5e6-96231b3b80d8
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181868 91177308-0d34-0410-b5e6-96231b3b80d8
This just brings a crash a little further forward from DWARF emission to
DIE construction to make errors easier to diagnose.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181748 91177308-0d34-0410-b5e6-96231b3b80d8
This is only tested for global variables at the moment (& includes tests
for the unnamed parameter case, since apparently this entire function
was completely untested previously)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181632 91177308-0d34-0410-b5e6-96231b3b80d8
This provides basic functionality for imported declarations. For
subprograms and types some amount of lazy construction is supported (so
the definition of a function can proceed the using declaration), but it
still doesn't handle declared-but-not-defined functions (since we don't
generally emit function declarations).
Variable support is really rudimentary at the moment - simply looking up
the existing definition with no support for out of order (declaration,
imported_module, then definition).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181392 91177308-0d34-0410-b5e6-96231b3b80d8
DIBuilder::createImportedDeclaration isn't fully plumbed through (note,
lacking in AsmPrinter/DwarfDebug support) but this seemed like a
sufficiently useful division of code to make the subsequent patch(es)
easier to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181364 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently we didn't keep an association of Compile Unit metadata nodes
to DIEs so looking up that parental context failed & thus caused no
DW_TAG_imported_modules to be emitted at the CU scope. Fix this by
adding the mapping & sure up the test case to verify this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181339 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r179840 with a fix to test/DebugInfo/two-cus-from-same-file.ll
I'm not sure why that test only failed on ARM & MIPS and not X86 Linux, even
though the debug info was clearly invalid on all of them, but this ought to fix
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179996 91177308-0d34-0410-b5e6-96231b3b80d8
Adding another CU-wide list, in this case of imported_modules (since they
should be relatively rare, it seemed better to add a list where each element
had a "context" value, rather than add a (usually empty) list to every scope).
This takes care of DW_TAG_imported_module, but to fully address PR14606 we'll
need to expand this to cover DW_TAG_imported_declaration too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179836 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 342d92c7a0.
Turns out we're going with a different schema design to represent
DW_TAG_imported_modules so we won't need this extra field.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178215 91177308-0d34-0410-b5e6-96231b3b80d8
This is just the basic groundwork for supporting DW_TAG_imported_module but I
wanted to commit this before pushing support further into Clang or LLVM so that
this rather churny change is isolated from the rest of the work. The major
churn here is obviously adding another field (within the common DIScope prefix)
to all DIScopes (files, classes, namespaces, lexical scopes, etc). This should
be the last big churny change needed for DW_TAG_imported_module/using directive
support/PR14606.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178099 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used to factor out some uses of magic number operand offsets
inside Clang where these fields were updated in an effort to resolve forward
declarations/circular references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178078 91177308-0d34-0410-b5e6-96231b3b80d8
The differing file (due to the #line directive in the original source) is for
future testing improvements coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177560 91177308-0d34-0410-b5e6-96231b3b80d8
Moving the DIFile parameter to immediately proceed the tag so that it will be a
common prefix with other DIScopes (once the DIFile is replaced with the raw
file/directory pair).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177492 91177308-0d34-0410-b5e6-96231b3b80d8
This is the backend portion of a Clang test case
(clang/test/CodeGenCXX/debug-info-namespace.cpp) that was roughly/coarsely
testing LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177487 91177308-0d34-0410-b5e6-96231b3b80d8
This makes DIType's first non-tag parameter the same as DIFile's, allowing them
to both share the common implementation of getFilename/getDirectory in DIScope.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177467 91177308-0d34-0410-b5e6-96231b3b80d8
This is another step along the way to making all DIScopes have a common prefix
which can be added to in a general manner to support using directives
(DW_TAG_imported_module).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177462 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently my final cleanup to use a relevant suffix for these tests before
committing r176831 caused them to stop running since lit wasn't configured to
run tests with that suffix in those directories (why don't we just have a
global suffix list?). So, add the suffix to the relevant directories & fix the
test that has bitrotted over the last week due to my debug info schema changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177315 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first step to making all DIScopes have a common metadata prefix (so
that things (using directives, for example) that can appear in any scope can be
added to that common prefix). DIFile is itself a DIScope so the common prefix
of all DIScopes cannot be a DIFile - instead it's the raw filename/directory
name pair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177239 91177308-0d34-0410-b5e6-96231b3b80d8
David Blaikie