Commit Graph

220 Commits

Author SHA1 Message Date
Walter Erquinigo acfee72a05 Another attempt of D77452 - da0e91fee6
[intel-pt] Improve the way the test determines whether to run

- Now I'm creating a default value for the new test parameter
- I fixed a small mistake in the skipping logic of the test

... I forgot to clear the cmake cache when testing my diff
2020-04-15 17:52:36 -07:00
Walter Erquinigo f17a85cf36 Revert "[intel-pt] Improve the way the test determines whether to run"
This reverts commit da0e91fee6.

There's a failure in
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/8584
caused by a missing python object.
2020-04-15 16:35:29 -07:00
Walter Erquinigo da0e91fee6 [intel-pt] Improve the way the test determines whether to run
Summary:
@labath raised a concern on the way I was skipping this test. I think that was
fair and I found a better way.
Now I'm skipping if the CMAKE flag LLDB_BUILD_INTEL_PT is false.
I added an enabled_plugins entry in the dotest configuration, which gets
set by lit or lldb-dotest. The only available plugin right now is
'intel-pt', but I imagine it will be useful in the future for other
kinds of plugins that get determined at configuration time. I didn't
want to add a new argument option --enable-intel-pt or something or the
sort, as it wouldn't be useful for other cases.

Reviewers: labath, clayborg

Subscribers: lldb-commits, labath

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77452
2020-04-15 16:03:31 -07:00
Jonas Devlieghere fc41013893 [lldb/Reproducers] Capture reproducers from the API test suite.
Make it possible to capture reproducers from the API test suite. Given
the symmetry between capture and replay, this patch also adds the
necessary code for replay. For now this is a NO-OP until the
corresponding reproducer instrumentation changes land.

For more info please refer to the RFC on lldb-dev:
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html

Differential revision: https://reviews.llvm.org/D77588
2020-04-14 09:24:23 -07:00
Med Ismail Bennani f0be92ebcd [lldb/test] Fix TestLoadUnload
Summary:
[lldb/test] Fix TestLoadUnload failure introduced in e0dbd02513

It seems that `env_cmd_string` is declared and used few lines under this
self.runCmd expression. I guess this is some left-over from an older
version.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Reviewers: labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D78094
2020-04-14 13:53:51 +02:00
Muhammad Omair Javaid 01cfe88a17 [LLDB] Remove xfail aarch64-linux from test_step_over_load*
test_step_over_load_with_svr4 and test_step_over_load now pass on
aarch64 linux.

Fixed by change-id: e0dbd02513

Differential Revision: https://reviews.llvm.org/D77662
2020-04-14 16:21:06 +05:00
Pavel Labath e0dbd02513 [lldb/test] Make TestLoadUnload compatible with windows
Summary:
This patch introduces a header "dylib.h" which can be used in tests to
handle shared libraries semi-portably. The shared library APIs on
windows and posix systems look very different, but their underlying
functionality is relatively similar, so the mapping is not difficult.

It also introduces two new macros to wrap the functinality necessary to
export/import function across the dll boundary on windows. Previously we
had the LLDB_TEST_API macro for this purpose, which automagically
changed meaning depending on whether we were building the shared library
or the executable. While convenient for simple cases, this approach was
not sufficient for the more complicated setups where one deals with
multiple shared libraries.

Lastly it rewrites TestLoadUnload, to make use of the new APIs. The
trickiest aspect there is the handling of DYLD_LIBRARY_PATH on macos --
previously setting this variable was not needed as the test used
@executable_path-relative dlopens, but the new generic api does not
support that. Other systems do not support such dlopens either so the
test already contained support for setting the appropriate path
variable, and this patch just makes that logic more generic. In doesn't
seem that the purpose of this test was to exercise @executable_path
imports, so this should not be a problem.

These changes are sufficient to make some of the TestLoadUnload tests
pass on windows. Two other tests will start to pass once D77287 lands.

