Migrate to using ReportError to report a failure to evaluate a
watchpoint condition. I had already done so for the parallel code for
breakpoints.
In the process, I noticed that I accidentally regressed the error
reporting for breakpoint conditions by dropping the call to
GetDescription. This patch rectifies that and adds a test.
Because the call to GetDescription expects a Stream*, I also switches
from using a raw_string_ostream to a StreamString for both breakpoints
and watchpoints.
At first, lli only supported lazy mode for ORC. Greedy mode was added with e1579894d2 and is the default settings now. JITLoaderGDB tests don't rely on laziness, so we can switch them to greedy and remove some complexity.
When executing a script command in HandleCommand(s) we currently print
its output twice
You can see this issue in action when adding a breakpoint command:
(lldb) b main
Breakpoint 1: where = main.out`main + 13 at main.cpp:2:3, address = 0x0000000100003fad
(lldb) break command add 1 -o "script print(\"Hey!\")"
(lldb) r
Process 76041 launched: '/tmp/main.out' (x86_64)
Hey!
(lldb) script print("Hey!")
Hey!
Process 76041 stopped
The issue is caused by HandleCommands using a temporary
CommandReturnObject and one of the commands (`script` in this case)
setting an immediate output stream. This causes the result to be printed
twice: once directly to the immediate output stream and once when
printing the result of HandleCommands.
This patch fixes the issue by introducing a new option to suppress
immediate output for temporary CommandReturnObjects.
Differential revision: https://reviews.llvm.org/D103349
LLVM OrcJIT is shifting from RuntimeDyld to JITLink. Starting with D96627 I am planning to add debug support. It would be great to have test coverage for it in LLDB early on.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D96634
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.
The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D90769
causing the -D option for breakpoint set command to be incorrectly parsed.
Patch by Martin Svensson.
Differential Revision: https://reviews.llvm.org/D69425
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
Jonas Devlieghere