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

llvm-svn: 182867

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

llvm-svn: 182791

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.

llvm-svn: 182532

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.

llvm-svn: 182344

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;").

llvm-svn: 182328

happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.

llvm-svn: 181835

This just brings a crash a little further forward from DWARF emission to
DIE construction to make errors easier to diagnose.

llvm-svn: 181748

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.

llvm-svn: 181680

llvm-svn: 181663

To add a frame now there is a dedicated addFrameMove which also takes
care of constructing the move itself.

llvm-svn: 181657

llvm-svn: 181656

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)

llvm-svn: 181632

temporarily while investigating gdb.cp/templates.exp.

This reverts commit r181471.

llvm-svn: 181496

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.

llvm-svn: 181471

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).

llvm-svn: 181392

llvm-svn: 181391

instead of relying upon an extra call to finish initializing.

llvm-svn: 181383

llvm-svn: 181378

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.

llvm-svn: 181364

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.

llvm-svn: 181339

llvm-svn: 181296

llvm-svn: 181271

llvm-svn: 181227

llvm-svn: 181226

llvm-svn: 180889

because it breaks some buildbots.

This reverts commit 180816.

llvm-svn: 180819

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

llvm-svn: 180816

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>

llvm-svn: 180737

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.

llvm-svn: 180660

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

llvm-svn: 180641

llvm-svn: 180186

The value isn't actually used, and setting it emits a COFF specific
directive.

llvm-svn: 180064

Also add a check for llvm.used in the verifier and simplify clients now that
they can assume they have a ConstantArray.

llvm-svn: 180019

llvm-svn: 180000

llvm-svn: 179999

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.

llvm-svn: 179996

This reverts commit r179836 as it seems to have caused test failures.

llvm-svn: 179840

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.

llvm-svn: 179836

Differential Revision: http://llvm-reviews.chandlerc.com/D598

llvm-svn: 179725

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.

llvm-svn: 179114