Reviewers: amccarth, jingham, JDevlieghere, compnerd

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77662
2020-04-14 11:10:59 +02:00
Muhammad Omair Javaid 29bb046fe9 [LLDB] Remove xfail aarch64/linux from TestThreadPlanCommands.py 2020-04-13 14:30:50 +05:00
Jim Ingham aa4b37b2ac Convert the ThreadPlanCommands test to use a scripted plan
that pushes a step over plan.  Relax the listing checker
so it will look past any entries after the ones listed in
the input patterns.  Then for the internal plans just check
for the StepOver plan that our scripted plan pushes, and look past
any others.

This should make the test more robust on systems that don't use the
step-in then push a step-out plan to step over a function.
2020-04-10 18:15:03 -07:00
Raphael Isemann 02d152bb1b [lldb] Make some asserts in TestFixIts more expressive 2020-04-10 19:16:33 +02:00
Raphael Isemann a0c6ebd58f [lldb] Refactor TestFixIts so that most of it can run on aarch64-linux
The final function call to `test_X` is failing on aarch64-linux with SIGILL.
Function calls to previous expressions seem to just not work on aarch64-linux
but I don't see another way to test the multiple-run Fix-Its.

This patch refactors the test that the skipIf for aarch64 Linux only covers
the part of the test that was added D77214.
2020-04-10 13:38:45 +02:00
Shu Anzai 1d3b7370c4 [lldb] Fixing the bug that the "log timer" has no tab completion
I fixed the bug that the "log timer" has no tab command.

Original code has the only CommandObjectLogTimer class, but it is not
sufficient. Thus I divided the content of CommandObjectLog class into
CommandObjectLogEnable class, CommandObjectLogDisable class,
CommandObjectLogDump class, CommandObjectLogReset class,
CommandObjectLogIncrement class.

Reviewed by: teemperor

Differential Revision: https://reviews.llvm.org/D76906
2020-04-09 08:58:52 +02:00
Walter Erquinigo 8e40987e18 Fix e796c77b26
Failure:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/14556/testReport/junit/lldb-api/tools_lldb-vscode_breakpoint-events/TestVSCode_breakpointEvents_py/

