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

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

llvm-svn: 176882

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.

llvm-svn: 176838

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

llvm-svn: 176605

a few lines above.

llvm-svn: 176224

llvm-svn: 176223

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

llvm-svn: 176220

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

llvm-svn: 176143

llvm-svn: 176129

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

llvm-svn: 176120

update testcase accordingly to give the correct name to the cu.

llvm-svn: 175934

llvm-svn: 175264

option "generate-dwarf-pubnames" to control it, set to "false" by default.

llvm-svn: 174981

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.

llvm-svn: 174860

llvm-svn: 174817

line table entries in assembly.

llvm-svn: 174785

syms before constructing the compile units so we're not emitting
section references to sections not there already.

llvm-svn: 174663

units coming in.

llvm-svn: 174548

llvm-svn: 174547

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.

llvm-svn: 174479

We generate one line table for each compilation unit in the object file.
Reviewed by Eric and Kevin.

rdar://problem/13067005

llvm-svn: 174445

for the first compile unit.

llvm-svn: 174352

DWARF5 split dwarf proposal.

llvm-svn: 174350

Testing case is reduced from MultiSource/BenchMarks/Prolangs-C++/deriv1.

rdar://problem/13071590

llvm-svn: 174235

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

llvm-svn: 174084

Provides the functionality for Clang change r172911 - I just had this still
lying around.

llvm-svn: 173820

llvm-svn: 173698

llvm-svn: 172941