in use supports it.

llvm-svn: 189439

MDNode more clear as just for a single argument.

llvm-svn: 189294

is constructing from as an input and keep the same unique identifier.
We can use this to connect items which must stay in the .o file
(e.g. pubnames and pubtypes) to the skeleton cu rather than having
duplicate unique numbers for the sections and needing to do lookups
based on MDNode.

llvm-svn: 189293

llvm-svn: 189292

can get it via the MDNode that's passed in. Save that instead.

llvm-svn: 189291

it by default under linux or when we're trying to keep compatibility
with old gdb versions.

Fix testcase for option name change.

llvm-svn: 189289

llvm-svn: 189288

llvm-svn: 189279

Replace instances of this scattered around the code base.

llvm-svn: 189169

llvm-svn: 189168

Leak found by valgrind.

llvm-svn: 189167

Summary:
LLVM would generate DWARF with version 3 in the .debug_pubname and
.debug_pubtypes version fields.  This would lead SGI dwarfdump to fail
parsing the DWARF with (in the instance of .debug_pubnames) would exit
with:
dwarfdump ERROR:  dwarf_get_globals: DW_DLE_PUBNAMES_VERSION_ERROR (123)

This fixes PR16950.

Reviewers: echristo, dblaikie

Reviewed By: echristo

CC: cfe-commits

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

llvm-svn: 188869

llvm-svn: 188711

Until gdb supports the new accelerator tables we should add the
pubnames section so that gdb_index can be generated from gold
at link time. On darwin we already emit the accelerator tables
and so don't need to worry about pubnames.

llvm-svn: 188708

Output DW_AT_stmt_list dwarf debug info as DW_FORM_sec_offset instead of DW_FORM_data4 as it is a section offset (fixes the coff/dwarf debug info statement locations)

llvm-svn: 188297

CUs.

Currently only hashes the name of CUs and the names of any children,
but it's an obvious first step to show the framework. The testcase
should continue to be correct, however, as it's an empty TU.

llvm-svn: 188243

has been finalized except for sizes and offsets. Update test accordingly.

llvm-svn: 188199

No functional change intended.

llvm-svn: 188028

llvm-svn: 187954

llvm-svn: 187953

llvm-svn: 187872

Use it when we're looking for a string in particular. Update comments
as well.

llvm-svn: 187844

No functional change.

llvm-svn: 187843

llvm-svn: 187752

This reverts commit r187745.

llvm-svn: 187747

simple.

llvm-svn: 187745

greatly on many comments in the code.

llvm-svn: 187742

update testcase to make sure we generate debug info for walrus
by adding a non-trivial constructor and verify that we don't
emit an ODR signature for the type.

llvm-svn: 187393

sure the comments for each testcase are a bit easier to distinguish.

llvm-svn: 187392

llvm-svn: 187385

This makes LLVM emit the same signature regardless of host and target endianess.

llvm-svn: 187304

There doesn't appear to be any reason to put this variable on the heap.
I'm suspicious of the LexicalScope above that we stuff in a map and then
delete afterward, but I'm just trying to get the valgrind bot clean.

llvm-svn: 187301

llvm-svn: 187245

type units.

Initially this support is used in the computation of an ODR checker
for C++. For now we're attaching it to the DIE, but in the future
it will be attached to the type unit.

This also starts breaking out types into the separation for type
units, but without actually splitting the DIEs.

In preparation for hashing the DIEs this adds a DIEString type
that contains a StringRef with the string contained at the label.

llvm-svn: 187213

llvm-svn: 186994

No functionality change.

llvm-svn: 186470

llvm-svn: 186371

Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old convention was 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 register values the combination reg,
reg is used. MachineInstrBuilder::BuildMI knows how to build the new
DBG_VALUES.

rdar://problem/13658587

llvm-svn: 185966

No functionality change. It should suffice to check the type of a debug info
metadata, instead of calling Verify.

llvm-svn: 185847

llvm-svn: 185844