[lldb] Encode operands and arity in Dwarf.def and use them in LLDB. (#94679)

This PR extends Dwarf.def to include the number of operands and the arity (the
number of entries on the DWARF stack).

[lldb] Encode operands and arity in Dwarf.def and use them in LLDB. (#94679)

This PR extends Dwarf.def to include the number of operands and the arity (the
number of entries on the DWARF stack).

- The arity is used in LLDB's DWARF expression evaluator.
- The number of operands is unused, but is present in the table to avoid
confusing the arity with the operands. Keeping the latter up to date should
be straightforward as it maps directly to a table present in the DWARF
standard.

show more ...

[DebugInfo] Add DW_OP_LLVM_extract_bits (#93990)

This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift followed
by

[DebugInfo] Add DW_OP_LLVM_extract_bits (#93990)

This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift followed
by a right shift.

This is being added for use in clang for C++ structured bindings of
bitfields that have offset or size that aren't a byte multiple. A new
operation is being added, instead of shifts being used directly, as it
makes correctly handling it in optimisations (which will be done in a
later patch) much easier.

show more ...

Implement the DWARF 6 language and version attributes. (#89980)

This patch adds DWARF constants for DW_AT_language_name and
DW_AT_language_version to Dwarf.def and Dwarf.h.

While the DWARF 6 spe

Implement the DWARF 6 language and version attributes. (#89980)

This patch adds DWARF constants for DW_AT_language_name and
DW_AT_language_version to Dwarf.def and Dwarf.h.

While the DWARF 6 spec is not finalized, the constants are published on
the DWARF website and considered stable, with idea being that the list
published on dwarfstd.org is the authoritative source that is being
continuously updated between DWARF revisions, as new languages are being
developed.

https://dwarfstd.org/languages-v6.html

My main motivation for adding this is to use in
https://github.com/llvm/llvm-project/pull/89981

show more ...

[DebugInfo] Add DW_OP_LLVM_user extension point

The extension codespace for DWARF expressions (DW_OP_LLVM_{lo,hi}_user)
has shrunk over time, as no extension is ever "retired" in practice. To
facili

[DebugInfo] Add DW_OP_LLVM_user extension point

The extension codespace for DWARF expressions (DW_OP_LLVM_{lo,hi}_user)
has shrunk over time, as no extension is ever "retired" in practice. To
facilitate future extensions, this patch reserves one open opcode as an extension
point (0xfe), which is followed by a ULEB128-encoded SubOperation, and
then by the subop's operands.

There is some prior-art, namely DW_OP_AARCH64_operation
(see https://github.com/ARM-software/abi-aa/blob/edd7460d87493fff124b8b5713acf71ffc06ee91/aadwarf64/aadwarf64.rst#45dwarf-expression-operations).

This version makes some different tradeoffs, opting to use a ULEB128 for
the subop encoding for future-proofing.

Reviewed By: #debug-info, dblaikie

Differential Revision: https://reviews.llvm.org/D147271

show more ...

[DebugInfo] Handle missed DW_FORM_addrx3 and DW_FORM_strx3 cases

This fixes a few places where the addrx3 and strx3 forms were missed.
Previously this meant if one of these forms appeared somewhere

[DebugInfo] Handle missed DW_FORM_addrx3 and DW_FORM_strx3 cases

This fixes a few places where the addrx3 and strx3 forms were missed.
Previously this meant if one of these forms appeared somewhere various
errors could occur. This now also adds an extra test case for the addrx3
form (which previously failed).

Differential Revision: https://reviews.llvm.org/D143488

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[DebugInfo] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Reapply "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"

Rewrites test to use correct architecture triple; fixes incorrect
reference in SourceLevelDebugging doc

Reapply "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"

Rewrites test to use correct architecture triple; fixes incorrect
reference in SourceLevelDebugging doc; simplifies `spillReg` behaviour
so as to not be dependent on changes elsewhere in the patch stack.

This reverts commit d2000b45d033c06dc7973f59909a0ad12887ff51.

show more ...

Revert "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"

This reverts commit d07f106f4a48b6e941266525b6f7177834d7b74e.

[DebugInfo] Add new instruction and DIExpression operator for variadic debug values

This patch adds a new instruction that can represent variadic debug values,
DBG_VALUE_VAR. This patch alone covers

[DebugInfo] Add new instruction and DIExpression operator for variadic debug values

This patch adds a new instruction that can represent variadic debug values,
DBG_VALUE_VAR. This patch alone covers the addition of the instruction and a set
of basic code changes in MachineInstr and a few adjacent areas, but does not
correctly handle variadic debug values outside of these areas, nor does it
generate them at any point.

The new instruction is similar to the existing DBG_VALUE instruction, with the
following differences: the operands are in a different order, any number of
values may be used in the instruction following the Variable and Expression
operands (these are referred to in code as “debug operands”) and are indexed
from 0 so that getDebugOperand(X) == getOperand(X+2), and the Expression in a
DBG_VALUE_VAR must use the DW_OP_LLVM_arg operator to pass arguments into the
expression.

The new DW_OP_LLVM_arg operator is only valid in expressions appearing in a
DBG_VALUE_VAR; it takes a single argument and pushes the debug operand at the
index given by the argument onto the Expression stack. For example the
sub-expression `DW_OP_LLVM_arg, 0` has the meaning “Push the debug operand at
index 0 onto the expression stack.”

Differential Revision: https://reviews.llvm.org/D82363

show more ...

[Debuginfo][DW_OP_implicit_pointer] (1/7) Support for DW_OP_LLVM_implicit_pointer

New dwarf operator DW_OP_LLVM_implicit_pointer is introduced (present only in LLVM IR)
This operator is required as

[Debuginfo][DW_OP_implicit_pointer] (1/7) Support for DW_OP_LLVM_implicit_pointer

New dwarf operator DW_OP_LLVM_implicit_pointer is introduced (present only in LLVM IR)
This operator is required as it is different than DWARF operator
DW_OP_implicit_pointer in representation and specification (number
and types of operands) and later can not be used as multiple level.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D84113

show more ...

DebugInfo: Cleanup RLE dumping, using a length-constrained DataExtractor rather than carrying the end offset separately

[DebugInfo] Allow GNU macro extension to be read

Allow the GNU .debug_macro extension to be parsed and printed by
llvm-dwarfdump. In an upcoming patch support will be added for emitting
that format

[DebugInfo] Allow GNU macro extension to be read

Allow the GNU .debug_macro extension to be parsed and printed by
llvm-dwarfdump. In an upcoming patch support will be added for emitting
that format also.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D82974

show more ...

[BinaryFormat] Add formatv support for DW_OP constants

The functionality will be used from lldb.

[DebugInfo] Report the format of call frame information entries [6/10]

Differential Revision: https://reviews.llvm.org/D80523

[DebugInfo] Extract a helper function to return the DWARF format name, NFC [1/10]

Differential Revision: https://reviews.llvm.org/D80523

[DebugInfo]: Added DWARFv5 macro header flags and corresponding helper
functions.

DWARFDebugLine.cpp: Format unknown line number standard opcodes

Summary:
This patch implements `formatv()` formatting for `dwarf::LineNumberOps`
and makes use of it for the `llvm-dwarfdump --debug-l

DWARFDebugLine.cpp: Format unknown line number standard opcodes

Summary:
This patch implements `formatv()` formatting for `dwarf::LineNumberOps`
and makes use of it for the `llvm-dwarfdump --debug-line` dump.

Previously, unknown line number standard opcodes would lead to undefined
behaviour. The code would attempt to format the data pointer of an empty
`StringRef` (a null pointer) using `%s`. According to the description
for `format()`, use of that interface carries the "risk of `printf`".
Passing a null pointer in place of an array to a C library function
results in undefined behaviour.

Reviewers: jhenderson, daltenty, stevewan

Reviewed By: jhenderson

Subscribers: aprantl, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D72369

show more ...

[DWARF5] Added support for deleted C++ special member functions.

This patch adds support for deleted C++ special member functions in
clang and llvm. Also added Defaulted member encodings for future

[DWARF5] Added support for deleted C++ special member functions.

This patch adds support for deleted C++ special member functions in
clang and llvm. Also added Defaulted member encodings for future
support for defaulted member functions.

Patch by Sourabh Singh Tomar!

Differential Revision: https://reviews.llvm.org/D69215

show more ...

[DebugInfo] Add a DW_OP_LLVM_entry_value operation

Summary:
Internally in LLVM's metadata we use DW_OP_entry_value operations with
the same semantics as DWARF; that is, its operand specifies the num

[DebugInfo] Add a DW_OP_LLVM_entry_value operation

Summary:
Internally in LLVM's metadata we use DW_OP_entry_value operations with
the same semantics as DWARF; that is, its operand specifies the number
of bytes that the entry value covers.

At the time of emitting entry values we don't know the emitted size of
the DWARF expression that the entry value will cover. Currently the size
is hardcoded to 1 in DIExpression, and other values causes the verifier
to fail. As the size is 1, that effectively means that we can only have
valid entry values for registers that can be encoded in one byte, which
are the registers with DWARF numbers 0 to 31 (as they can be encoded as
single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte
DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump
will print an operation "correctly", even if the byte size is less than
that, which may make it seem that we emit correct DWARF for registers
with DWARF numbers > 31. If you instead use readelf for such cases, it
will interpret the number of specified bytes as a DWARF expression. This
seems like a limitation in llvm-dwarfdump.

As suggested in D66746, a way forward would be to add an internal
variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand
instead specifies the number of operations that the entry value covers,
and we then translate that into the byte size at the time of emission.

In this patch that internal operation is added. This patch keeps the
limitation that a entry value can only be applied to simple register
locations, but it will fix the issue with the size operand being
incorrect for DWARF numbers > 31.

Reviewers: aprantl, vsk, djtodoro, NikolaPrica

Reviewed By: aprantl

Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits

Tags: #debug-info, #llvm

Differential Revision: https://reviews.llvm.org/D67492

llvm-svn: 374881

show more ...

DebugInfo: Move LLE enum handling to .def to match RLE handling

llvm-svn: 374122

[Dwarf] Complete the list of type tags.

An incorrect verification error revealed that the list of type tags was
incomplete. This patch adds the missing types by adding a tag kind to
the Dwarf.def fi

[Dwarf] Complete the list of type tags.

An incorrect verification error revealed that the list of type tags was
incomplete. This patch adds the missing types by adding a tag kind to
the Dwarf.def file, which is used by the `isType` function.

A test was added for the original verification error.

Differential revision: https://reviews.llvm.org/D65914

llvm-svn: 368718

show more ...

hwasan: Add a tag_offset DWARF attribute to instrumented stack variables.

The goal is to improve hwasan's error reporting for stack use-after-return by
recording enough information to allow the spec

hwasan: Add a tag_offset DWARF attribute to instrumented stack variables.

The goal is to improve hwasan's error reporting for stack use-after-return by
recording enough information to allow the specific variable that was accessed
to be identified based on the pointer's tag. Currently we record the PC and
lower bits of SP for each stack frame we create (which will eventually be
enough to derive the base tag used by the stack frame) but that's not enough
to determine the specific tag for each variable, which is the stack frame's
base tag XOR a value (the "tag offset") that is unique for each variable in
a function.

In IR, the tag offset is most naturally represented as part of a location
expression on the llvm.dbg.declare instruction. However, the presence of the
tag offset in the variable's actual location expression is likely to confuse
debuggers which won't know about tag offsets, and moreover the tag offset
is not required for a debugger to determine the location of the variable on
the stack, so at the DWARF level it is represented as an attribute so that
it will be ignored by debuggers that don't know about it.

Differential Revision: https://reviews.llvm.org/D63119

llvm-svn: 363635

show more ...

[DebugInfo] Introduce DW_OP_LLVM_convert

Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an a

[DebugInfo] Introduce DW_OP_LLVM_convert

Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows
for a convenient way to perform type conversions on the Dwarf expression
stack. As an additional bonus it paves the way for using other Dwarf
v5 ops that need to reference a base_type.

The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp
to perform sext/zext on debug values but mainly the patch is about
preparing terrain for adding other Dwarf v5 ops that need to reference a
base_type.

For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a
complex shift & mask pattern is generated to emulate sext/zext.

This is a recommit of r356442 with trivial fixes for the failing tests.

Differential Revision: https://reviews.llvm.org/D56587

llvm-svn: 356451

show more ...