Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.
<rdar://problem/13363576>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183544 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
Since the testing case uses ref_addr, which requires version 3+ to work,
we will solve the dwarf version issue first.
This patch also causes failures in one of the bots. I will update the patch
accordingly in my next attempt.
rdar://13926659
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182867 91177308-0d34-0410-b5e6-96231b3b80d8
from a different CU.
We used to print out an error message and fail to generate inlined_subroutine.
If we use ref_addr in the generated DWARF, the DWARF version should be 3 or
above.
rdar://13926659
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182791 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 is to fix PR15408 where an undefined symbol Lline_table_start1 is used.
Since we do not generate the debug_line section when .loc is used,
Lline_table_start1 is not emitted and we can't refer to it when calculating
at_stmt_list for a compile unit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182344 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
happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181835 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
It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarfRegNum are pushed out, which
should allow further simplifications.
I left the MachineModuleInfo::addFrameMove interface unchanged since
this patch was already fairly big.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181680 91177308-0d34-0410-b5e6-96231b3b80d8
To add a frame now there is a dedicated addFrameMove which also takes
care of constructing the move itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181657 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
for constructors and destructors since the original declaration given
by the AT_specification both won't and can't.
Patch by Yacine Belkadi, I've cleaned up the testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181471 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
register-indirect address with an offset of 0.
It used to be that a DBG_VALUE is a register-indirect value if the offset
(operand 1) is nonzero. The new convention is that a DBG_VALUE is
register-indirect if the first operand is a register and the second
operand is an immediate. For plain registers use the combination reg, reg.
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180816 91177308-0d34-0410-b5e6-96231b3b80d8
The `llvm.tls_init_funcs' (created by the front-end) holds pointers to the TLS
initialization functions. These need to be placed into the correct section so
that they are run before `main()'.
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180737 91177308-0d34-0410-b5e6-96231b3b80d8
to determine whether or not we're on a darwin platform for debug code
emitting.
Solves the problem of a module with no triple on the command line
and no triple in the module using non-gdb ok features on darwin. Fix
up the member-pointers test to check the correct things for cross
platform (DW_FORM_flag is a good prefix).
Unfortunately no testcase because I have no ideas how to test something
without a triple and without a triple in the module yet check
precisely on two platforms. Ideas welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180660 91177308-0d34-0410-b5e6-96231b3b80d8
Clarify documentation and API to make the difference between register and
register-indirect addressed locations more explicit. Put in a comment
to point out that with the current implementation we cannot specify
a register-indirect location with offset 0 (a breg 0 in DWARF).
No functionality change intended.
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180641 91177308-0d34-0410-b5e6-96231b3b80d8
Also add a check for llvm.used in the verifier and simplify clients now that
they can assume they have a ConstantArray.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180019 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
therefore not at all) of the pc or statement list. We also don't
need to emit the compilation dir so save so space and time
and don't bother.
Fix up the testcase accordingly and verify that we don't emit
the attributes or the items that they use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179114 91177308-0d34-0410-b5e6-96231b3b80d8
a relocation across sections. Do this for DW_AT_stmt list in the
skeleton CU and check the relocations in the debug_info section.
Add a FIXME for multiple CUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178969 91177308-0d34-0410-b5e6-96231b3b80d8
We used to do "SmallString += CUID", which is incorrect, since CUID will
be truncated to a char.
rdar://problem/13573833
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178941 91177308-0d34-0410-b5e6-96231b3b80d8
There is a difference for FORM_ref_addr between DWARF 2 and DWARF 3+.
Since Eric is against guarding DWARF 2 ref_addr with DarwinGDBCompat, we are
still in discussion on how to handle this.
The correct solution is to update our header to say version 4 instead of version
2 and update tool chains as well.
rdar://problem/13559431
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178806 91177308-0d34-0410-b5e6-96231b3b80d8
the target system.
It was hard-coded to 4 bytes before. I can't get llvm to generate a
ref_addr on a reasonably sized testing case.
rdar://problem/13559431
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178722 91177308-0d34-0410-b5e6-96231b3b80d8
die values. A lot of DIEs have 10 attributes in C++ code (example
clang), none had more than 12. Seems like a good default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178366 91177308-0d34-0410-b5e6-96231b3b80d8
The always-true "(int)Int == (signed)Int" comparison was found
while experimenting with a potential new Clang warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177290 91177308-0d34-0410-b5e6-96231b3b80d8
belongs to a different compile unit.
DW_FORM_ref_addr should be used for cross compile-unit reference.
When compiling a large application, we got a dwarfdump verification error where
abstract_origin points to nowhere.
This error can't be reproduced on any testing case in MultiSource.
We may have other cases where we use DW_FORM_ref4 unconditionally.
rdar://problem/13370501
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176882 91177308-0d34-0410-b5e6-96231b3b80d8
Versioned debug info support has been a burden to maintain & also compromised
current debug info verification by causing test cases testing old debug info to
remain rather than being updated to the latest. It also makes it hard to add or
change the metadata schema by requiring various backwards-compatibility in the
DI* hierarchy.
So it's being removed in preparation for new changes to the schema to tidy up
old/unnecessary fields and add new fields needed for new debug info (well, new
to LLVM at least).
The more surprising part of this is the changes to DI*::Verify - this became
necessary due to the changes to AsmWriter. AsmWriter was relying on the version
test to decide which bits of metadata were actually debug info when printing
the comment annotations. Without the version information the tag numbers were
too common & it would print debug info on random metadata that happened to
start with an integer that matched a tag number. Instead this change makes the
Verify functions more precise (just adding "number of operands" checks - not
type checking those operands yet) & relies on that to decide which metadata is
debug info metadata.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176838 91177308-0d34-0410-b5e6-96231b3b80d8
We now emit a line table for each compile unit. To reduce the prologue size
of each line table, the files and directories used by each compile unit are
stored in std::map<unsigned, std::vector< > > instead of std::vector< >.
The prologue for a lto'ed image can be as big as 93K. Duplicating 93K for each
compile unit causes a huge increase of debug info. With this patch, each
prologue will only emit the files required by the compile unit.
rdar://problem/13342023
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176605 91177308-0d34-0410-b5e6-96231b3b80d8
definition DIE (TAG_variable), and put AT_MIPS_linkage_name to TAG_member when
DarwinGDBCompat is true.
Darwin GDB needs AT_MIPS_linkage_name at both places to work.
Follow-up patch to r176143.
rdar://problem/13291234
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176220 91177308-0d34-0410-b5e6-96231b3b80d8
definition DIE, to make old GDB happy.
We have a regression for old GDB when Clang uses DW_TAG_member to declare
static members inside a class, instead of DW_TAG_variable. This patch will fix
this regression.
rdar://problem/13291234
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176143 91177308-0d34-0410-b5e6-96231b3b80d8
TAG_member inside a class to the specification DIE.
Having AT_MIPS_linkage_name on TAG_member caused old gdb (GNU 6.3.50) to
error out. Also gcc 4.7 has AT_MIPS_linkage_name on the specification DIE.
rdar://problem/13291234
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176120 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts my commit 171047. Now that I've removed my misguided attempt to
support backend warnings, these diagnostics are only about inline assembly.
It would take quite a bit more work to generalize them properly, so I'm
just reverting this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174860 91177308-0d34-0410-b5e6-96231b3b80d8
syms before constructing the compile units so we're not emitting
section references to sections not there already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174663 91177308-0d34-0410-b5e6-96231b3b80d8
Failure: undefined symbol 'Lline_table_start0'.
Root-cause: we use a symbol subtraction to calculate at_stmt_list, but
the line table entries are not dumped in the assembly.
Fix: use zero instead of a symbol subtraction for Compile Unit 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174479 91177308-0d34-0410-b5e6-96231b3b80d8
We generate one line table for each compilation unit in the object file.
Reviewed by Eric and Kevin.
rdar://problem/13067005
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174445 91177308-0d34-0410-b5e6-96231b3b80d8
We used to create children DIEs for a scope, then check whether ScopeDIE is
null. If ScopeDIE is null, the children DIEs will be dangling. Other DIEs can
link to those dangling DIEs, which are not emitted at all, causing dwarf error.
The current testing case is 4k lines, from MultiSource/BenchMark/McCat/09-vor.
rdar://problem/13071959
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174084 91177308-0d34-0410-b5e6-96231b3b80d8
changing both the string of the dwo_name to be correct and the type of
the statement list.
Testcases all around.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172699 91177308-0d34-0410-b5e6-96231b3b80d8