Diff:
[lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request
https://reviews.llvm.org/D76968

It failed a test TestVSCode_breakpointEvents that only runs Darwin that needed to be updated to match the current logic.
The change is simple.
2020-04-08 10:48:01 -07:00
Walter Erquinigo e796c77b26 [lldb-vscode] Correctly return source mapped breakpoints for setBreakpoints request
Summary:
When using source maps for a breakpoint, in order to find the actual source that breakpoint has resolved, we
need to use a query similar to what CommandObjectSource::DumpLinesInSymbolContexts does, which is the logic
used by the CLI to display the source line at a given breakpoint. That's necessary because from a breakpoint
location you only have an address, which points to the original source location, not the source mapped one.

in the setBreakpoints request handler, we haven't been doing such query and we were returning the original
source location, which was breaking the UX of VSCode, as many breakpoints were being set but not displayed
in the source file next to each line. Besides, clicking the source path of a breakpoint in the breakpoints
view in the debug tab was not working for this case, as VSCode was trying to open a non-existent file, thus
showing an error to the user.

Ideally, we should do the query mentioned above to find the actual source location to respond to the IDE,
however, that query is expensive and users can have an arbitrary number of breakpoints set. As a simpler fix,
the request sent by VSCode already contains the full source path, which exists because the user set it from
the IDE itself, so we can simply reuse it instead of querying from the SB API.

I wrote a test for this, and found out that I had to move SetSourceMapFromArguments after RunInitCommands in
lldb-vscode.cpp, because an init command used in all tests is `settings clear -all`, which would clear the
source map unless specified after initCommands. And in any case, I think it makes sense to have initCommands
run before anything the debugger would do.

Reviewers: clayborg, kusmour, labath, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D76968
2020-04-08 09:52:59 -07:00
Muhammad Omair Javaid e609fe68b2 Revert "[lldb-server] jThreadsInfo returns stack memory"
This reverts commit a53bf9b7c8.
2020-04-07 17:11:22 +05:00
Muhammad Omair Javaid 2a436a07ae Mark TestFixIts.py xfail for LLDB AArch64/Linux 2020-04-07 17:11:22 +05:00
Fred Riss 06ea05a3fb [lldb/test] Fix TestDSYMSourcePathRemapping in the presence of symlnks
My main work directory is on a separate partition, but I usually access
it through a symlink in my home directory. When running the tests,
either Clang or make resolves the symlink, and the real path of the
test directory ends up in the debug information.

This confuses this test as LLDB is trying to remap the real path, but
the remapping description uses the path with the symlink in
it. Calling realpath on the source path when constructing the
remapping description fixes it.
2020-04-06 19:50:34 -07:00
Jonas Devlieghere 1b7560b877 [lldb/Test] Enable TestGdbRemoteThreadsInfoMemory.py on Windows.
This test is currently XFAILed but is passing on the Windows bot.
2020-04-06 14:29:09 -07:00
Jason Molenda 836534f997 Add more detailed symbol type categorization, based on a swift patch by
Greg Clayton a few years ago.

My patch to augment the symbol table in Mach-O files with the
dyld trie exports data structure only categorized symbols as code
or data, but Greg Clayton had a patch to do something similar to
swift a few years ago that had a more extensive categorization of
symbols, as well as extracting some objc class/ivar names from the
entries. This patch is basically just Greg's, updated a bit and
with a test case added to it.

<rdar://problem/50791451>

Differential Revision: https://reviews.llvm.org/D77369
2020-04-06 14:05:33 -07:00
Kazuaki Ishizaki e9264b746b [lldb] NFC: Fix trivial typo in comments, documents, and messages
Differential Revision: https://reviews.llvm.org/D77460
2020-04-07 01:06:16 +09:00
Jaroslav Sevcik a53bf9b7c8 [lldb-server] jThreadsInfo returns stack memory
This patch adds parts of the stack that should be useful for unwinding
to the jThreadsInfo reply from lldb-server. We return the top of the
stack (12 words), and we also try to walk the frame pointer linked list
and return the memory containing frame pointer and return address pairs.
The idea is to cover the cases with and without frame pointer omission.

Differential Revision: https://reviews.llvm.org/D74398
2020-04-06 15:43:19 +02:00
Raphael Isemann 203a8adb65 [lldb] Add option to retry Fix-Its multiple times to failed expressions
Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.

This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).

The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.

Reviewers: jingham, JDevlieghere, friss, shafik

Reviewed By: shafik

Subscribers: shafik, abidh

Differential Revision: https://reviews.llvm.org/D77214
2020-04-06 11:25:36 +02:00
Raphael Isemann 3c2dc28d81 [lldb] Also apply Fix-Its in "note:" diagnostics that belong to an error diagnostic
Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error". Fix-Its connected to warnings and other severities are supposed to
be ignored as LLDB doesn't seem to trust Clang Fix-Its in these situations.

However, LLDB also ignores all Fix-Its coming from "note:" diagnostics. These diagnostics
are usually emitted alongside other diagnostics (both warnings and errors), either to keep
a single diagnostic message shorter or because the Fix-It is in a different source line. As they
are technically their own (non-error) diagnostics, we currently are ignoring all Fix-Its associated with them.

For example, this is a possible Clang diagnostic with a Fix-It that is currently ignored:
```
error: <user expression 1>:2:10: too many arguments provided to function-like macro invocation
ToStr(0, {,})
         ^
<user expression 1>:1:9: macro 'ToStr' defined here
#define ToStr(x) #x
        ^
<user expression 1>:2:1: cannot use initializer list at the beginning of a macro argument
ToStr(0, {,})
^        ~~~~
```

We also don't store "note:" diagnostics at all, as LLDB's abstraction around the whole diagnostic
concept doesn't have such a concept. The text of "note:" diagnostics is instead
appended to the last non-note diagnostic (which is causing that there is no "note:" text in the
diagnostic above, as all the "note:" diagnostics have been appended to the first "error: ..." text).

This patch fixes the ignored Fix-Its in note-diagnostics by appending them to the last non-note
diagnostic, similar to the way we handle the text in these diagnostics.

