Using invalidated vector iterator is at best a UB and could crash depending on STL implementation.
Fixing via minimal changes to preserve the existing code style.
Coverity warning 1454828 (scan.coverity.com)
Differential Revision: https://reviews.llvm.org/D130312
Extract a bit of copy/pasted regex filtering logic into a separate
function and simplify it a little bit.
Differential Revision: https://reviews.llvm.org/D130219
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.
This reverts commit 555ae5b8f5.
Apparently, there's something different about how Linux ARM handles watchpoints,
as all the watchpoint tests seem to stall on the Ubuntu aarch64 bots.
Reverting till I can get my hands on a linux system and see what is
wrong.
That was causing hit counts to be double-counted on x86_64 Linux.
It looks like StopInfoWatchpoint::ShouldStopSynchronous gets called
twice for a give stop on Linux (not on Darwin). I had taken out the
"have I been called already" check when I reworked this part of the
code because it didn't seem necessary. Putting that back in because
it looks like it is on some systems.
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
Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:
- We guarantee that two options that use the same argument type have
the same accepted values.
- We can print the enum values and their description in the help
output. (D129707)
Differential revision: https://reviews.llvm.org/D129703
Remove m_inferior_prev_state that's not suitable for multiprocess
debugging and that does not seem to be really used at all.
The only use of the variable right now is to "prevent" sending the stop
reason after attach/launch. However, this code is never actually run
since none of the process plugins actually use eStateLaunching or
eStateAttaching. Through adding an assert, I've confirmed that it's
never hit in any of the LLDB tests or while attaching/launching debugged
process via lldb-server and via lldb CLI.
Differential Revision: https://reviews.llvm.org/D128878
Sponsored by: The FreeBSD Foundation
clang 14 removed -gz=zlib-gnu support and ld.lld/llvm-objcopy removed zlib-gnu
support recently. Remove lldb support by migrating away from
llvm::object::Decompressor::isCompressedELFSection.
The API has another user llvm-dwp, so it is not removed in this patch.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129724
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
Convert the m_debugged_processes map from NativeProcessProtocol pointers
to structs, and combine the additional set(s) holding the additional
process properties into a flag field inside this struct. This is
desirable since there are more properties to come and having a single
structure with all information should be cleaner and more efficient than
using multiple sets for that.
Suggested by Pavel Labath in D128893.
Differential Revision: https://reviews.llvm.org/D129652
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
It's more natural to use uint8_t * (std::byte needs C++17 and llvm has
too much uint8_t *) and most callers use uint8_t * instead of char *.
The functions are recently moved into `llvm::compression::zlib::`, so
downstream projects need to make adaption anyway.
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
It turns out that cgroup filtering is relatively trivial and works
really nicely. Thid diffs adds automatic cgroup filtering when in
per-cpu mode, unless a new --disable-cgroup-filtering flag is passed in
the start command. At least on Meta machines, all processes are spawned
inside a cgroup by default, which comes super handy, because per cpu
tracing is now much more precise.
A manual test gave me this result
- Without filtering:
Total number of trace items: 36083
Total number of continuous executions found: 229
Number of continuous executions for this thread: 2
Total number of PSB blocks found: 98
Number of PSB blocks for this thread 2
Total number of unattributed PSB blocks found: 38
- With filtering:
Total number of trace items: 87756
Total number of continuous executions found: 123
Number of continuous executions for this thread: 2
Total number of PSB blocks found: 10
Number of PSB blocks for this thread 3
Total number of unattributed PSB blocks found: 2
Filtering gives us great results. The number of instructions collected
more than double (probalby because we have less noise in the trace), and
we have much less unattributed PSBs blocks and unrelated PSBs in
general. The ones that are unrelated probably belong to other processes
in the same cgroup.
Differential Revision: https://reviews.llvm.org/D129257
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
This metric was missing. We were only measuring in per-thread mode, and
this completes the work.
For a sample trace I have, the `dump info` command shows
```
Timing for this thread:
Decoding instructions: 0.12s
```
I also improved a bit the TaskTime function so that callers don't need to
specify the template argument
Differential Revision: https://reviews.llvm.org/D129249
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 TestConvenienceVariables.test for AArch64 Windows.
Clang/LLD was unable to find printf apparently available as a macro
definition in stdio.h.
