#
5bc8543a |
| 12-May-2017 |
Reid Kleckner <rnk@google.com> |
[codeview] Fix assertion failure introduced in r295354 refactoring
CodeViewDebug sets Asm to nullptr to disable debug info generation. You can get a .ll file like no-cus.ll from 'clang -gcodeview -
[codeview] Fix assertion failure introduced in r295354 refactoring
CodeViewDebug sets Asm to nullptr to disable debug info generation. You can get a .ll file like no-cus.ll from 'clang -gcodeview -g0', which happens in the ubsan test suite.
llvm-svn: 302923
show more ...
|
Revision tags: llvmorg-4.0.1-rc1 |
|
#
8f333795 |
| 23-Mar-2017 |
Adrian Prantl <aprantl@apple.com> |
Zero-Initialize PrevInstBB when entering a new MachineFunction.
It is not guaranteed that the memory used for MachineBasicBlocks in the previous MachineFunction hasn't been freed, so holding on to a
Zero-Initialize PrevInstBB when entering a new MachineFunction.
It is not guaranteed that the memory used for MachineBasicBlocks in the previous MachineFunction hasn't been freed, so holding on to a pointer to the last function's isn't correct. Particularly I have observed the sret.ll testcase failing because the first BasicBlock in the new function happened to be allocated to the exact same memory as the previously saved and (deleted) PrevInstBB.
llvm-svn: 298642
show more ...
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
#
b2fbb4b2 |
| 16-Feb-2017 |
David Blaikie <dblaikie@gmail.com> |
Refactor DebugHandlerBase a bit to common non-debug-having-function filtering
llvm-svn: 295354
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
#
49797ca6 |
| 22-Dec-2016 |
Adrian Prantl <aprantl@apple.com> |
Refactor the DIExpression fragment query interface (NFC) ... so it becomes available to DIExpressionCursor.
llvm-svn: 290322
|
#
ac7fe5e0 |
| 12-Dec-2016 |
Paul Robinson <paul.robinson@sony.com> |
Recommit r288212: Emit 'no line' information for interesting 'orphan' instructions.
DWARF specifies that "line 0" really means "no appropriate source location" in the line table. By default, use th
Recommit r288212: Emit 'no line' information for interesting 'orphan' instructions.
DWARF specifies that "line 0" really means "no appropriate source location" in the line table. By default, use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source).
Updated patch allows enabling or suppressing this behavior for all unspecified source locations.
Differential Revision: http://reviews.llvm.org/D24180
llvm-svn: 289468
show more ...
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3 |
|
#
941fa758 |
| 05-Dec-2016 |
Adrian Prantl <aprantl@apple.com> |
[DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operation so we can stop using DW_OP_bit_piece with the wrong semantics.
The entire back story can be found here: http://lists.llvm.org/piper
[DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operation so we can stop using DW_OP_bit_piece with the wrong semantics.
The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html
The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly.
Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it.
Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809
llvm-svn: 288683
show more ...
|
Revision tags: llvmorg-3.9.1-rc2 |
|
#
b66cb88c |
| 01-Dec-2016 |
Kostya Serebryany <kcc@google.com> |
revert r288283 as it causes debug info (line numbers) to be lost in instrumented code. also revert r288299 which was a workaround for the problem.
llvm-svn: 288300
|
#
37a13ddb |
| 30-Nov-2016 |
Paul Robinson <paul.robinson@sony.com> |
Recommit r288212: Emit 'no line' information for interesting 'orphan' instructions. The LLDB tests are now ready for this patch.
DWARF specifies that "line 0" really means "no appropriate source loc
Recommit r288212: Emit 'no line' information for interesting 'orphan' instructions. The LLDB tests are now ready for this patch.
DWARF specifies that "line 0" really means "no appropriate source location" in the line table. Use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source).
Differential Revision: http://reviews.llvm.org/D24180
llvm-svn: 288283
show more ...
|
#
957ba405 |
| 29-Nov-2016 |
Paul Robinson <paul.robinson@sony.com> |
Revert r288212 due to lldb failure.
llvm-svn: 288216
|
#
96de8c77 |
| 29-Nov-2016 |
Paul Robinson <paul.robinson@sony.com> |
Emit 'no line' information for interesting 'orphan' instructions.
DWARF specifies that "line 0" really means "no appropriate source location" in the line table. Use this for branch targets and some
Emit 'no line' information for interesting 'orphan' instructions.
DWARF specifies that "line 0" really means "no appropriate source location" in the line table. Use this for branch targets and some other cases that have no specified source location, to prevent inheriting unfortunate line numbers from physically preceding instructions (which might be from completely unrelated source).
Differential Revision: http://reviews.llvm.org/D24180
llvm-svn: 288212
show more ...
|
Revision tags: llvmorg-3.9.1-rc1 |
|
#
e1156c2e |
| 31-Oct-2016 |
Victor Leschuk <vleschuk@accesssoftek.com> |
DebugInfo: make DW_TAG_atomic_type valid
DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly, however Verifier didn't recognize it as valid. Thus we introduce the following c
DebugInfo: make DW_TAG_atomic_type valid
DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly, however Verifier didn't recognize it as valid. Thus we introduce the following changes:
* Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5) * Add it to related docs * Add DebugInfo tests
Differential Revision: https://reviews.llvm.org/D26144
llvm-svn: 285624
show more ...
|
#
a5b1eef8 |
| 26-Aug-2016 |
Reid Kleckner <rnk@google.com> |
[MC] Move .cv_loc management logic out of MCContext
MCContext already has many tasks, and separating CodeView out from it is probably a good idea. The .cv_loc tracking was modelled on the DWARF trac
[MC] Move .cv_loc management logic out of MCContext
MCContext already has many tasks, and separating CodeView out from it is probably a good idea. The .cv_loc tracking was modelled on the DWARF tracking which lived directly in MCContext.
Removes the inclusion of MCCodeView.h from MCContext.h, so now there are only 10 build actions while I hack on CodeView support instead of 265.
llvm-svn: 279847
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
#
acee5685 |
| 12-Jul-2016 |
Amjad Aboud <amjad.aboud@intel.com> |
[codeview] Improved array type support.
Added support for: 1. Multi dimension array. 2. Array of structure type, which previously was declared incompletely. 3. Dynamic size array. 4. Array where ele
[codeview] Improved array type support.
Added support for: 1. Multi dimension array. 2. Array of structure type, which previously was declared incompletely. 3. Dynamic size array. 4. Array where element type is a typedef, volatile or constant (this should resolve PR28311).
Differential Revision: http://reviews.llvm.org/D21526
llvm-svn: 275167
show more ...
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
#
28865809 |
| 14-Apr-2016 |
Reid Kleckner <rnk@google.com> |
Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.h
MachineInstr.h and MachineInstrBuilder.h are very popular headers, widely included across all LLVM backends. It turns out that
Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.h
MachineInstr.h and MachineInstrBuilder.h are very popular headers, widely included across all LLVM backends. It turns out that there only a handful of TUs that actually care about DI operands on MachineInstrs.
After this change, touching DebugInfoMetadata.h and rebuilding llc only needs 112 actions instead of 542.
llvm-svn: 266351
show more ...
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3 |
|
#
f9c275fe |
| 10-Feb-2016 |
Reid Kleckner <rnk@google.com> |
[codeview] Describe int local variables using .cv_def_range
Summary: Refactor common value, scope, and label tracking logic out of DwarfDebug into a common base class called DebugHandlerBase.
Updat
[codeview] Describe int local variables using .cv_def_range
Summary: Refactor common value, scope, and label tracking logic out of DwarfDebug into a common base class called DebugHandlerBase.
Update an old LLVM IR test case to avoid an assertion in LexicalScopes.
Reviewers: dblaikie, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16931
llvm-svn: 260432
show more ...
|