We want to use `DexDeclareFile` to specify paths relative to a project root
directory. The option `--source-root-dir`, prior to this patch, causes dexter
to strip the path prefix from commands before passing them to a debugger, and
appends the prefix to file paths returned from a debugger. This patch changes
the behviour of `--source-root-dir`. Relative paths in commands, made possible
with `DexDeclareFile(relative/path)`, are appended to the `--source-root-dir`
directory.
A new option, `--debugger-use-relative-paths`, can be used alongside
`--source-root-dir` to reproduce the old behaviour: all paths passed to the
debugger will be made relative to `--source-root-dir`.
I've added a regression test source_root_dir.dex for this new behaviour, and
modified the existing `--source-root-dir` regression and unit tests to use
`--debugger-use-relative-paths`.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D100307
DexDeclareFile allows test producers to write test files with .dex extensions
that contain pure dexter commands.
.dex file commands do not need to be commented out like they do when written
inline within test source files.
DexDeclareFile commands are declarative in behaviour, they state that any
Dexter command seen from this point on will have its path attribute set to the
path declared in the DexDeclareFile command.
Differential Revision: https://reviews.llvm.org/D99651
The removed code just replicated what use_llvm_tool does, plus looked
for an installed LLDB on the PATH to use. In a monorepo world, it seems
likely that if people want to run the tests that require LLDB, they
should enable and build LLDB itself. If users really want to use the
installed LLDB executable, they can specify the path to the executable
as an environment variable "LLDB".
See the discussion in https://reviews.llvm.org/D95339#2638619 for
more details.
Reviewed by: jmorse, aprantl
Differential Revision: https://reviews.llvm.org/D102680
The DexLimitSteps command leading breakpoint will be deleted after triggering
'hit_count' number of times if the argument is provided.
All the lit tests pass on linux (with lldb), and I've tested this on windows
(with vs2017) manually as the lit tests for DexLimitSteps are currently
unsupported on windows.
Reviewed By: StephenTozer, chrisjackson
Differential Revision: https://reviews.llvm.org/D101527
This patch changes how line labels are resolved in order to enable
label-relative offsets to be used in commands. This is a breaking change in
dexter. Instead of using label references directly as argument values, labels
will instead be referenced through a function `ref(str)`.
// No way to use offsets currently.
Currently: DexExpectWatchValue('x', '1', on_line='labled_line')
Patched: DexExpectWatchValue('x', '1', on_line=ref('labled_line'))
Patched: DexExpectWatchValue('x', '1', on_line=ref('labled_line') + 3)
A dexter command is "parsed" by finding the whole command and sending it off to
`eval`. This change adds a function called `ref` to the `eval` globals map that
simply looks up the name and returns an int. If the line name hasn't been
defined, or a name is defined more than once, an error is reported (see
err_bad_label_ref.cpp and err_duplicate_label.cpp). Label offsets can be
achieved by simply writing the desired expression.
The rationale behind removing the existing label referencing mechanic is for
consistency and to simplify the code required to make labels work.
I've separated the update to llvm's dexter tests into another patch for ease of
review here (D101148). Here is a small python script which can be used to
update tests to use the new syntax:
https://gist.github.com/OCHyams/8255efe7757cac266440ed2ba55f1442
If it helps anyone using dexter on downstream tests we can come up with a
deprecation plan instead out outright removing the existing syntax.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D101147
Currently, if the user specifies the environment variable 'CLANG', tests
will attempt to use the value as a path to the clang executable.
Previously, lldb could also be specified via the CLANG environment
variable, but this was almost certainly a bug, because that meant both
clang and lldb would have the same path. This patch changes the
environment variable for lldb to 'LLDB'.
Reviewed by: thopre, teemperor
Differential Revision: https://reviews.llvm.org/D101982
Currently the DexLimitSteps command requires at least one condition. This patch
lets users elide the condition to specify that the breakpoint range should
always be activated when the leading line is stepped on. This patch also
updates the terminology used in the `ConditionalController` class from the
terms 'conditional' and 'unconditional' to 'leading' and 'trailing' when
referring to the breakpoints in the DexLimitSteps range because the leading
breakpoint can now be unconditional.
Reviewed By: chrisjackson
Differential Revision: https://reviews.llvm.org/D101438
Remove the `ConditionalController._conditional_met` method. This was missed in
the recent ConditionalController refactor (D98699). We don't need to check that
the conditions for a conditional breakpoint have been met because
`DebuggerBase.get_triggered_breakpoint_ids` returns the set of ids for
breakpoints which have been triggered.
To get the "triggered breakpoints" from lldb we use `GetStopReasonDataCount`
and `GetStopReasonDataAtIndex`. It seems that these functions count all
breakpoints associated with the location which lldb has stopped at, regardless
of their condition. i.e. Even if we have two breakpoints at the same source
location that have mutually exclusive conditions, both will be found this way
when either condition is true. To get around this, we store a map of breakpoint
{id: condition} `_breakpoint_conditions` and evaluate the conditions of the
triggered breakpoints to filter the set down to those which are unconditional
or have a condition which evaluates to true.
Essentially we are just moving the condition double check from a general
debugger controller into the lldb specific wrapper. This tidy up will help make
upcoming patches simpler.
Reviewed By: chrisjackson
Differential Revision: https://reviews.llvm.org/D101431
Commit 7deb970ef added REQUIRES and UNSUPPORTED lines to a test which is
sensitive to line number changes. Update the line number reference in the test.
As this is a test that actually gets to operating the debugger, it
needs to be limited to scenarios where the debugger is available.
(We'll file this in the set of things Dexter doesn't handle gracefully..)
Add optional keyword argument 'on_line' to DexLabel to label the specifed line
instead of the line the command is found on.
This will be helpful when used alongside DexDeclareFile (D99651).
Reviewed By: TWeaver
Differential Revision: https://reviews.llvm.org/D101055
Using a DexLimitSteps command forces dexter to use the ConditionalController
debugger controller. At each breakpoint the ConditionalController needs to
understand which one has been hit. Prior to this patch, upon hitting a
breakpoint, dexter used the current source location to look up which requested
breakpoint had been hit.
A breakpoint may not get set at the exact location that the user (dexter)
requests. For example, if the requested breakpoint location doesn't exist
in the line table then then debuggers will (usually, AFAICT) set the breakpoint
at the next available valid breakpoint location.
This meant that, occasionally in unoptimised programs and frequently in
optimised programs, the ConditionalController was failing to determine which
breakpoint had been hit.
This is the fix:
Change the DebuggerBase breakpoint interface to use opaque breakpoint ids
instead of using source location to identify breakpoints, and update the
ConditionalController to track breakpoints instead of locations.
These now return a breakpoint id:
add_breakpoint(self, file_, line)
_add_breakpoint(self, file_, line)
add_conditional_breakpoint(self, file_, line, condition)
_add_conditional_breakpoint(self, file_, line, condition)
Replace:
delete_conditional_breakpoint(self, file_, line, condition)
_delete_conditional_breakpoint(self, file_, line, condition)
with:
delete_breakpoint(self, id)
Add:
get_triggered_breakpoint_ids(self)
A breakpoint id is guaranteed to be unique for each requested breakpoint, even
for duplicate breakpoint requests. Identifying breakpoints like this, instead
of by location, removes the possibility of mixing up requested and bound
breakpoints.
This closely matches the LLDB debugger interface so little work was required in
LLDB.py, but some extra bookkeeping is required in VisualStudio.py to maintain
the new breakpoint id semantics. No implementation work has been done in
dbgeng.py as DexLimitSteps doesn't seem to support dbgeng at the moment.
Testing
Added:
dexter/feature_tests/commands/perfect/limit_steps/limit_steps_line_mismatch.cpp
There were no unexpected failures running the full debuginfo-tests suite.
The regression tests use dbgeng on windows by default, and as mentioned above
dbgeng isn't supported yet, so I have also manually tested (i.e. without lit)
that this specific test works as expected with clang and Visual Studio 2017 on
Windows.
Reviewed By: TWeaver
Differential Revision: https://reviews.llvm.org/D98699
The test optnone-simple-functions.cpp added in D97668 fails on macOS.
os.path.exists raises an exception because we pass it None. Guard against this.
Related revision: https://reviews.llvm.org/D97668
Add dexter tests using the optnone attribute in various scenarios. Our users
have found optnone useful when debugging optimised code. We have these tests
downstream (and one upstream already: D89873) and we would like to contribute
them if there is any interest.
The tests are fairly self explanatory. Testing optnone with:
* optnone-fastmath.cpp: floats and -ffast-math,
* optnone-simple-functions: simple functions and integer arithmetic,
* optnone-struct-and-methods: a struct with methods,
* optnone-vectors-and-functions: templates and integer vector arithmetic.
optnone-vectors-and-functions contains two FIXMEs. The first problem is that
lldb seems to struggle with evaluating expressions with the templates used
here (example below). Perhaps this is PR42920?
(lldb) p TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
error: <user expression 0>:1:1: no template named 'TypeTraits'
TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
^
The second is that while lldb cannot evaluate the following expression, gdb
can, but it reports that the variable has been optimzed away. It does this when
compiling at O0 too. llvm-dwarfdump shows that MysteryNumber does have a
location. I don't know whether the DIE is bad or if both debuggers just don't
support it.
TypeTraits<int __attribute__((ext_vector_type(4)))>::MysteryNumber
DW_TAG_variable
DW_AT_specification (0x0000006b "MysteryNumber")
DW_AT_location (DW_OP_addr 0x601028)
DW_AT_linkage_name ("_ZN10TypeTraitsIDv4_iE13MysteryNumberE")
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D97668
Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D95119
If the default target and host triple don't match then print the following
message when the lit test runs:
Forcing dexter tests to use host triple {HOST_TRIPLE}.
If we can't target the host arch then, when lit runs, we mark
the dexter test directories as UNSUPPORTED and print the message:
Host triple {HOST_TRIPLE} not supported. Skipping dexter tests in
the debuginfo-tests project.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D96494
This test was accidently removed when the directory structure was shuffled
around for dexter in f78c236efd.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D96968
LLVM has a minimum requirement of python 3.6 now, and Python is
explicitly checked for in the LLVM CMakeLists.txt, so this check is no
longer needed here.
Differential Revision: https://reviews.llvm.org/D96499
Reviewed by: aprantl
The '%dexter_regression_test' substitution was missing quotes around the
python executable, unlike other substitutions of a similar nature in the
file. This changes fixes the issue.
Differential Revision: https://reviews.llvm.org/D96420
Reviewed by: jmorse, aganea
Since the new pass manager has been enabled by default these tests had their
-O1 variations failing due to the tested functions being inlined. This just
adds no_inline to the respective code similar to what we did in other
tests (e.g. aa56b30014 ).
This reverts commit 511dd4f438 along with
a couple fixes.
Original message:
Now the context is the first, rather than the last input.
This better matches the rest of the infrastructure and makes
it easier to move these types to being declaratively specified.
Phabricator: https://reviews.llvm.org/D96111
This method of the dbgeng debugger driver used to just "pass", as setting
dbgeng free running still leads to numerous errors. This wasn't a problem
in the past because, as it turns out, nothing called the go method.
However, a recent refactor uses it.
Rather than launch dbgeng free running, instead have it single step one
step forwards. This is slow, but it makes progress, where previously we
weren't.
Differential Revision: https://reviews.llvm.org/D91737
Tweak dexter-tests/memvars/inline-escaping-function.c added in D94761
(b7e516202e) by adding a 'param' use after the merge point. The test XFAILS
with and without this change, but without it the test looks very similar to
memvars/unused-merged-value.c. The test now demonstrates the problem more
clearly.
These dexter tests illustrate PR48719, the summary of which is:
Sometimes we insert dbg.values for merged values (PHIs) when promoting
variables, sometimes we don't. Sometimes there is no PHI because the merged
value is never used. It doesn't matter because LiveDebugValues understands these
merged values (implicit or otherwise) and correctly updates the debug
info. Importantly, these merged variable values (which may or may not exist as
PHIs, and may or not be represented with dbg.values) are //always// implicitly
defined by the combination of incoming edges and the incoming variable locations
along those edges by virtue of LiveDebugValues existing. Unfortunately, it is
possible to mess with the CFG and remove / move these edges before
LiveDebugValues runs. In this case our debug info model only works when the
merged value is tracked by a dbg.value. Currently, this is only done rigorously
for variables which are A) promoted in the first round of mem2reg and B) are
used after the merge point.
As an example, compile the following source with -O3 -g and step through with a
debugger. You will see parama=5 throughout the function fun which is incorrect -
we expect to see param=20 after the conditional assignment.
__attribute__((optnone))
void esc(int* p) {}
__attribute__((optnone))
void fluff() {}
__attribute__((noinline))
int fun(int parama, int paramb) {
if (parama)
parama = paramb;
fluff(); // DexLabel('s0')
esc(¶ma);
return 0;
}
int main() {
return fun(5, 20);
}
1. parama is escaped by esc(¶ma) so it is not promoted by
SROA/mem2reg (failing condition "A" above).
2. InstCombine's LowerDbgDeclare converts the dbg.declare to a set of
dbg.values (tracking the stored SSA values).
3. InstCombine replaces the two stores to parama's alloca (the initial
parameter register store in entry and the assignment in if.then) with a
PHI+store in the common sucessor.
4. SimplifyCFG folds the blocks together and converts the PHI to a
select.
The debug info is not updated to account for the merged value in the successor
prior to SimplifyCFG when it exists as a PHI, or during when it becomes a
select.
As with D89543, which added some dexter tests for escaped locals, the idea is
to build a set of source-level tests which highlights existing issues and
might be useful in evaluating a new debug info model.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D94761
This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.
Differential Revision: https://reviews.llvm.org/D92435
Adds visual studio debugger support to dexter via option --debugger vs2019
Differential Revision: https://reviews.llvm.org/D89803
Author: Nabeel Omer <nabeel.omer@sony.com>
both deferred_globals.cpp namespace.cpp require lldb in order to run and will
fail if it's not available.
add the required lines to the top of the tests.
deferred_globals.cpp: Verify that debug information for a local variable does
not hide a global definition that has the same name
namespace.cpp: Ensure that the debug information for a global variable
includes namespace information.
Differential Revision: https://reviews.llvm.org/D89462
Author: Nabeel Omer <nabeel.omer@sony.com>
Recently there has been renewed interest in improving debug-info for variables
that (partially or otherwise) live on the stack in optimised code.
At the moment instcombine speculates that stack slots are probably going to be
promoted to registers, and prepares the debug-info accordingly. It runs a
function called LowerDbgDeclare which converts dbg.declares to a set of
dbg.values after loads, and before stores and calls. Sometimes the stack
location remains (e.g. for escaped locals). If any dbg.values become undef
where the stack location is still valid we end up unnecessarily reducing
variable location coverage due to our inability to track multiple locations
simultaneously. There is a flag to disable this feature
(-instcombine-lower-dbg-declare=0), which prevents this conversion at the cost
of sometimes providing incorrect location info in the face of DSE, DCE, GVN,
CSE etc.
This has been discussed fairly extensively on PR34136.
The idea of these tests is to provide examples of situations that we should
consider when designing a new system, to aid discussions and eventually help
evaluate the implementation.
Dexter isn't ideal for observing specific optimisation behaviour. Writing an
exaustive test suite would be difficult, and the resultant suite would be
fragile. However, I think having some concrete executable examples is useful
at least as a reference.
Differential Revision: https://reviews.llvm.org/D89543
NFC patch simply updates the commands.md documentation contents with missing
links to the DexLimitSteps and DexLabel command documentation.
Differential Revision: https://reviews.llvm.org/D89689
Author: Nabeel Omer <nabeel.omer@sony.com>
This is the first bit from D73546. Primarily setting up the corresponding test. Will add more pretty printers in a separate revision.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D86937
Tom Weaver