History log of /llvm-project/llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp (Results 76 – 90 of 90)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1234