(From LLDB r192897)

llvm-svn: 192968

llvm-svn: 192954

llvm-svn: 192952

[DebugInfo] Delete dead code, simplify and fix code style for some existing code. No functionality change.

llvm-svn: 192894

llvm-svn: 191813

Parsing .debug_aranges section now takes O(nlogn) operations instead
of O(n^2), where "n" is the number of address ranges. With this change,
the time required to symbolize an address from a random large
Clang-generated binary drops from 165 seconds to 1.5 seconds.

No functionality change.

llvm-svn: 191781

llvm-svn: 191779

llvm-svn: 191778

llvm-svn: 191637

llvm-svn: 191571

llvm-svn: 191408

llvm-svn: 191407

llvm-svn: 191401

llvm-svn: 191333

CR feedback from Eric Christopher

llvm-svn: 191330

llvm-svn: 191329

llvm-svn: 191266

llvm-svn: 191255

llvm-svn: 191244

llvm-svn: 191238

llvm-svn: 191234

llvm-svn: 191233

This is a small step that may enable some simplifications in producer
(DWARFContext) and consumer (DWARFCompileUnit and other places) by
making a more complete abstraction around the data and relocations for a
section. Small initial steps could include simple changes such as
passing the pair to DWARFCompileUnit's ctor rather than passing the data
and relocs separately. I don't intend to pursue any such changes
immediately, however.

The motivation for doing this now is that type unit dumping will need to
deal with these data+reloc pairs moreso than the existing dumping
support has needed to associate the data as type unit sections are named
the same (debug_types) and comdat group folded. So to implement dumping
and reloc handling we'll need a mapping of section->data+relocs.

llvm-svn: 191209

llvm-svn: 191179

llvm-svn: 191178

llvm-svn: 191065

llvm-svn: 191062

Ensures that the pubnames entries actually refer to the intended
entities. This test could be more flexible if there was a way to do
multiline FileCheck matches with captures (in that way the test wouldn't
need to have hardcoded offset values and would thus be resilient to
changes in the layout of the DIEs in this CU).

llvm-svn: 191055

llvm-svn: 191050

Summary:
1) Make llvm-symbolizer properly symbolize
files with split debug info (by using stanalone .dwo files).
2) Make DWARFCompileUnit parse and store corresponding .dwo file,
if necessary.
3) Make bits of DWARF parsing more CompileUnit-oriented.

Reviewers: echristo

Reviewed By: echristo

CC: bkramer, llvm-commits

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

llvm-svn: 189329

Summary:
This is a part of D1164. DWARFCompileUnit is not that lightweight
to copy it around, and we want it to own corresponding .dwo compile unit
eventually.

Reviewers: echristo

Reviewed By: echristo

CC: llvm-commits

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

llvm-svn: 189089

This reduces the noise in diffs making it more likely that, at least for
LLVM revision-over-revision, diffs will actually yield usable results.

This is consistent with objdump's DWARF dumping behavior.

llvm-svn: 188650

Store compile unit corresponding to each chain of inlined debug info entries. No functionality change.

llvm-svn: 187792

llvm-svn: 187790

llvm-svn: 187763

DebugInfo: Factor out parsing compile unit DIEs to a separate function. Improve code style and comments.

No functionality change.

llvm-svn: 186315

llvm-svn: 184362

This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.

llvm-svn: 184361

In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.

llvm-svn: 183284

For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.

In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.

In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.

This patch exposes that in the ObjectFile API. It has the following advantages:

* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.

* llvm-readobj now prints relocations in the same way the native readelf does.

* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.

llvm-svn: 182908