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

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.

llvm-svn: 178969

We used to do "SmallString += CUID", which is incorrect, since CUID will
be truncated to a char.

rdar://problem/13573833

llvm-svn: 178941

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

llvm-svn: 178806

llvm-svn: 178804

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

llvm-svn: 178722

llvm-svn: 178624

llvm-svn: 178623

llvm-svn: 178386

die values. A lot of DIEs have 10 attributes in C++ code (example
clang), none had more than 12. Seems like a good default.

llvm-svn: 178366

entire original compile unit has been constructed.

llvm-svn: 178365

llvm-svn: 177869

llvm-svn: 177867

The always-true "(int)Int == (signed)Int" comparison was found
while experimenting with a potential new Clang warning.

llvm-svn: 177290

llvm-svn: 176963

llvm-svn: 176962