Do not convert dbg.declares to dbg.assigns for variables backed by scalable
vector allocas as this isn't yet supported.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D149959
This change will allow to put code pointers in DWARF info fields that are larger than actual pointer size, e.g. 16-bit pointers into 32-bit fields.
The need for this came up while creating support for MSP430 in LLDB. MSP430-GCC already generates DWARF info with 32-bit fields, so this change is necessary for LLDB to maintain compatibility with both GCC and LLVM binaries. Moreover, right now in LLDB there is no support for having DWARF pointer size different from ELF header type, e.g. 16-bit DWARF info within ELF32, and it seems there is no such thing as ELF16.
Since other mainline targets are made to have the same pointer size in both MCAsmInfo and DataLayout, there is no need to change anything there.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D148042
Some debuggers like DBX on AIX assume the address in debug line
entries is always incremental. But clang generates two entries (entry
for file scope line and entry for prologue end) with same address if
prologue is empty
And if the prologue is empty, seems the first debug line entry for the
function is unnecessary(i.e. removing the first entry won't impact the
behavior in GDB on Linux), so I implement this for all debuggers.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D147506
The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags
field which LLVM has had the values for (in the ProcSymFlags enum) but
has never actually set.
These flags are used by Microsoft-internal tooling that leverages debug
information to do binary analysis.
Modified LLVM to set the correct flags:
- ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that
debug info is present for optimized builds (if debug info is not emitted
for optimized builds, then LLVM won't emit a debug symbol at all).
- ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the
function has the NoReturn or NoInline attributes respectively.
- ProcSymFlags::HasFP - set if the function requires a frame pointer (per
TargetFrameLowering::hasFP).
Differential Revision: https://reviews.llvm.org/D148761
Allow shrink-wrapping past memory accesses that only access globals or
function arguments. This patch uses getUnderlyingObject to try to
identify the accessed object by a given memory operand. If it is a
global or an argument, it does not access the stack of the current
function and should not block shrink wrapping.
Note that the caller's stack may get accessed when passing an argument
via the stack, but not the stack of the current function.
This addresses part of the TODO from D63152.
Reviewed By: thegameg
Differential Revision: https://reviews.llvm.org/D149668
Without this patch, in `getAssignmentInfo` the result of `getTypeSizeInBits` is
cast to `uint64_t`, which a) is an operation that will eventually be
unsupported by the API according to the comments, and b) causes an assertion
failure if the type is a scalable vector. Don't cast the `TypeSize` to
`uint64_t` and check `isScalable` before getting the fixed size.
This can result in incorrect variable locations, see llvm.org/PR62346 (but is
better than crashing).
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D149137
The .cfi_sections .debug_frame intrinsic is used to emit .debug_frame
section. This directive tells the assembler to write out a section of
debug frame data. AArch64 is a platform where eh_frame is not needed for
unwind information. Unfortunately, that means that even when the
.cfi_sections .debug_frame intrinsic is used, the compiler skips
emitting the CIE's and FDE's in the debug_frame section. This patch
address that issue by making sure that the emission of CIE's and FDE's
are only skipped if the unwind information does not require a
debug_frame section and is a platform where the eh_frame can be skipped.
Differential Revision: https://reviews.llvm.org/D147980
There was some lacking test coverage for checking when the
.cfi_sections .debug_frame intrinsic is emitted. On x86_64,
with -fno-exceptions there is no .cfi_sections .debug_frame intrinsic
emitted because there is an unwind table attribute.
On AArch64, with -fno-exceptions, there is no unwind table attribute, so
the .cfi_sections .debug_frame intrinsic is emitted correctly.
Alternatively, with -fexceptions, both AArch64 and x86_64 emit an unwind
table and therefore do not emit a .cfi_sections .debug_frame intrinsic
All this work was done in addition to https://reviews.llvm.org/D139663
patch.
Differential Revision: https://reviews.llvm.org/D147747
Remove assert from AssignmentTrackingAnalysis that fires if a local variable
has non-alloca storage. The analysis can emit these locations but the
assignment tracking code in SelectionDAG isn't ready to handle non-alloca
storage for locals yet. The AssignmentTrackingPass (pass that adds assignment
tracking metadata) ignores non-alloca dbg.declares, so the only variables
affected are those who's backing storage is changed from an alloca during
optimisation, and the result is the variables are dropped.
Fixes: https://ci.chromium.org/ui/p/pigweed/builders/toolchain/
toolchain-ci-pigweed-linux/b8783274592206481489/overview
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D149135
A ValueAsMetadata may be replaced with nullptr for several reasons including
deleting (certain) values and value remapping a use-before-def. In the case of
a MetadataAsValue user, handleChangedOperand intercepts and replaces the
metadata with an empty tuple (!{}).
At the moment, an empty metadata operand in a debug intrinsics signals that it
can be deleted.
Given that we end up with empty metadata operands in circumstances where the
Value has been "lost" the current behaviour can lead to incorrect variable
locations. Instead, we should treat empty metadata as meaning "there is no
location for the variable" (the same as we currently treat undef operands).
This patch removes the deletion logic from wouldInstructionBeTriviallyDead.
Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D140901
In llvm/test/DebugInfo/Generic/empty.ll, there are two RUN lines. The
second one use the option "-split-dwarf-file=foo.dwo"
Since darwin doesn't support split dwarf, there is an assertion when
running the test:
"Assertion failed: (Section && "Cannot switch to a null section!"),
function switchSection, file llvm/lib/MC/MCStreamer.cpp, line 1238"
While there is an XFAIL for darwin in the test, It is not a good
practice to run a test on darwin which causes an assertion. This
patch is a small refactoring of the test so that the split-dwarf test
can be it's own file with an explicit elf triple.
Differential Review: https://reviews.llvm.org/D149106
In rare situations involving AVX intrinsics, it seems LLVM can be coaxed
into generating copies to arguments that look like this:
$xmm0 = VMOVAPSrr $xmm1, implicit-def $ymm0
CALL64 @something ymm0
This particular form of copy implicitly zeros the upper lanes of ymm0,
hence there's an implicit-def for the register in the copy. The X86
implementation of describeLoadedValue doesn't attempt to describe this sort
of copy which causes the generic implementation in
TargetInstrInfo::describeLoadedValue to fire an assertion saying it
expected the target hook to handle it.
Play it safe in the generic implementation and return the "no location /
value" return value, rather than asserting.
Differential Revision: https://reviews.llvm.org/D148626
This improves the readability of debugging intrinsics. Instead of:
call void @llvm.dbg.value(metadata !2, ...)
!2 = !{}
We will see:
call void @llvm.dbg.value(metadata !{}, ...)
!2 = !{}
Note that we still get a numbered metadata entry for the node even if it's not
used elsewhere. This is to avoid adding more context to the print functions.
This is already legal IR - LLVM can parse and understand it - so there is no
need to update the parser.
The next patches in this stack will make such empty metadata operands more
common and semantically important.
Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D140900
load if the load is moved due to the pre register allocation ld/st
optimization pass
The issue here is that there can be a scenario where debug information
is lost because of the pre register allocation load store optimization
pass, where a load who's result describes the debug infomation for a
local variable gets moved below the load and that causes the debug
information for that load to get lost.
Example:
Before the Pre Register Allocation Load Store Pass
inst_a
%2 = ld ...
inst_b
DBG_VALUE %2, "x", ...
%3 = ld ...
After the Pass:
inst_a
inst_b
DBG_VALUE %2, "x", ...
%2 = ld ...
%3 = ld ...
The load has now been moved to after the DBG_VAL that uses its result
and the debug info for "x" has been lost. What we want is:
inst_a
inst_b
%2 = ld ...
DBG_VALUE %2, "x", ...
%3 = ld ...
Which is what this patch addresses
Differential Revision: https://reviews.llvm.org/D145168
This is a recommit of 75f1f158812d, reverted in 7a443b1c493d, because
it caused compilation error in
compiler-rt/lib/sanitizer_common/symbolizer/sanitizer_symbolize.cpp.
The error was fixed by Kasimir Georgiev in de4c038c7ba2, but this
commit was reverted in de088dd3a0aa, because the initial commit was
reverted.
This commit reverts both the reverting commits, 7a443b1c493d and
de088dd3a0aa.
Original commit message is below.
If llvm-symbolize did not find module, the error looked like:
LLVMSymbolizer: error reading file: No such file or directory
This message does not follow common practice: LLVMSymbolizer is not an
utility name. Also the message did not not contain the name of missed file.
With this change the error message looks differently:
llvm-symbolizer: error: 'abc': No such file or directory
This format is closer to messages produced by other utilities and allow
proper coloring.
Differential Revision: https://reviews.llvm.org/D148032
Fixed issue where {tu,cu}-index fixup code for DWARF5 that would report an error when
fixup map is empty. Which is the case when seciton(s) are not over 4GB or
--manaully-generate-unit-index is not specified
Differential Revision: https://reviews.llvm.org/D148578
`shortenAssignment` inserts dbg.assigns with fragments describing the dead part
of a shortened store after each dbg.assign linked to the store.
Without this patch it doesn't take into account that the dead part of a
shortened store may be outside the bounds of a variable of a linked
dbg.assign. It also doesn't correctly account for a non-zero offset in the
address modifying `DIExpression` of the dbg.assign (which is possible for
fragments now even though whole variables currently cannot have a non-zero
offset in their alloca).
Fix this by moving the dead slice into variable-space and performing an
intersect of that adjusted slice with the existing fragment.
This fixes a verifier error reported when building fuchsia with assignment
tracking enabled:
https://ci.chromium.org/ui/p/fuchsia/builders/ci/
clang_toolchain.ci.core.x64-release/b8784000953022145169/overview
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148536
We shouldn't be able to reach this code path from source code but this provides
a better fail-safe than asserting. The result of the downgrade is a degraded
debugging experience, but it is better than nothing.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148212
Debug intrinsics sometimes end up with empty metadata location operands. The
debug intrinsic interfaces return nullptr when retrieving location operand in
this case.
Skip empty-metadata dbg.declares to avoid dereferencing the nullptr. This
doesn't affect the final debug info in any way.
Reviewed By: jryans
Differential Revision: https://reviews.llvm.org/D148204
Debug intrinsics sometimes end up with empty metadata location operands. The
debug intrinsic interfaces return nullptr when retrieving location operand in
this case.
When assignment tracking is not enabled a dbg.declare with a nullptr location
operand is skipped. Do the same when assignment tracking is enabled (a nullptr
address component of a dbg.assign is already handled correctly.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148203
If llvm-symbolize did not find module, the error looked like:
LLVMSymbolizer: error reading file: No such file or directory
This message does not follow common practice: LLVMSymbolizer is not an
utility name. Also the message did not not contain the name of missed file.
With this change the error message looks differently:
llvm-symbolizer: error: 'abc': No such file or directory
This format is closer to messages produced by other utilities and allow
proper coloring.
Differential Revision: https://reviews.llvm.org/D148032
According to
https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-preserve-an-instruction-location,
when moving (and in our case cloning) within the same BB, the debug
location is preserved. But when moving / cloning to a different BB, we
preserve the debug location only if the destination BB contains the same
location. Currently we preserve the debug loc unconditionally in all
cases. This CL correctly handles the debug locs in DebugValueManager.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D148115
This reverts commit 0aaf634152f25a805563d552e72d89e8202d84f2.
Reverted this because of build failure https://lab.llvm.org/buildbot#builders/245/builds/7035
/home/tcwg-buildbot/worker/clang-armv8-quick/llvm/llvm/test/DebugInfo/Generic/incorrect-variable-debugloc1.ll:28:12: error: DWARF23: expected string not found in input
; DWARF23: DW_OP_lit13{{$}}
^
<stdin>:1:1: note: scanning from here
-: file format elf32-littlearm
^
<stdin>:19:20: note: possible intended match here
DW_AT_frame_base (DW_OP_reg13 SP)
^
load if the load is moved due to the pre register allocation ld/st
optimization pass
The issue here is that there can be a scenario where debug information
is lost because of the pre register allocation load store optimization
pass, where a load who's result describes the debug infomation for a
local variable gets moved below the load and that causes the debug
information for that load to get lost.
Example:
Before the Pre Register Allocation Load Store Pass
inst_a
%2 = ld ...
inst_b
DBG_VALUE %2, "x", ...
%3 = ld ...
After the Pass:
inst_a
inst_b
DBG_VALUE %2, "x", ...
%2 = ld ...
%3 = ld ...
The load has now been moved to after the DBG_VAL that uses its result
and the debug info for "x" has been lost. What we want is:
inst_a
inst_b
%2 = ld ...
DBG_VALUE %2, "x", ...
%3 = ld ...
Which is what this patch addresses
Differential Revision: https://reviews.llvm.org/D145168
VLA backed variables currently trip an assertion in SROA with D146987 (enabling
assignment tracking). Disable assignment tracking for VLA variables until that
can be investigated.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148140
The assertion exists to ensure all variables passed into `trackAssignments` end
up with dbg.assigns associated with their backing allocas. The assertion
compared the passed-in and tracked variables using `DebugVariable`, which
includes the fragment as part of the variable identity.
It is possible for the backing alloca to be smaller than a variable (see test
case). In this case the input variable `(Var X, no fragment, no InlinedAt)`
isn't equal to the dbg.assign variable `(Var X, some fragment, no
InlinedAt)`. To cover this case the assertion now ignores fragments through the
use of `DebugVariableAggregate`.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148100
In D147777 emitDbgAssign was fixed to discard assignments which touched any
bits outside the bounds of a variable. This patch changes emitDbgAssign to
discard assignments which touch bits only outside the variable bounds, and
creates a truncated fragment expression for stores partially overlapping the
variable. This is necessary because the alloca is interpreted as a store (of
undef), meaning without this patch emitDbgAssign would discard the inital
dbg.assign for a variable that is smaller than the alloca.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148018
Some dbg.assigns using poison become un-poisoned in SROA. The reason this
happens at all is because dbg.assigns linked to memory intrinsics use poison to
indicate they can't describe the stored value, but the value becomes available
after some optimisations. This needs reworking eventually, but for now we need
to ensure that when it does occur we don't create invalid expressions.
D147312 prevented this occuring when the dbg.assign uses DIArgLists, but that
wasn't a complete fix. We also need to ensure we avoid un-poisoning when the
existing expression uses more than one location operand (DW_OP_arg, n).
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D148020
Prior to this patch the trackAssignments function would attribute all stores to
an alloca to all variables linked to the alloca. This is wrong in the case
where the alloca contains variables which are smaller than the alloca, and
caused erroneous fragment information to be generated.
Now stores outside the variable bounds are discarded, and we check whether a
fragment is needed based on whether the store covers the entire variable as
opposed to whether it covers the entire alloca (except for variables of unknown
size).
Note that trackAssignments doesn't yet understand whole variables sitting at
anything other than offset 0 in an alloca - those variables are still tracked
using dbg.declares.
Fixes https://lab.llvm.org/buildbot/#/builders/70/builds/36007
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D147777
Correctly handle the case of splitting an alloca which backs contiguous
distinct variables, where a slice's size equals the size of a backed variable.
We need to ensure that we don't generate fragments expressions with fragments
of the same size as the variable as this is a verifier error.
Prior to this patch a fragment expression would be created in this
situation. e.g. splitting an alloca i64 with two adjacent 32-bit variables into
two 32-bit allocas, the new dbg.assign expressions would contain
(DW_OP_LLVM_fragment, 0, 32) and (DW_OP_LLVM_fragment, 32, 32) even though
those fragments cover each variable entirely.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D147696
Implement emission of DWARF CFI instructions for MSP430. This includes descriptions of stack frame layout and location of callee-saved registers that could be used for backtracing.
Differential Revision: https://reviews.llvm.org/D146966
This makes parsing for build IDs in the markup filter slightly more
permissive, in line with fromHex.
It also removes the distinction between missing build ID and empty build
ID; empty build IDs aren't a useful concept, since their purpose is to
uniquely identify a binary. This removes a layer of indirection wherever
build IDs are obtained.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D147485
createFragmentExpression will fail if it determines that the expression cannot
be split over fragments. Handle this case in SROA. Similarly to D147312 this
should be a rare occurrence as the `dbg.assign` will usually reference the
`Value` being stored without modifying it with a `DIExpression`.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D147431
Such dbg.assigns will occur if you write zero-sized memcpys (see
https://reviews.llvm.org/D146987#4240016).
Handle this in AssignmentTrackingAnalysis (back end) rather than
AssignmentTrackingPass (declare-to-assign) in case it is possible to reproduce
this as a result of optimisations.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D147435
If the to-be-split dbg.assign has a `DIArgList` and a new `Value` has been
requested then use a kill-location for the new dbg.assign. We can't simply
replace the value component (a `DIArgList`) with the new `Value` as that would
leave the `DIExpression` in an invalid state (`DW_OP_LLVM_arg` operands with no
arglist).
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D147312
Given the intent of Split DWARF is to minimize .o file size it seems
like adequate signal that it's worth a minor tradeoff in .dwo size to
significantly reduce .o size (though it doesn't reduce linked executable
size - the cost is mostly in the static relocations resolved by the
linker).
In `DebugValueManager`, if a `Def` is requested to be sunk to the same
place (i.e., `Insert` is right after `Def`, not counting `DBG_VALUE`s)
currently we still do the sink. This can result in unnecessary creation
of `DBG_VALUE $noreg`. See comments for details. This CL detects this
case and do nothing and return, so we don't end up creating unnecessary
undef `DBG_VALUE`s.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D146860
