[Lldb-commits] [lldb] [lldb][Docs] Fix typo in `tutorial.rst` (PR #111326)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: 苏灵素@夏日限定 (Surinrasu) Changes --- Full diff: https://github.com/llvm/llvm-project/pull/111326.diff 1 Files Affected: - (modified) lldb/docs/use/tutorial.rst (+3-3) ``diff diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 76e8ac4aeab89c..7bfe1743b917f6 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -210,7 +210,7 @@ you will have to indicate these are not option markers by putting ``--`` after t command name, but before your command string. LLDB also has a built-in Python interpreter, which is accessible by the -``"script`` command. All the functionality of the debugger is available as classes +``script`` command. All the functionality of the debugger is available as classes in the Python interpreter, so the more complex commands that in GDB you would introduce with the ``define`` command can be done by writing Python functions using the LLDB Python library, then loading the scripts into your running @@ -331,8 +331,8 @@ do: :: - (lldb) help -- Breakpoint ID's consist major and - minor numbers; the major etc... + (lldb) help +-- Breakpoint ID's consist major and minor numbers; the major etc... Breakpoint Names `` https://github.com/llvm/llvm-project/pull/111326 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Fix typo in `tutorial.rst` (PR #111326)
https://github.com/Surinrasu created https://github.com/llvm/llvm-project/pull/111326 None From 86831746f36bb895ed4c2712012e33b8dff9dc8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=8B=8F=E7=81=B5=E7=B4=A0=40=E5=A4=8F=E6=97=A5=E9=99=90?= =?UTF-8?q?=E5=AE=9A?= Date: Mon, 7 Oct 2024 10:12:26 +0800 Subject: [PATCH] Fix typo in `tutorial.rst` --- lldb/docs/use/tutorial.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst index 76e8ac4aeab89c..7bfe1743b917f6 100644 --- a/lldb/docs/use/tutorial.rst +++ b/lldb/docs/use/tutorial.rst @@ -210,7 +210,7 @@ you will have to indicate these are not option markers by putting ``--`` after t command name, but before your command string. LLDB also has a built-in Python interpreter, which is accessible by the -``"script`` command. All the functionality of the debugger is available as classes +``script`` command. All the functionality of the debugger is available as classes in the Python interpreter, so the more complex commands that in GDB you would introduce with the ``define`` command can be done by writing Python functions using the LLDB Python library, then loading the scripts into your running @@ -331,8 +331,8 @@ do: :: - (lldb) help -- Breakpoint ID's consist major and - minor numbers; the major etc... + (lldb) help +-- Breakpoint ID's consist major and minor numbers; the major etc... Breakpoint Names ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Docs] Fix typo in `tutorial.rst` (PR #111326)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/111326 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DynamicLoaderDarwin load images in parallel (PR #110439)
jasonmolenda wrote: Ah, yes Simulator debugging is a bit different than macOS process debugging. With macOS process debugging -- with lldb and the inferior process running on the same computer -- lldb is using the same shared cache as the inferior process, so to read the libraries it reads them out of its own memory. (they don't exist as separate binaries on-disk any more anyway - the other alternative would be read them out of inferior memory via debugserver) A simulator process does will have many libraries that don't exist in the shared cache in lldb's memory, so it will need to read them from a different source -- an on-disk discrete binary, or reading memory via debugserver -- so it makes sense that there could be a performance difference in this case. https://github.com/llvm/llvm-project/pull/110439 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)
https://github.com/Da-Viper updated
https://github.com/llvm/llvm-project/pull/106907
>From 2ca64edb00d1f7b9d2938c9db32644c4a8cbc13e Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Sun, 1 Sep 2024 13:48:41 +0100
Subject: [PATCH 1/3] Add: show return value on step out
---
lldb/tools/lldb-dap/lldb-dap.cpp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index c5c4b09f15622b..c9116c62c46b5e 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -3801,6 +3801,17 @@ void request_variables(const llvm::json::Object
&request) {
variable_name_counts[GetNonNullVariableName(variable)]++;
}
+// Show return value if there is any ( in the top frame )
+auto process = g_dap.target.GetProcess();
+auto selectedThread = process.GetSelectedThread();
+lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
+if (stopReturnValue.IsValid() &&
+(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
+ auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
+ variables.emplace_back(
+ CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+}
+
// Now we construct the result with unique display variable names
for (auto i = start_idx; i < end_idx; ++i) {
lldb::SBValue variable = top_scope->GetValueAtIndex(i);
>From 8119240ca46e0e9d25ebc1b9c41d1eb9bd4f9ee2 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Sun, 1 Sep 2024 14:10:54 +0100
Subject: [PATCH 2/3] format file
---
lldb/tools/lldb-dap/lldb-dap.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index c9116c62c46b5e..bf87dd838c8a74 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -3809,7 +3809,7 @@ void request_variables(const llvm::json::Object &request)
{
(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
variables.emplace_back(
- CreateVariable(renamedReturnValue,0, UINT64_MAX, hex, false));
+ CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
}
// Now we construct the result with unique display variable names
>From d50238b0f7603ddf387be2f02e8a067a0158b761 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Sun, 15 Sep 2024 22:22:09 +0100
Subject: [PATCH 3/3] [lldb-dap] Add: Show children for return values
---
lldb/tools/lldb-dap/lldb-dap.cpp | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index bf87dd838c8a74..90b179e1e743c8 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -3803,13 +3803,19 @@ void request_variables(const llvm::json::Object
&request) {
// Show return value if there is any ( in the top frame )
auto process = g_dap.target.GetProcess();
-auto selectedThread = process.GetSelectedThread();
-lldb::SBValue stopReturnValue = selectedThread.GetStopReturnValue();
-if (stopReturnValue.IsValid() &&
-(selectedThread.GetSelectedFrame().GetFrameID() == 0)) {
- auto renamedReturnValue = stopReturnValue.Clone("(Return Value)");
- variables.emplace_back(
- CreateVariable(renamedReturnValue, 0, UINT64_MAX, hex, false));
+auto selected_thread = process.GetSelectedThread();
+lldb::SBValue stop_return_value = selected_thread.GetStopReturnValue();
+if (stop_return_value.IsValid() &&
+(selected_thread.GetSelectedFrame().GetFrameID() == 0)) {
+ auto renamed_return_value = stop_return_value.Clone("(Return Value)");
+ int64_t return_ref = 0;
+ if (stop_return_value.MightHaveChildren() ||
+ stop_return_value.IsSynthetic()) {
+return_ref = g_dap.variables.InsertExpandableVariable(
+stop_return_value, /*is_permanent=*/false);
+ }
+ variables.emplace_back(CreateVariable(renamed_return_value, return_ref,
+UINT64_MAX, hex, false));
}
// Now we construct the result with unique display variable names
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make env and source map dictionaries #95137 (PR #106919)
Da-Viper wrote: @walter-erquinigo Is there anything missing for this pull request ? https://github.com/llvm/llvm-project/pull/106919 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DynamicLoaderDarwin load images in parallel (PR #110439)
jasonmolenda wrote: This is an interesting idea, thanks for looking into it. When I spoke with Augusto about it, my main concern was that all of the Modules would be trying to add strings to the constant string pool and lock contention could become a bottleneck. I built github main unmodified, and with your parallel and parallel+preload patches and tried a quick benchmark. I built with `-DCMAKE_BUILD_TYPE=Debug` and with `-DCMAKE_BUILD_TYPE=RelWithDebInfo` because unoptimized lldb can have very different perf behaviors. I picked a random UI app -- Slack, a third party app using Electron, I have my system configured so I can attach to it -- and I used the command sequence like `time build.parallel-with-preload/bin/lldb -x -b -O 'settings set plugin.experimental.dynamic-loader.darwin.enable-parallel-image-load true' -o 'pro att -n Slack' -o 'det'` a few times for every configuration to get a rough idea of what perf looked like. My Slack has 936 binaries loaded, typical for a UI app these days. 10 of the binaries are outside the shared cache (app frameworks/dylibs). I did my tests on an M2 Max mac studio with 12 cores and 96GB of memory. Built `RelWithDebInfo`, unmodified lldb took 4.5 seconds. Parallel took 6.6 seconds. Parallel with preload took 6.7 seconds. Built `Debug`, unmodified lldb took 27.6 seconds. Parallel took 35.5 seconds. Parallel plus preload took 35.6 seconds. One important thing I'm doing in this case is not creating a Target with a binary. In `Target::SetExecutableModule` it calls `ObjectFileMachO::GetDependentModules` to get the list of all linked libraries, and loads the binaries at those filepaths into the target. Then at process launch/attach time, if we'd already parsed the symbol table for a binary, it would be reused. I'm curious what your machine/target process looks like, that we're seeing such different numbers. I'm guessing you were testing an unoptimized build given the time amounts. Does it look like I missed something with my test case? https://github.com/llvm/llvm-project/pull/110439 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DynamicLoaderDarwin load images in parallel (PR #110439)
jasonmolenda wrote: nb I used `plugin.experimental.dynamic-loader.darwin.enable-parallel-image-load` as the settings name so I could use the same command for all three types of lldb's - the unmodified lldb would give an error on an unrecognized setting normally and I didn't want to see that. Adding `.experimental` to a path makes an unrecognized setting a no-op. https://github.com/llvm/llvm-project/pull/110439 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [lldb] [lldb][CMake] Add single target that runs libc++ tests (PR #110856)
Michael137 wrote: Hmm seems like we can't currently run `dotest-param='--category'` on the API test suite because of the simulator tests: ``` File "/home/runner/_work/llvm-project/llvm-project/lldb/packages/Python/lldbsuite/test/test_result.py", line 183, in startTest self.hardMarkAsSkipped(test) File "/home/runner/_work/llvm-project/llvm-project/lldb/packages/Python/lldbsuite/test/test_result.py", line 162, in hardMarkAsSkipped getattr(test, test._testMethodName).__func__.__unittest_skip__ = True AttributeError: 'functools.partial' object has no attribute '__func__'. Did you mean: '__doc__'? ``` Looks like the mechanism by which we mark tests skipped doesn't work for the partial methods we construct for the `libcxx-simulators`. Even unwrapping the `functools.partial` method (or adding a separate `categories` file), will silently run these tests. One option would be to add `--filter-out=libcxx-simulators` to the lit-invocation. @labath are you familiar enough with the `unittest` python library to know how to properly mark these simulator tests skipped? https://github.com/llvm/llvm-project/pull/110856 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DynamicLoaderDarwin load images in parallel (PR #110439)
DmT021 wrote: > my main concern was that all of the Modules would be trying to add strings to > the constant string pool and lock contention could become a bottleneck. Yeah it sure would be a bottleneck. I didn't measure it precisely but I think I saw something about 30-50% of the time is spent on the mutexes in the string pools. And this is one of the reasons I gated the parallelized implementation behind the flag. One possible approach here would be to split the work done in the `ObjectFileMachO::ParseSymtab` into 3 phases: parsing, `ConstString` creation, and assigning the string to the symbols. So we can create all of the strings as one batch and minimize the locking penalty. `ParseSymtab` is a funny piece of code though and deserves its own pull request to address such things. > Built RelWithDebInfo, unmodified lldb took 4.5 seconds. Parallel took 6.6 > seconds. Parallel with preload took 6.7 seconds. > > Built Debug, unmodified lldb took 27.6 seconds. Parallel took 35.5 seconds. > Parallel plus preload took 35.6 seconds. Oh wow. 4.5 sec is amazingly fast. I'll try to reproduce your results. > I'm curious what your machine/target process looks like, that we're seeing > such different numbers. I'm guessing you were testing an unoptimized build > given the time amounts. Does it look like I missed something with my test > case? The machine is MBP M1 10 cores/32 GB. I'm testing this patch on [the swift fork](https://github.com/swiftlang/llvm-project/tree/stable/20230725) built in the `Release` mode and I'm attaching it to an iOS app(in the simulator) that has 978 modules. I'm running `lldb --local-lldbinit` in Instruments app with the following lldbinit file: ``` settings set plugin.dynamic-loader.darwin.enable-parallel-image-load 1 process attach --name browser_corp_ios continue ``` https://github.com/llvm/llvm-project/pull/110439 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add: show return value on step out (PR #106907)
https://github.com/walter-erquinigo commented: This looks much better! Could you please write some tests? https://github.com/llvm/llvm-project/pull/106907 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Make env and source map dictionaries #95137 (PR #106919)
https://github.com/walter-erquinigo approved this pull request. nice! https://github.com/llvm/llvm-project/pull/106919 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