Reviewers: JDevlieghere, jingham

Reviewed By: JDevlieghere

Subscribers: abidh

Differential Revision: https://reviews.llvm.org/D77055
2020-04-06 10:37:33 +02:00
Pavel Labath 4f644ff9e8 [lldb] XFAIL TestThreadPlanCommands _only_ on aarch64
The test works fine on x86-linux.
2020-04-06 10:36:02 +02:00
Raphael Isemann acb0b99c8e [lldb][NFC] Modernize lang/cpp/scope test 2020-04-06 09:36:54 +02:00
Muhammad Omair Javaid b6cd964ac7 Fix typo in xfail decorator for lldb thread plan list tests 2020-04-05 20:16:46 +05:00
Jim Ingham 3270748127 The thread plan list test is failing at least on Ubuntu Linux.
Mark it expected fail for now.

The test output shows that the "internal" thread listing isn't showing the
step out plan that we use to step back out of a function we're stepping into.
The internal plan listing code has nothing platform specific in it, so that
isn't the problem.

I am pretty sure the difference is that on MacOS we step into the function and then need to
step back out again so we push the internal plan the test is checking for.  But on Linux we
are able to step past the function without stepping into it.

So nothing is actually going wrong here, I just need to find a better test case where I
can ensure we are going to have to push a private plan.  It's probably better to test this
using a custom thread plan, then I can control the state of the plan stack better.

That's for Monday...
2020-04-03 20:06:11 -07:00
Walter Erquinigo ca47ac3d5f [source maps] Fix remove, insert-after and replace
Summary:
In this diff of mine D77186 I introduce a bug in the replace operation, where I was failing fast by mistake.
Besides, a similar problem existed in the insert-after operation, where it was failing fast.

Finally, the remove operation was wrong, as it was not using the indices provided by the users.

I fixed those issues and added some tests account for cases with multiple elements in these requests.

Reviewers: labath, clayborg

Reviewed By: labath

Subscribers: mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77324
2020-04-03 19:15:56 -07:00
Jim Ingham 48ba745eac This test is failing on the Ubuntu bot but the bot log doesn't
capture the test stdout, so put the info I need to see in the error
message instead.
2020-04-03 18:04:02 -07:00
Jim Ingham 2d658c56d5 Disable two new tests on Windows. They are failing but the logs are not helpful.
Also turn on the command trace unconditionally for TestThreadPlanCommands.py as the
tests for the Ubuntu bot don't seem to run with -t making it hard to see why this is
failing remotely.
2020-04-03 17:14:56 -07:00
Jim Ingham 1893065d7b Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin.  To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.

Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.

Differential Revision: https://reviews.llvm.org/D76814
2020-04-03 14:56:28 -07:00
Greg Clayton 5998aceda9 Have lldb-vscode update the currently selecte thread and frame when it receives a "scopes" request.
Summary: The IDE has no packets that are sent to lldb-vscode that say which thread and frame are selected. The only way we know is we get a request for variables for a stack frame via a "scopes" request. When we receive this packet we make that thread and frame the selected thread and frame in lldb. This way when people execute lldb commands in the debug console by prefixing the expression with the backtick character, we will have the right thread and frame selected. Previously this was not updated as new stack frames were selected.

Reviewers: labath, aadsm, wallace, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77347
2020-04-02 18:35:17 -07:00
Walter Erquinigo b78157c88b [intel-pt] Implement a basic test case
* This is a reattempted commit due to a previous builtbot failure

- Now using a env var to determine whether to run the test, as
someone might have built liblldbIntelFeatures.so without intelPT
support, which would make this test fail.

Summary:
Depends on D76872.

There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.

The test is skipped if the Intel PT plugin library is not built.

Reviewers: clayborg, labath, kusmour, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77107
2020-04-02 11:36:05 -07:00
Pavel Labath 62be83463a Recommit "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"
This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.

The original commit message was:

A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.

Reviewers: amccarth, friss

