llvm-svn: 185586

(and for consistency).

llvm-svn: 185585

llvm-svn: 185573

llvm-svn: 185523

llvm-svn: 185520

Introduce some typedefs for DenseMaps containing SmallVectors so the vector size doesn't have to repeated when creating iterators for the DenseMap.

llvm-svn: 185508

Use SmallVectorImpl& instead of SmallVector& to avoid needlessly respecifying the small vector size.

llvm-svn: 185505

Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.

llvm-svn: 185504

avoid adding information for the debug_inlined section when it isn't
going to be emitted anyhow.

llvm-svn: 185500

llvm-svn: 185498

llvm-svn: 185497

grep.

llvm-svn: 185496

llvm-svn: 185495

llvm-svn: 185492

true, so remove the return value and propagate accordingly.

llvm-svn: 185490

Correctly handles ref_addr depending on the Dwarf version. Emit Dwarf with
version from module flag.

TODO: turn on/off features depending on the Dwarf version.
llvm-svn: 185484

llvm-svn: 185480

[DebugInfo] Allow getDebugThreadLocalSymbol to return MCExpr

This allows getDebugThreadLocalSymbol to return a generic MCExpr
instead of just a MCSymbolRefExpr.

This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.

llvm-svn: 185460

[DebugInfo] Hold generic MCExpr in AddrPool

This changes the AddrPool infrastructure to enable it to hold
generic MCExpr expressions, not just MCSymbolRefExpr.

This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.

llvm-svn: 185459

[DebugInfo] Introduce DIEExpr variant of DIEValue to hold MCExpr values

This partially reverts r185202 and restores DIELabel to hold plain
MCSymbol references.  Instead, we add a new subclass DIEExpr of
DIEValue that can hold generic MCExpr references.

This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.

llvm-svn: 185458

This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).

llvm-svn: 185436

llvm-svn: 185398

Based on GCC's output for TLS variables (OP_constNu, x@dtpoff,
OP_lo_user), this implements debug info support for TLS in ELF. Verified
that this output is correct/sufficient on Linux (using gold - if you're
using binutils-ld, you'll need something with the fix for
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 in it).

Support on non-ELF is sort of "arbitrary" at the moment - if Apple folks
want to discuss (or just go ahead & implement) how this should work in
MachO, etc, I'm open.

llvm-svn: 185203

This is a precursor to adding debug info support for TLS which requires
non-default relocations applied to TLS symbols.

llvm-svn: 185202

llvm-svn: 185190

llvm-svn: 185189

llvm-svn: 185188

llvm-svn: 184866

llvm-svn: 184792

llvm-svn: 184788

never modified. No functional change.

llvm-svn: 184781

llvm-svn: 184669

llvm-svn: 184643

Fix up three tests - one that was relying on abbreviation number,
another relying on a location list in this case (& testing raw asm,
changed that to use dwarfdump on the debug_info now that that's where
the location is), and another which was added in r184368 - exposing a
bug in that fix that is exposed when we emit the location inline rather
than through a location list. Fix that bug while I'm here.

llvm-svn: 184387

We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.

Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).

llvm-svn: 184368

Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.

llvm-svn: 184067

Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.

Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.

llvm-svn: 184066

llvm-svn: 184045

Debug Info: Don't print the display name and colon prefix for DEBUG_VALUE comments if the display name is empty

llvm-svn: 184026

llvm-svn: 183807