- Jul 17, 2013
-
-
Manman Ren authored
No functionality change. llvm-svn: 186470
-
- Jul 16, 2013
-
-
Craig Topper authored
llvm-svn: 186371
-
- Jul 09, 2013
-
-
Adrian Prantl authored
Change the informal convention of DBG_VALUE machine instructions so that we can express a register-indirect address with an offset of 0. The old convention was that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain register values the combination reg, reg is used. MachineInstrBuilder::BuildMI knows how to build the new DBG_VALUES. rdar://problem/13658587 llvm-svn: 185966
-
- Jul 08, 2013
-
-
Manman Ren authored
No functionality change. It should suffice to check the type of a debug info metadata, instead of calling Verify. llvm-svn: 185847
-
David Blaikie authored
llvm-svn: 185844
-
David Blaikie authored
Since the pool indexes are necessarily sequential and contiguous, just insert things in the right place rather than having to sort the sequence after the fact. No functionality change. llvm-svn: 185842
-
- Jul 04, 2013
-
-
Eric Christopher authored
llvm-svn: 185589
-
Eric Christopher authored
for them and update all uses. llvm-svn: 185588
-
- Jul 03, 2013
-
-
Eric Christopher authored
llvm-svn: 185586
-
Craig Topper authored
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
-
Craig Topper authored
Use SmallVectorImpl& instead of SmallVector& to avoid needlessly respecifying the small vector size. llvm-svn: 185505
-
Craig Topper authored
Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size. llvm-svn: 185504
-
Eric Christopher authored
avoid adding information for the debug_inlined section when it isn't going to be emitted anyhow. llvm-svn: 185500
-
Eric Christopher authored
llvm-svn: 185498
-
Eric Christopher authored
llvm-svn: 185492
-
Manman Ren authored
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
-
- Jul 02, 2013
-
-
Eric Christopher authored
llvm-svn: 185480
-
Ulrich Weigand authored
[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
-
Ulrich Weigand authored
[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
-
Rafael Espindola authored
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
-
David Blaikie authored
llvm-svn: 185398
-
- Jun 28, 2013
-
-
David Blaikie authored
This is a precursor to adding debug info support for TLS which requires non-default relocations applied to TLS symbols. llvm-svn: 185202
-
David Blaikie authored
llvm-svn: 185190
-
David Blaikie authored
llvm-svn: 185189
-
David Blaikie authored
llvm-svn: 185188
-
- Jun 25, 2013
-
-
Manman Ren authored
llvm-svn: 184866
-
Eric Christopher authored
llvm-svn: 184792
-
- Jun 20, 2013
-
-
David Blaikie authored
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
-
- Jun 19, 2013
-
-
David Blaikie authored
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
-
- Jun 16, 2013
-
-
David Blaikie authored
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
-
- Jun 07, 2013
-
-
David Blaikie authored
llvm-svn: 183454
-
- Jun 06, 2013
-
-
David Blaikie authored
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
-
- Jun 05, 2013
-
-
David Blaikie authored
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
-
- Jun 01, 2013
-
-
Benjamin Kramer authored
Also simplify code a bit while there. No functionality change. llvm-svn: 183076
-
- May 30, 2013
-
-
Eric Christopher authored
llvm-svn: 182903
-
- May 29, 2013
-
-
Manman Ren authored
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
-
- May 28, 2013
-
-
Manman Ren authored
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
-
- May 21, 2013
-
-
Manman Ren authored
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
-
David Blaikie authored
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
-
- May 11, 2013
-
-
Benjamin Kramer authored
llvm-svn: 181663
-