Previously you got:
AssertionError: False is not True : Emulation test succeeded.
Which is a bit of a head scratcher. The message is used when
the test fails, not when it succeeds.
This patch adds support for evaluating expressions which reference
a captured `this` from within the context of a C++ lambda expression.
Currently LLDB doesn't provide Clang with enough information to
determine that we're inside a lambda expression and are allowed to
access variables on a captured `this`; instead Clang simply fails
to parse the expression.
There are two problems to solve here:
1. Make sure `clang::Sema` doesn't reject the expression due to an
illegal member access.
2. Materialize all the captured variables/member variables required
to evaluate the expression.
To address (1), we currently import the outer structure's AST context
onto `$__lldb_class`, making the `contextClass` and the `NamingClass`
match, a requirement by `clang::Sema::BuildPossibleImplicitMemberExpr`.
To address (2), we inject all captured variables as locals into the
expression source code.
**Testing**
* Added API test
This is required in preparation for the follow-up patch which adds
support for evaluating expressions from within C++ lambdas. In such
cases we need to materialize variables which are not part of the
current frame but instead are ivars on a 'this' pointer of the current
frame.
Update the process ID after handling fork/vfork to ensure that
the process plugin reports the correct PID immediately.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D130037
`IntegerLiteral::Create` operates on integer types. For that reason
when we parse DWARF into an AST, when we encounter a constant
initialized enum member variable, we try to determine the underlying
integer type before creating the `IntegerLiteral`. However, we
currently don't desugar the type and for enum typedefs
`dyn_cast<EnumType>` fails. In debug builds this triggers following
assert:
```
Assertion failed: (type->isIntegerType() && "Illegal type in IntegerLiteral"), function IntegerLiteral, file Expr.cpp, line 892
```
This patch turns the `dyn_cast<EnumType>` into a `getAs<EnumType>`
which `dyn_cast`s the canonical type, allowing us to get to the
underlying integer type.
**Testing**
* API test
* Manual repro is fixed
Differential Revision: https://reviews.llvm.org/D130213
This patch adds support for formatting `std::map::const_iterator`.
It's just a matter of adding `const_` to the existing regex.
**Testing**
* Added test case to existing API tests
Differential Revision: https://reviews.llvm.org/D129962
This reverts commit 5778ada8e5.
The watchpoint tests all stall on aarch64-ubuntu bots. Reverting till I can
get my hands on an system to test this out.
We were just emitting "invalid module" w/o saying which module. That's
not particularly helpful.
Differential Revision: https://reviews.llvm.org/D129338
Since we want to present the "new & old" values for watchpoint hits, on architectures,
including the ARM family, that stop before the triggering instruction is run, we need
to single step over the instruction before stopping for realz. This was incorrectly
done directly in the StopInfoWatchpoint::ShouldStop. That causes problems if more than
one thread stops "for a reason" at the same time as the watchpoint, since the other actions
didn't expect the process to make progress in this part of the execution control machinery.
The correct way to do this is to schedule the step over using ThreadPlans, and then to restore
the stop info after that plan stops, so that the rest of the stop info actions can happen when
all the other threads have handled their immediate actions as well.
Differential Revision: https://reviews.llvm.org/D129814
Enable stdio forwarding when nonstop mode is enabled, and disable it
once it is disabled. This makes it possible to cleanly handle stdio
forwarding while running multiple processes in non-stop mode.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128932
Stop all processes and clear notification queues when disabling non-stop
mode. Ensure that no stop notifications are sent for processes stopped
due to the mode switch.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128893
Fix the response to `?` packet for threads that are running at the time
(in non-stop mode). The previous code would wrongly send or queue
an empty response for them.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128879
Introduce a new %Stdio notification category and use it to send process
output asynchronously when running in non-stop mode. This is an LLDB
extension since GDB does not use the 'O' packet for process output,
just for replies to 'qRcmd' packets.
Using the async notification mechanism implies that only the first
output packet is sent immediately to the client. The client needs
to request subsequent notifications (if any) using the new vStdio packet
(that works pretty much like vStopped for the Stop notification queue).
The packet handler in lldb-server tests is updated to handle the async
stdio packets in addition to the regular O packets. However, due
to the implications noted above, it can only handle the first output
packet sent by the server. Subsequent packets need to be explicitly
requested via vStdio.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128849
Improve handling of multiple successive continue packets in non-stop
mode. More specifically:
1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.
2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.
With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710
Improve handling of multiple successive continue packets in non-stop
mode. More specifically:
1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.
2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.
With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710
Reland 486787210d which broke tests on Arm and Windows.
* Windows -- on Windows const static data members with no out-of-class
definition do have valid addresses, in constract to other platforms
(Linux, macos) where they don't. Adjusted the test to expect success
on Windows and failure on other platforms.
* Arm -- `int128` is not available on 32-bit ARM, so disable the test
for this architecture.
Print the enum values and their description in the help output for
argument values. Until now, there was no way to get these values and
their description.
Example output:
(lldb) help <description-verbosity>
<description-verbosity> -- How verbose the output of 'po' should be.
compact : Only show the description string
full : Show the full output, including persistent variable's
name and type
Differential revision: https://reviews.llvm.org/D129707
This adds support for using const static integral data members as described by C++11 [class.static.data]p3
to LLDB's expression evaluator.
So far LLDB treated these data members are normal static variables. They already work as intended when they are declared in the class definition and then defined in a namespace scope. However, if they are declared and initialised in the class definition but never defined in a namespace scope, all LLDB expressions that use them will fail to link when LLDB can't find the respective symbol for the variable.
The reason for this is that the data members which are only declared in the class are not emitted into any object file so LLDB can never resolve them. Expressions that use these variables are expected to directly use their constant value if possible. Clang can do this for us during codegen, but it requires that we add the constant value to the VarDecl we generate for these data members.
This patch implements this by:
* parsing the constant values from the debug info and adding it to variable declarations we encounter.
* ensuring that LLDB doesn't implicitly try to take the address of expressions that might be an lvalue that points to such a special data member.
The second change is caused by LLDB's way of storing lvalues in the expression parser. When LLDB parses an expression, it tries to keep the result around via two mechanisms:
1. For lvalues, LLDB generates a static pointer variable and stores the address of the last expression in it: `T *$__lldb_expr_result_ptr = &LastExpression`
2. For everything else, LLDB generates a static variable of the same type as the last expression and then direct initialises that variable: `T $__lldb_expr_result(LastExpression)`
If we try to print a special const static data member via something like `expr Class::Member`, then LLDB will try to take the address of this expression as it's an lvalue. This means LLDB will try to take the address of the variable which causes that Clang can't replace the use with the constant value. There isn't any good way to detect this case (as there a lot of different expressions that could yield an lvalue that points to such a data member), so this patch also changes that we only use the first way of capturing the result if the last expression does not have a type that could potentially indicate it's coming from such a special data member.
This change shouldn't break most workflows for users. The only observable side effect I could find is that the implicit persistent result variables for const int's now have their own memory address:
Before this change:
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x00007ffeefbff8e8
(lldb) p &i
(const int *) $2 = 0x00007ffeefbff8e8
```
After this change we capture `i` by value so it has its own value.
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x0000000100155320
(lldb) p &i
(const int *) $2 = 0x00007ffeefbff8e8
```
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D81471
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
[This patch was reverted after causing a testsuite failure on a CI bot;
I haven't been able to repro the failure outside the CI, but I have a
theory that my sanity check on cputype which only matched arm64 and
x86_64 - and the CI machine may have a watch simulator that is still
using i386.]
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
Add `pcm-info` to the `target module dump` subcommands.
This dump command shows information about clang .pcm files. This command
effectively runs `clang -module-file-info` and produces identical output.
The .pcm file format is tightly coupled to the clang version. The clang
embedded in lldb is not guaranteed to match the version of the clang executable
available on the local system.
There have been times when I've needed to view the details about a .pcm file
produced by lldb's embedded clang, but because the clang executable was a
slightly different version, the `-module-file-info` invocation failed. With
this command, users can inspect .pcm files generated by lldb too.
Differential Revision: https://reviews.llvm.org/D129456
Thanks to ymeng@fb.com for coming up with this change.
`thread trace dump info` can dump some metrics that can be useful for
analyzing the performance and quality of a trace. This diff adds a --json
option for dumping this information in json format that can be easily
understood my machines.
Differential Revision: https://reviews.llvm.org/D129332
Thanks to fredzhou@fb.com for coming up with this feature.
When tracing in per-cpu mode, we have information of in which cpu we are execution each instruction, which comes from the context switch trace. This diff makes this information available as a `cpu changed event`, which an additional accessor in the cursor `GetCPU()`. As cpu changes are very infrequent, any consumer should listen to cpu change events instead of querying the actual cpu of a trace item. Once a cpu change event is seen, the consumer can invoke GetCPU() to get that information. Also, it's possible to invoke GetCPU() on an arbitrary instruction item, which will return the last cpu seen. However, this call is O(logn) and should be used sparingly.
Manually tested with a sample program that starts on cpu 52, then goes to 18, and then goes back to 52.
Differential Revision: https://reviews.llvm.org/D129340
A trace bundle contains many trace files, and, in the case of intel pt, the
largest files are often the context switch traces because they are not
compressed by default. As a way to improve this, I'm adding a --compact option
to the `trace save` command that filters out unwanted processes from the
context switch traces. Eventually we can do the same for intel pt traces as
well.
Differential Revision: https://reviews.llvm.org/D129239
Thanks to rnofenko@fb.com for coming up with these changes.
This diff adds support for passing units in the trace size inputs. For example,
it's now possible to specify 64KB as the trace size, instead of the
problematic 65536. This makes the user experience a bit friendlier.
Differential Revision: https://reviews.llvm.org/D129613
This patch fixes TestThreadAPI for AArch64 windows by switching over to
PDB debug info instead of DWARF. This is needed to step over library
functions like printf as there is debug info mismatch between DWARF and
PDB. PDB DWARF interworking is not fully supported by LLDB at the
moment.
This patch fixes marks TestLoadUnload.test_static_init_during_load as
xfail for AArch64 windows. It is failing similar to Linux and already
marked xfail for linux.
This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb.
Reviewed By: clayborg, JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D128069
This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb.
Reviewed By: clayborg, JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D128069
This patch adds a formatter for libcxx's `std::unordered_map` iterators.
The implementation follows a similar appraoch to the `std::map` iterator
formatter. I was hesistant about coupling the two into a common
implementation since the libcxx layouts might change for one of the
the containers but not the other.
All `std::unordered_map` iterators are covered with this patch:
1. const/non-const key/value iterators
2. const/non-const bucket iterators
Note that, we currently don't have a formatter for `std::unordered_map`.
This patch doesn't change that, we merely add support for its iterators,
because that's what Xcode users requested. One can still see contents
of `std::unordered_map`, whereas with iterators it's less ergonomic.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D129364
Make sure we use the libc++ from the build dir. Currently, by passing
-stdlib=libc++, we might pick up the system libc++. This change ensures
that if LLVM_LIBS_DIR is set, we try to use the libc++ from there.
Differential revision: https://reviews.llvm.org/D129166
Summary:
This is an essential piece of infrastructure for us to be
continuously testing debug info with BOLT. We can't only make changes
to a test repo because we need to change debuginfo tests to call BOLT,
hence, this diff needs to sit in our opensource repo. But when upstreaming
to LLVM, this should be kept BOLT-only outside of LLVM. When upstreaming,
we need to git diff and check all folders that are being modified by our
commits and discard this one (and leave as an internal diff).
To test BOLT in debuginfo tests, configure it with -DLLVM_TEST_BOLT=ON.
Then run check-lldb and check-debuginfo.
Manual rebase conflict history:
https://phabricator.intern.facebook.com/D29205224https://phabricator.intern.facebook.com/D29564078https://phabricator.intern.facebook.com/D33289118https://phabricator.intern.facebook.com/D34957174
Test Plan:
tested locally
Configured with:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;compiler-rt;bolt;debuginfo-tests"
-DLLVM_TEST_BOLT=ON
Ran test suite with:
ninja check-debuginfo
ninja check-lldb
Reviewers: #llvm-bolt
Subscribers: ayermolo, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D35317341
Tasks: T92898286
Perform a major refactoring of vCont-threads tests in order to attempt
to improve their stability and performance.
Split test_vCont_run_subset_of_threads() into smaller test cases,
and split the whole suite into two files: one for signal-related tests,
the running-subset-of tests.
Eliminate output_match checks entirely, as they are fragile to
fragmentation of output. Instead, for the initial thread list capture
raise an explicit SIGINT from inside the test program, and for
the remaining output let the test program run until exit, and check all
the captured output afterwards.
For resume tests, capture the LLDB's thread view before and after
starting new threads in order to determine the IDs corresponding
to subthreads rather than relying on program output for that.
Add a mutex for output to guarantee serialization. A barrier is used
to guarantee that all threads start before SIGINT, and an atomic bool
is used to delay prints from happening until after SIGINT.
Call std::this_thread::yield() to reduce the risk of one of the threads
not being run.
This fixes the test hangs on FreeBSD. Hopefully, it will also fix all
the flakiness on buildbots.
Thanks to Pavel Labath for figuring out why the original version did not
work on Debian.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D129012
The requirements for "thread until <line number>" are:
a) If any code contributed by <line number> or the nearest subsequent of <line number> is executed before leaving the function, stop
b) If you end up leaving the function w/o triggering (a), then stop
In case of (a), since the <line number> may have multiple entries in the line table and the compiler might have scheduled/moved the relevant code across, and the lldb does not know the control flow, set breakpoints on all the line table entries of best match of <line number> i.e. exact or the nearest subsequent line.
Along with the above, currently, CommandObjectThreadUntil is also setting the breakpoints on all the subsequent line numbers after the best match and this latter part is wrong.
This issue is discussed at http://lists.llvm.org/pipermail/lldb-dev/2018-August/013979.html.
In fact, currently `TestStepUntil.py` is not actually testing step until scenarios and `test_missing_one` test fails without this patch if tests are made to run. Fixed the test as well.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D50304
Using SIGSTOP means that if anything goes wrong in the test, the process
can end up in the stopped state, where it is not running, but still
taking up resources. Eventually, these "zombies" can make the machine
completely unusable. Instead, use a signal whose default action is to
kill the processes.
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
This would fail with an overly naive approach to simple template
name (clang's -gsimple-template-names) since the names wouldn't be
unique per specialization, creating ambiguity/chance that a query for
one specialization would find another.
Improve the error message when we fail to hit the initial breakpoint in
run_to_breakpoint_do_run. In addition to the process state, we now also
report the exit code and reason (if the process exited) as well as the
inferior's output.
Differential revision: https://reviews.llvm.org/D111978
Perform a major refactoring of vCont-threads tests in order to attempt
to improve their stability and performance.
Split test_vCont_run_subset_of_threads() into smaller test cases,
and split the whole suite into two files: one for signal-related tests,
the running-subset-of tests.
Eliminate output_match checks entirely, as they are fragile to
fragmentation of output. Instead, for the initial thread list capture
raise an explicit SIGSTOP from inside the test program, and for
the remaining output let the test program run until exit, and check all
the captured output afterwards.
For resume tests, capture the LLDB's thread view before and after
starting new threads in order to determine the IDs corresponding
to subthreads rather than relying on program output for that.
Add a mutex for output to guarantee serialization. A barrier is used
to guarantee that all threads start before SIGSTOP, and an atomic bool
is used to delay prints from happening until after SIGSTOP.
Call std::this_thread::yield() to reduce the risk of one of the threads
not being run.
This fixes the test hangs on FreeBSD. Hopefully, it will also fix all
the flakiness on buildbots.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D129012
Previously we recorded AllocationBase as the base address of the region
we get from VirtualQueryEx. However, this is the base of the allocation,
which can later be split into more regions.
So you got stuff like:
[0x00007fff377c0000-0x00007fff377c1000) r-- PECOFF header
[0x00007fff377c0000-0x00007fff37840000) r-x .text
[0x00007fff377c0000-0x00007fff37870000) r-- .rdata
Where all the base addresses were the same.
Instead, use BaseAddress as the base of the region. So we get:
[0x00007fff377c0000-0x00007fff377c1000) r-- PECOFF header
[0x00007fff377c1000-0x00007fff37840000) r-x .text
[0x00007fff37840000-0x00007fff37870000) r-- .rdata
https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-memory_basic_information
The added test checks for any overlapping regions which means
if we get the base or size wrong it'll fail. This logic
applies to any OS so the test isn't restricted to Windows.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129272
After 82ba3f4, we (again) need to call lldb_enable_attach to be able to
attach to processes on linux. This was a new test, so it does not have
the necessary boilerplate.
This recommits b15b1421, which reverted in was reverted in f51c47d98 due to
failures on apple systems. The problem was that the patch introduced a race
where the debug server could start the attach process before the first process
(which isn't supposed to be attached to) was set up. This caused us to attach
to the wrong process.
The new version introduces additional synchronization to ensure that does not
happen.
Original commit message was:
As the documentation states, using this is not safe in multithreaded
programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program
from the very first instruction, where our usual mechanism of
synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test
(TestGdbRemoteAttachWait) so instead of doing this everywhere, I create
a bespoke solution for that single test. The solution basically
consists of outsourcing the preexec_fn code to a separate (and
single-threaded) shim process, which enables attaching and then executes
the real program.
This pattern could be generalized in case we needed to use it for other
tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit
a997a1d7fb.
This is a follow up on my last commit where one of the decorator was
left unremoved.
This patch removes Xfail decorator from TestLoadUnload.py as it is now
passing on Arm/Linux buildbot.
This test has some race condition which is making it hang on LLDB
Arm/AArch64 Linux buildbot. I am marking it as skipped until we
investigate whats going wrong.
As the documentation states, using this is not safe in multithreaded
programs, and I have traced it to a rare deadlock in some of the tests.
The reason this was introduced was to be able to attach to a program
from the very first instruction, where our usual mechanism of
synchronization -- waiting for a file to appear -- does not work.
However, this is only needed for a single test
(TestGdbRemoteAttachWait) so instead of doing this everywhere, I create
a bespoke solution for that single test. The solution basically
consists of outsourcing the preexec_fn code to a separate (and
single-threaded) shim process, which enables attaching and then executes
the real program.
This pattern could be generalized in case we needed to use it for other
tests, but I suspect that we will not be having many tests like this.
This effectively reverts commit
a997a1d7fb.
LLDB fails to step in/out/over code with missing debug information.
This is only reproducible on AArch64/Windows. I have reported a issue
upstream at llvm.org/pr56292
This patch Xfail TestStepNoDebug.py for AArch64/Windows.
Checking whether a formatter change does not break some of the supported
string layouts is difficult because it requires tracking down and/or
building different versions and build configurations of the library.
The purpose of this patch is to avoid that by providing an in-tree
simulation of the string class. It is a reduced version of the real
string class, obtained by elimitating all non-trivial code, leaving
just the internal data structures used by the data formatter. Different
versions of the class can be simulated through preprocessor defines.
The test (ab)uses the fact that our formatters kick in for any
double-underscore sub-namespace of `std`, so it avoids colliding with
the real string class by declaring the test class in the std::__lldb
namespace.
I do not consider this to be a replacement for the existing data
formatter tests, as producing this kind of a test is not trivial, and it
is easy to make a mistake in the process. However, it's also not
realistic to expect that every person changing the data formatter will
test it against all versions of the real class, so I think it can be
useful as a first line of defence.
Adding support for new layouts can become particularly unwieldy, but
this complexity will also be reflected in the actual code, so if we find
ourselves needing to support too many variants, we may need to start
dropping support for old ones, or come up with a completely different
strategy.
Differential Revision: https://reviews.llvm.org/D124155
not to be hit. But another thread might be hit at the same time and
actually stop. So we have to be sure to switch the first thread's
stop info to eStopReasonNone or we'll report a hit when the condition
failed, which is confusing.
Differential Revision: https://reviews.llvm.org/D128776
TestObjCXXBridgedPO is broken on macOS Ventura (but not on macOS
Monterey). I took a look but it doesn't seem trivial. I'm XFAILing the
test until Adrian, who wrote the test, can take a look.
rdar://96224141
TestCommandScript.py fails on Arm/Windows due following issues:
https://llvm.org/pr56288https://llvm.org/pr56292
LLDB fails to skip prologue and also step over library function or
nodebug functions fails due to PDB/DWARF mismatch.
This patch replace function breakpoint with line breakpoint so that we
can expect LLDB to stop on desired line. Also replace dwarf with PDB
debug info for this test only.
This is a follow up to my previous commit where TestSTL.py got broken
due to 9c6e043592.
Now that we force dwarf symbols by default on windows we dont need to
specifically put -gdwarf O0 in debug flags for this test.
TestVSCode_breakpointEvents.py is failing on macOS Ventura because we
receive 3 breakpoint events instead of one. This is likely the result of
dyld moving into the shared cache.
We want to include events with metadata, like context switches, and this
requires the API to handle events with payloads (e.g. information about
such context switches). Besides this, we want to support multiple
similar events between two consecutive instructions, like multiple
context switches. However, the current implementation is not good for this because
we are defining events as bitmask enums associated with specific
instructions. Thus, we need to decouple instructions from events and
make events actual items in the trace, just like instructions and
errors.
- Add accessors in the TraceCursor to know if an item is an event or not
- Modify from the TraceDumper all the way to DecodedThread to support
- Renamed the paused event to disabled.
- Improved the tsc handling logic. I was using an API for getting the tsc from libipt, but that was an overkill that should be used when not processing events manually, but as we are already processing events, we can more easily get the tscs.
event items. Fortunately this simplified many things
- As part of this refactor, I also fixed and long stating issue, which is that some non decoding errors were being inserted in the decoded thread. I changed this so that TraceIntelPT::Decode returns an error if the decoder couldn't be set up proplerly. Then, errors within a trace are actual anomalies found in between instrutions.
All test pass
Differential Revision: https://reviews.llvm.org/D128576
Replace the use of "trap" with a new "stop" command in fork tests,
that maps to `raise(SIGSTOP)`. Since traps do not increment PC on some
architectures (notably ARM), using traps would require special logic
to increment it while testing. Using SIGSTOP avoids the problem
and is probably more logical, given that the purpose of the "trap"s
was to simply stop the inferior at a synchronization point. This fixes
tests on AArch64 (and possibly ARM, I'll update XFAILs when it is
confirmed by the buildbot).
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128780
The DynamicLoaderPOSIXDYLD::GetStepThroughTrampolinePlan() function was
doing the symbol lookup using the demangled name. This stopped working
with https://reviews.llvm.org/D118814. To get things working again, just
use the mangled name for the lookup instead.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D127999
Split the test that's gotten very long in two, in hope that it will
resolve the arm/aarch64 buildbot failures. Even if it does not, it
could help pinpointing where the problem lies.
Sponsored by: The FreeBSD Foundation
Fix lldb-server in the non-stop + multiprocess mode to exit on vStopped
only if all processes have exited, rather than when the first one exits.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128639
Extend the most of baseline fork tests to run in nonstop mode as well.
For more cases, we're just testing one example scenario to save time.
This patch does not cover tests that rely on correct exit handling,
as fixing that is addressed in a followup patch.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128638
This is currently being done in an ad hoc way, and so for some
commands it isn't being checked. We have the info to make this check,
since commands are supposed to add their arguments to the m_arguments
field of the CommandObject. This change uses that info to check whether
the command received arguments in error.
A handful of commands weren't defining their argument types, I also had
to fix them. And a bunch of commands were checking for arguments by
hand, so I removed those checks in favor of the CommandObject one. That
also meant I had to change some tests that were checking for the ad hoc
error outputs.
Differential Revision: https://reviews.llvm.org/D128453
Add a log dump command to dump logs to a file. This only works for
channels that have a log handler associated that supports dumping. For
now that's limited to the circular log handler, but more could be added
in the future.
Differential revision: https://reviews.llvm.org/D128557
Augusto Noronha