llvm-svn: 204795

Fix PR19239 - Add support for generating debug info for functions without lexical scopes and/or debug info at all

llvm-svn: 204790

Based on code review feedback from Eric in r204672.

llvm-svn: 204702

Implement debug_loc.dwo, as well as llvm-dwarfdump support for dumping
this section.

Outlined in the DWARF5 spec and http://gcc.gnu.org/wiki/DebugFission the
debug_loc.dwo section has more variation than the standard debug_loc,
allowing 3 different forms of entry (plus the end of list entry). GCC
seems to, and Clang certainly, only use one form, so I've just
implemented dumping support for that for now.

It wasn't immediately obvious that there was a good refactoring to share
the implementation of dumping support between debug_loc and
debug_loc.dwo, so they're separate for now - ideas welcome or I may come
back to it at some point.

As per a comment in the code, we could choose different forms that may
reduce the number of debug_addr entries we emit, but that will require
further study.

llvm-svn: 204697

This seems excessive - switching section isn't expensive (or if it is
we're already being wasteful, since we emitted the debug_loc section
symbol earlier anyway) and otherwise there's no work that happens in
this function when the list is empty.

llvm-svn: 204696

Rather than using a flat list with "empty" entries (ala the actual
on-disk format), keep separate lists for each variable.

llvm-svn: 204680

No functional change intended.

Merging up-front rather than delaying this task until later. This just
seems simpler and more efficient (avoiding growing the debug loc list
only to have to skip over those post-merged entries, etc).

llvm-svn: 204679

llvm-svn: 204673

This is used to avoid relocations in the dwo file by allowing
DW_AT_ranges specified in debug_info.dwo to be relative to this base
address. (r204667 implements the base-relative DW_AT_ranges side of
this)

llvm-svn: 204672

This removes the debug_ranges relocations from debug_info.dwo (but
doesn't implement the DW_AT_GNU_ranges_base which is also necessary for
correct functioning)

llvm-svn: 204668

llvm-svn: 204667

llvm-svn: 204665

llvm-svn: 204663

llvm-svn: 204530

an ID, so this is a noop.
Thanks Manman for catching this!

llvm-svn: 204528

Type units have no addresses, so there's no need for DW_AT_addr_base.
This removes another relocation from every skeletal type unit and brings
LLVM's skeletal type units in line with GCC's (containing only
GNU_dwo_name (strp), comp_dir (strp), and GNU_pubnames (flag_present)).

Cary's got some ideas about using str_index in the .o file to reduce
those last two relocations (well, replace two relocations with one
relocation (pointing to the string index) and two indicies)

llvm-svn: 204506

llvm-svn: 204378

    Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc.

    This commit moves us from a single range per subprogram to extending
    ranges if we are:

    a) In the same section, and
    b) In the same enclosing CU.

    This means we have more fine grained ranges for compile units, and fewer
    ranges overall when we have multiple functions in the same CU
    adjacent to each other in the object file.

    Also remove all of the earlier hacks around this functionality for
    function sections etc. Also update all of the testcases to take into
    account the merging functionality.

with a fix for location entries in the debug_loc section:

Make sure that debug loc entries are relative to the low_pc
of the compile unit. This means that when we only have a single
range that the offset should be just relative to the low_pc
of the unit, for multiple ranges for a CU this means that we'll be
relative to 0 which we emit along with DW_AT_ranges.

This mostly shows up with linked binaries, so add a testcase with
multiple CUs so that our location is going to be offset of a CU
with a non-zero low_pc.

llvm-svn: 204377

llvm-svn: 204358

This appears to trigger failures with optimization and function arguments somehow.

This reverts commit r204277.

llvm-svn: 204286

This commit moves us from a single range per subprogram to extending
ranges if we are:

a) In the same section, and
b) In the same enclosing CU.

This means we have more fine grained ranges for compile units, and fewer
ranges overall when we have multiple functions in the same CU
adjacent to each other in the object file.

Also remove all of the earlier hacks around this functionality for
function sections etc. Also update all of the testcases to take into
account the merging functionality.

llvm-svn: 204277

This isn't a complete fix - it falls back to non-comp_dir when multiple
compile units are in play. Adding a map of comp_dir to table is part of
the more general solution, but I gave up (in the short term) when I
realized I'd also have to calculate the size of each type unit so as to
produce correct DW_AT_stmt_list attributes.

llvm-svn: 204202

When deployment target version information is available, emit it to the
target streamer for inclusion in the object file.

rdar://11337778

llvm-svn: 204191

llvm-svn: 204183

We really do use these things in the header.

llvm-svn: 204180

llvm-svn: 204177

llvm-svn: 204176

Follow-up to r203982.

llvm-svn: 204162

This is a follow-up to r203983 based on feedback from dblaikie and mren (Thanks!)
No functionality change.

llvm-svn: 204107

This allows us to catch more opportunities for ODR-based type uniquing
during LTO.
Paired commit with CFE which updates some testcases to verify the new
DIBuilder behavior.

llvm-svn: 204106

llvm-svn: 204104

llvm-svn: 204103

No functional change.

llvm-svn: 204102

DebugInfo: Avoid emitting standard opcode lengths in debug_line.dwo headers where opcodes are never used anyway

Introduce a slightly tighter wrapper around the header structure that
handles this use case. (MCDwarfDwoLineTable)

llvm-svn: 204101

This removes an attribute (and more importantly, a relocation) from
skeleton type units and removes some unnecessary file names from the
debug_line section that remains in the .o (and linked executable) file.

There's still a few places we could shave off some more space here:

* use compilation dir of the underlying compilation unit (since all the
  type units share that compilation dir - though this would be more
  complicated in LTO cases where they don't (keep a map of compilation
  dir->line table header?))

* Remove some of the unnecessary header fields from the line table since
  they're not needed in this situation (about 12 bytes per table).

llvm-svn: 204099

DebugInfo: Do not rely on the compilation dir (index 0) for files in line tables shared between compilation units

When emitting assembly there's no support for emitting separate line
tables for each compilation unit - so LLVM emits .loc directives
producing a single line table.

Line tables have an implicit directory (index 0) equal to the
compilation directory (DW_AT_comp_dir) of the compilation unit that
references them.

If multiple compilation units (with possibly disparate compilation
directories) reference the same line table, we must avoid relying on
this ambiguous directory.

Achieve this my simply not setting the compilation directory on the line
table when we're in this situation (multiple units while emitting
assembly).

llvm-svn: 204094

We still do a few lookups into the line table mapping in MCContext that
could be factored out into a single lookup (rather than looking it up
once for the table label, once to set the compilation unit, once for
each time we need a file ID, etc... ) but assembly output complicates
that somewhat as we still need a virtual dispatch back to the
MCAsmStreamer in that case.

llvm-svn: 204092

Our handling of compilation directory in DwarfDebug was broken
(incorrectly using the 'last' compilation directory (that of the last
CU in the metadata list) for all function emission in any CU). By moving
this handling down into MCDwarf the issue is fixed as the compilation
dir is tracked correctly per line table.

llvm-svn: 204089

See r204027 for the precursor to this that applied to asm debug info.

This required some non-obvious API changes to handle the case of asm
output (we never go asm->asm so this didn't come up in r204027): the
modification of the file/directory name by MCDwarfLineTableHeader needed
to be reflected in the MCAsmStreamer caller so it could print the
appropriate .file directive, so those StringRef parameters are now
non-const ref (in/out) parameters rather than just const.

llvm-svn: 204069

llvm-svn: 203983