Differential Revision: https://reviews.llvm.org/D76835
2020-04-02 11:52:56 +02:00
Walter Erquinigo 064c634ef3 Revert "[intel-pt] Implement a basic test case"
This reverts commit c911cc6c49.
2020-04-01 14:08:19 -07:00
Walter Erquinigo c911cc6c49 [intel-pt] Implement a basic test case
Summary:
Depends on D76872.

There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.

The test is skipped if the Intel PT plugin library is not built.

Reviewers: clayborg, labath, kusmour, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77107
2020-04-01 13:44:03 -07:00
Walter Erquinigo 8ba8a4a14d Revert "[intel-pt] Implement a basic test case"
This reverts commit f1242ec543.
2020-04-01 13:27:30 -07:00
Walter Erquinigo f1242ec543 [intel-pt] Implement a basic test case
Summary:
Depends on D76872.

There was no test for the Intel PT support on LLDB, so I'm creating one, which
will help making progress on solid grounds.

The test is skipped if the Intel PT plugin library is not built.

Reviewers: clayborg, labath, kusmour, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77107
2020-04-01 13:19:15 -07:00
Walter Erquinigo 30350c2541 [source maps] Ensure all valid source maps are added instead of failing with the first invalid one
Summary:
Several lldb-vscode users have noticed that when a source map rule is invalid (because a folder doesn't exist anymore), the rest of the source maps from their configurations are not applied.
This happens because lldb-vscode executes a single "settings set target.source-map" command with all the source maps and LLDB processes them one by one until one fails.

Instead of doing this, we can process in LLDB all the source map rules and apply the valid ones instead of failing fast.

Reviewers: clayborg, labath, kusmour, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77186
2020-04-01 13:01:40 -07:00
Muhammad Omair Javaid c9d1588054 Silent failing TestWatchpointCount.py aarch64/linux
Skip TestWatchpointCount.py for aarch64-linux to fix lldb aarch64 linux buildbot.

http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/
2020-04-01 16:31:37 +05:00
Raphael Isemann 9beba4245a [lldb][NFC] Modernize TestExprChar 2020-04-01 13:24:21 +02:00
Pavel Labath 0ec88d031a [lldb] Inherit host environment when running shell commands
Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.

Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment.  This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.

Reviewers: jingham, friss

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77123
2020-04-01 11:20:13 +02:00
Raphael Isemann 48a5bdafba [lldb][NFC] Modernize TestXValuePrinting 2020-04-01 10:20:52 +02:00
Raphael Isemann edb0efca1e [lldb][NFC] Modernize call-function tests 2020-04-01 10:17:42 +02:00
Raphael Isemann fa1b602ee6 [lldb][NFC] Modernize TestCallUserAnonTypedef 2020-04-01 10:06:59 +02:00
Raphael Isemann 15f34ff2d8 [lldb] Allow expect_expr without a running target
Summary:
If we don't have a current frame then we can still run many expressions
as long as we have an active target. With this patch `expect_expr` directly
calls the target's EvaluateExpression function when there is no current frame.

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D77197
2020-04-01 09:39:24 +02:00
Davide Italiano 64799fbebd [debugserver/ARM64] Make sure watchpoints hit are attributed correctly.
This didn't happen for arm64 if you have watches for variables
that are contigous in memory.

<rdar://problem/55135006>
2020-03-31 15:56:20 -07:00
Davide Italiano 06bb7df81c Recommit "[lldb] Make Fix-Its also apply to top-level expressions""
This reverts commit fe5cb1c25f as it
 was not responsible for breaking the bots. Sorry.
2020-03-30 14:24:06 -07:00
Davide Italiano 075b610403 Recommit "[lldb] Make TestExprDiagnostics.py pass again after enabling Fix-Its in test"
This reverts commit 55ed09d32e as
it was not responsible for breaking the bots. Sorry.
2020-03-30 14:24:06 -07:00
Davide Italiano 55ed09d32e Revert "[lldb] Make TestExprDiagnostics.py pass again after enabling Fix-Its in test"
This reverts commit 502a06fcda as it
breaks the macOS bots. Raph will take a look and re-commit.
2020-03-30 13:58:18 -07:00