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

to return and this is done all over.

llvm-svn: 183704

llvm-svn: 183703

llvm-svn: 183698

llvm-svn: 183695

Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.

<rdar://problem/13363576>

llvm-svn: 183544

llvm-svn: 183454

Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).

No intended functionality change.

llvm-svn: 183446

When a function is inlined we lazily construct the variables
representing the function's parameters. After that, we add any remaining
unused parameters.

If the function doesn't use all the parameters, or uses them out of
order, then the DWARF would produce them in that order, producing a
parameter order that doesn't match the source.

This fix causes us to always keep the arg variables at the start of the
variable list & in the original order from the source.

llvm-svn: 183297

Also simplify code a bit while there. No functionality change.

llvm-svn: 183076

llvm-svn: 183057

llvm-svn: 182903

llvm-svn: 182902

Not only does this break encapsulation, it's gross.

llvm-svn: 182876

Since the testing case uses ref_addr, which requires version 3+ to work,
we will solve the dwarf version issue first.

This patch also causes failures in one of the bots. I will update the patch
accordingly in my next attempt.

rdar://13926659

llvm-svn: 182867

from a different CU.

We used to print out an error message and fail to generate inlined_subroutine.

If we use ref_addr in the generated DWARF, the DWARF version should be 3 or
above.
rdar://13926659

llvm-svn: 182791

There were bits & pieces of code lying around that may've given the
impression that debug info metadata supported the possibility that a
subprogram's type could be specified by a non-subroutine type describing
the return type of a void function. This support was incomplete &
unnecessary. Asserts & API have been changed to make the desired usage
more clear.

llvm-svn: 182532

This is to fix PR15408 where an undefined symbol Lline_table_start1 is used.
Since we do not generate the debug_line section when .loc is used,
Lline_table_start1 is not emitted and we can't refer to it when calculating
at_stmt_list for a compile unit.

llvm-svn: 182344

This resolves the last of the PR14606 failures in the GDB 7.5 test
suite by implementing an optional name field for
DW_TAG_imported_modules/DIImportedEntities and using that to implement
C++ namespace aliases (eg: "namespace X = Y;").

llvm-svn: 182328

happens to be a compile unit. Noticed on inspection and tested
via calling on a newly created compile unit. No functional change.

llvm-svn: 181835

This just brings a crash a little further forward from DWARF emission to
DIE construction to make errors easier to diagnose.

llvm-svn: 181748

It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarfRegNum are pushed out, which
should allow further simplifications.

I left the MachineModuleInfo::addFrameMove interface unchanged since
this patch was already fairly big.

llvm-svn: 181680

llvm-svn: 181663

To add a frame now there is a dedicated addFrameMove which also takes
care of constructing the move itself.

llvm-svn: 181657