Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
aboutsummaryrefslogtreecommitdiff
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb][NFCI] Refactor regex filtering logic in CommandObjectTypeFormatterListJorge Gorbe Moya2022-07-211-47/+23
| | | | | | | 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
* [lldb] [gdb-remote] Fix process ID after following forked childMichał Górny2022-07-212-3/+23
| | | | | | | | 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
* [lldb/test] Fix flakyness in TestNonStop.test_stdioPavel Labath2022-07-211-13/+12
| | | | | The test was assuming that the output will come in two messages. The truth is that it will come in **at least** two messages.
* [LLDB][ClangExpression] Fix initialization of static enum alias membersMichael Buch2022-07-213-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | `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
* [LLDB][DataFormatter] Add support for std::__map_const_iteratorMichael Buch2022-07-213-2/+17
| | | | | | | | | | | 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
* [LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scanSlava Gurevich2022-07-2030-123/+135
| | | | | | | | | | | | | | | | Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from scan.coverity.com: 1094796 1095721 1095728 1095737 1095741 1095756 1095779 1095789 1095805 1214552 1229457 1232475 1274006 1274010 1293427 1364800 1364802 1364804 1364812 1364816 1374902 1374909 1384975 1399312 1420451 1431704 1454230 1454554 1454615 1454579 1454594 1454832 1457759 1458696 1461909 1467658 1487814 1487830 1487845 Differential Revision: https://reviews.llvm.org/D130098
* Use llvm::is_contained (NFC)Kazu Hirata2022-07-203-10/+4
|
* [LLDB][NativePDB] Add MSInheritanceAttr when creating pointer type that is a ↵Zequan Wu2022-07-193-0/+70
| | | | | | pointer to member. Differential Revision: https://reviews.llvm.org/D129807
* Update docs to note lzfse open source implementationJason Molenda2022-07-191-1/+4
|
* Revert "Make hit point counts reliable for architectures that stop before ↵Jim Ingham2022-07-1815-138/+137
| | | | | | | | | evaluation." This reverts commit 5778ada8e54edb2bc2869505b88a959d1915c02f. The watchpoint tests all stall on aarch64-ubuntu bots. Reverting till I can get my hands on an system to test this out.
* Revert "This is a followup to https://reviews.llvm.org/D129814"Jim Ingham2022-07-181-36/+10
| | | | | | | | | | This reverts commit 555ae5b8f5aa93ab090af853a8b7a83f815b3f20. 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.
* This is a followup to https://reviews.llvm.org/D129814Jim Ingham2022-07-181-10/+36
| | | | | | | | | 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.
* When the module path for `command script import` is invalid, echo the path.Jim Ingham2022-07-182-6/+7
| | | | | | | We were just emitting "invalid module" w/o saying which module. That's not particularly helpful. Differential Revision: https://reviews.llvm.org/D129338
* Make hit point counts reliable for architectures that stop before evaluation.Jim Ingham2022-07-1815-137/+138
| | | | | | | | | | | | | | | 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
* Remove redundant return statements (NFC)Kazu Hirata2022-07-171-1/+1
| | | | Identified with readability-redundant-control-flow.
* Use value instead of getValue (NFC)Kazu Hirata2022-07-1521-78/+76
|
* [lldb] [llgs] Improve stdio forwarding in multiprocess+nonstopMichał Górny2022-07-153-8/+72
| | | | | | | | | 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
* [lldb] [test] Skip test_leave_nonstop on WindowsMichał Górny2022-07-151-0/+1
|
* [lldb] [llgs] Fix disabling non-stop modeMichał Górny2022-07-153-1/+67
| | | | | | | | | 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
* [lldb] [test] Skip test_stop_reason_while_running on WindowsMichał Górny2022-07-151-0/+1
|
* [lldb] [llgs] Fix `?` packet response for running threadsMichał Górny2022-07-152-6/+30
| | | | | | | | | 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
* [lldb] [test] Skip TestNonStop → test_stdio on WindowsMichał Górny2022-07-151-0/+1
|
* [lldb] [llgs] Send process output asynchronously in non-stop modeMichał Górny2022-07-156-39/+91
| | | | | | | | | | | | | | | | | | | | | 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
* [lldb] [test] Skip new NonStop tests on WindowsMichał Górny2022-07-151-0/+3
|
* [lldb][AArch64] Enable int128 testDavid Spickett2022-07-151-1/+1
| | | | | Other 128 bit tests run on AArch64 fine, it's Arm (as in 32 bit Arm) that needs to be skipped.
* Reland "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"Michał Górny2022-07-154-85/+226
| | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[lldb] [llgs] Fix multi-resume bugs with nonstop mode"Michał Górny2022-07-154-235/+85
| | | | | | This reverts commit f8605da8758fbae16410e4ed5493a39429fd73ec. This is causing buildbot failures and now I see that I have not updated the tests to use "stop" instead of "trap".
* [lldb] [llgs] Fix multi-resume bugs with nonstop modeMichał Górny2022-07-154-85/+235
| | | | | | | | | | | | | | | | | | | | | | 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 "[lldb] Add support for using integral const static data members in ↵Andy Yankovsky2022-07-1511-4/+500
| | | | | | | | | | | | | | the expression evaluator" 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.
* Modernize Optional::{getValueOr,hasValue}Fangrui Song2022-07-152-5/+4
|
* [lldb] Print the enum values and their description in the help outputJonas Devlieghere2022-07-142-1/+34
| | | | | | | | | | | | | | | | | 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
* [lldb] Refactor command option enum values (NFC)Jonas Devlieghere2022-07-1439-753/+734
| | | | | | | | | | | | 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
* Revert "[lldb] Add support for using integral const static data members in ↵Stella Stamenova2022-07-1411-497/+4
| | | | | | | | the expression evaluator" This reverts commit 486787210df5ce5eabadc90a7de353ae81101feb. This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/21186
* [lldb] [llgs] Remove not-really-used m_inferior_prev_stateMichał Górny2022-07-142-21/+7
| | | | | | | | | | | | | | | 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
* [lldb] Remove ELF .zdebug supportFangrui Song2022-07-143-61/+5
| | | | | | | | | | | 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
* [lldb] Add support for using integral const static data members in the ↵Andy Yankovsky2022-07-1411-4/+497
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression evaluator 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
* [lldb] [llgs] Convert m_debugged_processes into a map of structsMichał Górny2022-07-142-26/+44
| | | | | | | | | | | | | 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
* [lldb] [gdb-remote] Remove stray GetSupportsThreadSuffix() method (NFC)Michał Górny2022-07-141-2/+0
| | | | | Remove stray GDBRemoteCommunicationClient::GetSupportsThreadSuffix() method that is not implemented nor used anywhere.
* jGetLoadedDynamicLibrariesInfos can inspect machos not yet loadedJason Molenda2022-07-145-84/+234
| | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Add image dump pcm-info commandDave Lee2022-07-134-3/+111
| | | | | | | | | | | | | | | | | | 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
* [Support] Change compression::zlib::{compress,uncompress} to use uint8_t *Fangrui Song2022-07-131-2/+1
| | | | | | | 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.
* [lldb] Silence a GCC warning about missing returns after a fully covered ↵Martin Storsjö2022-07-131-0/+1
| | | | switch. NFC.
* [trace][intel pt] Support dumping the trace info in jsonymeng2022-07-139-46/+191
| | | | | | | | | | | 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
* [trace][intel pt] Add a cgroup filterGaurav Gaur2022-07-1315-28/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [trace][intel pt] Create a CPU change event and expose it in the dumperWalter Erquinigo2022-07-1312-31/+198
| | | | | | | | | | 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
* [trace] Add an option to save a compact trace bundleWalter Erquinigo2022-07-1317-192/+419
| | | | | | | | | | | 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
* [trace][intel pt] Measure the time it takes to decode a thread in per-cpu modePeicong Wu2022-07-135-29/+49
| | | | | | | | | | | | | | | | | | 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
* [trace][intel pt] Add a nice parser for the trace sizernofenko2022-07-135-24/+154
| | | | | | | | | | 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
* [LLDB] Fix TestConvenienceVariables.test AArch64/WindowsMuhammad Omair Javaid2022-07-132-7/+2
| | | | | | This patch fixes TestConvenienceVariables.test for AArch64 Windows. Clang/LLD was unable to find printf apparently available as a macro definition in stdio.h.
* [LLDB] Fix TestThreadAPI.py for AArch64/WindowsMuhammad Omair Javaid2022-07-131-0/+2
| | | | | | | | 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.