[Lldb-commits] [lldb] [lldb] Handle an empty SBMemoryRegionInfo from scripted process (PR #115963)
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, error))
+ GetInterface().GetMemoryRegionContainingAddress(load_addr, error)) {
region = *region_or_err;
+if (region.GetRange().GetRangeBase() == 0 &&
+(region.GetRange().GetByteSize() == 0 ||
+ region.GetRange().GetByteSize() == LLDB_INVALID_ADDRESS)) {
labath wrote:
A single region that covers the entire address space is fairly boring, but it
is the kind of thing I might return as an "I don't know" value (perhaps I'm in
some embedded environment where every address really is readable?). What's the
problem with that kind of result?
That said, I think this check could be made more robust. `(0, 0)` is the
likeliest response, but doesn't this mean that we would still loop if the
plugin returns `(0,1)` instead? It sounds to me that if we check that:
- the returned region is of non-zero size
- the returned region actually includes the address being queried (I guess this
kinda subsumes the previous item)
then we can guarantee forward progress no matter what the plugin returns (?)
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Handle an empty SBMemoryRegionInfo from scripted process (PR #115963)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/115963 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Relax check for breakpoint site in Unwind/windows-unaligned-x86_64.test (PR #115318)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Stefan Gränitz (weliveindetail)
Changes
This test checks the thread backtrace for entries of intermediate frames that
aren't aligned to 16 bytes. In order to do that, it sets a single breakpoint
and makes sure we stop there. It seems sufficient, however, to check that we
hit the breakpoint itself and not which particular site.
---
Full diff: https://github.com/llvm/llvm-project/pull/115318.diff
1 Files Affected:
- (modified) lldb/test/Shell/Unwind/windows-unaligned-x86_64.test (+1-1)
``diff
diff --git a/lldb/test/Shell/Unwind/windows-unaligned-x86_64.test
b/lldb/test/Shell/Unwind/windows-unaligned-x86_64.test
index 94f1c011ebd2a6..0356960424328b 100644
--- a/lldb/test/Shell/Unwind/windows-unaligned-x86_64.test
+++ b/lldb/test/Shell/Unwind/windows-unaligned-x86_64.test
@@ -17,7 +17,7 @@ breakpoint set -n func
# CHECK: Breakpoint 1: where = {{.*}}`{{(::)?}}func
process launch
-# CHECK: stop reason = breakpoint 1.1
+# CHECK: stop reason = breakpoint 1
thread backtrace
# CHECK: frame #0: {{.*}}`{{(::)?}}func
``
https://github.com/llvm/llvm-project/pull/115318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
@@ -169,6 +169,38 @@ Status ProcessWindows::DoDetach(bool keep_stopped) {
Log *log = GetLog(WindowsLog::Process);
StateType private_state = GetPrivateState();
if (private_state != eStateExited && private_state != eStateDetached) {
+if (!keep_stopped) {
+ // if the thread is suspended by lldb, we have to resume threads before
+ // detaching process. When we do after DetachProcess(), thread handles
+ // become invalid so we do before detach.
+ if (private_state == eStateStopped || private_state == eStateCrashed) {
+LLDB_LOG(log, "process {0} is in state {1}. Resuming for detach...",
+ m_session_data->m_debugger->GetProcess().GetProcessId(),
+ GetPrivateState());
+
+LLDB_LOG(log, "resuming {0} threads for detach.",
+ m_thread_list.GetSize());
+
+bool failed = false;
+for (uint32_t i = 0; i < m_thread_list.GetSize(); ++i) {
+ auto thread = std::static_pointer_cast(
+ m_thread_list.GetThreadAtIndex(i));
+ Status result = thread->DoResume();
anatawa12 wrote:
> Does this mean that if the thread/process gets another exception before we
> manage to detach from it, it will remain suspended?
No, the process will not suspend.
The process will receive the exception and the process handles it instead.
For simple programs, it will crash the process but some process may handle in
their way.
We can see this behavior with TestDetachResumes by reverting
5ad1a98a8b07e1d75829870995fbf36fb8cb99ed.
> I'm not familiar with windows debugging API, so I don't know if there's a way
> to handle this, but I believe this is the reason why linux (and others) have
> a PTRACE_DETACH call which (atomically) detaches from a process/thread _and_
> resumes it.
I agree with that but as far as I researched I could not figure out the API to
detach and resume thread simultaneously.
https://github.com/llvm/llvm-project/pull/115712
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Relax check for breakpoint site in Unwind/windows-unaligned-x86_64.test (PR #115318)
https://github.com/weliveindetail ready_for_review https://github.com/llvm/llvm-project/pull/115318 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
anatawa12 wrote: > Can you explain what's the difference between them? Sorry for confusion. I'll explain two bugs cleanly. First of all, both bug must be fixed to pass `TestDetachResumes` test. The first bug is the process may freeze in Suspended state on detaching process. This bug is tracked as #67825. It looks this only happens when we detached process without resuming process (continue command). The second bug is the process may crash (killed)on detaching process. It looks this bug is not tracked in llvm-project repository but I think [RIDER-99436] is experiencing this bug. It looks this bug will always happen on detaching process. Both bug will make the attached process unusable on detaching process, but the difference between two bug is what happens on detaching process. The first bug make the process frozen in Suspended state, the later bug crashes the process. [RIDER-99436]: https://youtrack.jetbrains.com/issue/RIDER-99436/Unity-Editor-will-be-crashed-when-detaching-LLDB-debugger-in-Rider https://github.com/llvm/llvm-project/pull/115712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/ashgti ready_for_review https://github.com/llvm/llvm-project/pull/116045 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix source display for artificial locations (PR #115876)
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/115876 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added new plugin AIX-DYLD (Dynamic Loader) Base Support (PR #115714)
DhruvSrivastavaX wrote: Hi @labath , I agree that we can put a hold on this one for now. But on that note, we want to start integrating multiple plugins Parallely, but Systematically, to make the upstreaming pick up some pace and also be in order. Keeping that in mind, I think right now, the best candidates will be: xcoff plugin, process plugin, and host plugin. Hope thats alright? Please do suggest if you have something more in mind. https://github.com/llvm/llvm-project/pull/115714 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Fix inline_sites_live.cpp Shell when run on Windows remotely from Linux (PR #115722)
labath wrote: That might make more sense, but looking at the bot, it really does seem to run on windows, with a remote target (I guess it doesn't really run the binary there, it must fall back to host when it find the binary is not compatible). And if I had to guess, I'd say that all of this platform dancing causes it to somehow switch the the lldb-server windows implementation, which sends thread names (unlike the in-process one?). Overall, I guess the change is fine, though the combination is not particularly useful to test. https://github.com/llvm/llvm-project/pull/115722 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -4385,6 +4385,27 @@ bool TargetProperties::GetInjectLocalVariables(
.value_or(true);
}
+bool TargetProperties::GetUseDIL(ExecutionContext *exe_ctx) const {
+ const Property *exp_property =
+ m_collection_sp->GetPropertyAtIndex(ePropertyExperimental, exe_ctx);
+ OptionValueProperties *exp_values =
+ exp_property->GetValue()->GetAsProperties();
+ if (exp_values)
+return exp_values->GetPropertyAtIndexAs(ePropertyUseDIL, exe_ctx)
+.value_or(false);
+ else
+return true;
werat wrote:
Should this be `false` as well? Otherwise DIL will be enabled if `exp_values`
is not available (not sure when this happens though).
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/115666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
Previously this used `var` as both an lldb command and variable in the source
to validate the behavior of the 'auto' repl mode. However, `var` seems to
occasionally fail in the CI test when attempting to print some c++ types.
Instead switch the command and variable name to `list` which should not run the
dynamic variable formatting code for c++ objects.
This should fix #116041.
---
Full diff: https://github.com/llvm/llvm-project/pull/116045.diff
2 Files Affected:
- (modified) lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py (+5-5)
- (modified) lldb/test/API/tools/lldb-dap/evaluate/main.cpp (+2-2)
``diff
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 0126d40d86fca2..251d77d79d0800 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
self.assertEvaluateFailure("my_struct") # type name
self.assertEvaluateFailure("int") # type name
@@ -162,7 +162,7 @@ def run_test_evaluate_expressions(
# Expressions at breakpoint 3, which is inside a_function
self.continue_to_next_stop()
-self.assertEvaluate("var", "42")
+self.assertEvaluate("list", "42")
self.assertEvaluate("static_int", "42")
self.assertEvaluate("non_static_int", "43")
@@ -176,13 +176,13 @@ def run_test_evaluate_expressions(
if self.isExpressionParsedExpected():
self.assertEvaluate("a_function", "0x.*a.out`a_function.*")
self.assertEvaluate("a_function(1)", "1")
-self.assertEvaluate("var + 1", "43")
+self.assertEvaluate("list + 1", "43")
self.assertEvaluate("foo_func", "0x.*a.out`foo_func.*")
self.assertEvaluate("foo_var", "44")
else:
self.assertEvaluateFailure("a_function")
self.assertEvaluateFailure("a_function(1)")
-self.assertEvaluateFailure("var + 1")
+self.assertEvaluateFailure("list + 1")
self.assertEvaluateFailure("foo_func")
self.assertEvaluateFailure("foo_var")
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
index 1c68716e3a6e11..1c3d258114b1ff 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
@@ -8,8 +8,8 @@ static int static_int = 42;
int non_static_int = 43;
-int a_function(int var) {
- return var; // breakpoint 3
+int a_function(int list) {
+ return list; // breakpoint 3
}
struct my_struct {
``
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
Michael137 wrote:
Oh gotcha. I forgot that `list` is also a command
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Make CompilerDecl::GetName (always) return template args (PR #116068)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Pavel Labath (labath) Changes I ran into this while look at a different bug (patch coming soon). This function has only two callers. The first is SBTypeStaticField::GetName (which doesn't care about templates), and the other is CompilerDecl::GetCompilerContext (in the TypeQuery constructor), which does want template arguments. This function was (normally) returning the name without template args. Since this code is only used when looking up a type in another shared library, the odds of running into this bug are relatively low, but I add a test to demonstrate the scenario and the fix for it nonetheless. Amazingly (and scarily), this test actually passes without this change in the default configuration -- and only fails with -gsimple-template-names. The reason for that is that in the non-simplified case we create a regular CXXRecordDecl whose name is "bar" (instead of a template record "foo" with an argument of "int"). When evaluating the expression, we are somehow able to replace this with a proper template specialization decl. --- Full diff: https://github.com/llvm/llvm-project/pull/116068.diff 6 Files Affected: - (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+1-1) - (added) lldb/test/API/lang/cpp/forward/Makefile (+5) - (added) lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py (+61) - (added) lldb/test/API/lang/cpp/forward/foo.cpp (+3) - (added) lldb/test/API/lang/cpp/forward/foo.h (+3) - (added) lldb/test/API/lang/cpp/forward/main.cpp (+13) ``diff diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp index f5063175d6e070..c5249088a291b8 100644 --- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp +++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp @@ -9116,7 +9116,7 @@ ConstString TypeSystemClang::DeclGetName(void *opaque_decl) { clang::NamedDecl *nd = llvm::dyn_cast((clang::Decl *)opaque_decl); if (nd != nullptr) - return ConstString(nd->getDeclName().getAsString()); + return ConstString(GetTypeNameForDecl(nd, /*qualified=*/false)); } return ConstString(); } diff --git a/lldb/test/API/lang/cpp/forward/Makefile b/lldb/test/API/lang/cpp/forward/Makefile new file mode 100644 index 00..0b806b314397c5 --- /dev/null +++ b/lldb/test/API/lang/cpp/forward/Makefile @@ -0,0 +1,5 @@ +CXX_SOURCES := main.cpp +DYLIB_CXX_SOURCES := foo.cpp +DYLIB_NAME := foo + +include Makefile.rules diff --git a/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py new file mode 100644 index 00..5e9dd9c2227dd5 --- /dev/null +++ b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py @@ -0,0 +1,61 @@ +"""Test that forward declaration of a c++ template gets resolved correctly.""" + +import lldb +from lldbsuite.test.lldbtest import * +from lldbsuite.test.decorators import * +import lldbsuite.test.lldbutil as lldbutil + + +class ForwardDeclarationTestCase(TestBase): +def do_test(self, dictionary=None): +"""Display *bar_ptr when stopped on a function with forward declaration of struct bar.""" +self.build(dictionary=dictionary) +exe = self.getBuildArtifact("a.out") +target = self.dbg.CreateTarget(exe) +self.assertTrue(target, VALID_TARGET) + +environment = self.registerSharedLibrariesWithTarget(target, ["foo"]) + +# Break inside the foo function which takes a bar_ptr argument. +lldbutil.run_break_set_by_symbol(self, "foo", num_expected_locations=1) + +process = target.LaunchSimple( +None, environment, self.get_process_working_directory() +) +self.assertTrue(process, PROCESS_IS_VALID) + +# The stop reason of the thread should be breakpoint. +self.expect( +"thread list", +STOPPED_DUE_TO_BREAKPOINT, +substrs=["stopped", "stop reason = breakpoint"], +) + +# The breakpoint should have a hit count of 1. +lldbutil.check_breakpoint(self, bpno=1, expected_hit_count=1) + +self.expect_expr( +"*bar_ptr", +result_type="bar", +result_children=[ValueCheck(value="47", name="a", type="int")], +) + +def test(self): +self.do_test() + +@no_debug_info_test +@skipIfDarwin +@skipIf(compiler=no_match("clang")) +@skipIf(compiler_version=["<", "8.0"]) +@expectedFailureAll(oslist=["windows"]) +def test_debug_names(self): +"""Test that we are able to find complete types when using DWARF v5 +accelerator tables""" +self.do_test(dict(CFLAGS_EXTRAS="-gdwarf-5 -gpubnames")) + +@no_debug_info_test +@skipIf(compiler=no_match("clang")) +def test_simple_template_names(self): +"""Test that we are able to find comp
[Lldb-commits] [lldb] [lldb] Make CompilerDecl::GetName (always) return template args (PR #116068)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/116068
I ran into this while look at a different bug (patch coming soon). This
function has only two callers. The first is SBTypeStaticField::GetName (which
doesn't care about templates), and the other is
CompilerDecl::GetCompilerContext (in the TypeQuery constructor), which does
want template arguments.
This function was (normally) returning the name without template args. Since
this code is only used when looking up a type in another shared library, the
odds of running into this bug are relatively low, but I add a test to
demonstrate the scenario and the fix for it nonetheless.
Amazingly (and scarily), this test actually passes without this change in the
default configuration -- and only fails with -gsimple-template-names. The
reason for that is that in the non-simplified case we create a regular
CXXRecordDecl whose name is "bar" (instead of a template record "foo" with
an argument of "int"). When evaluating the expression, we are somehow able to
replace this with a proper template specialization decl.
>From bf27d39563f2e2eec8896dcc5679f93dc09f8977 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Wed, 13 Nov 2024 16:28:54 +0100
Subject: [PATCH] [lldb] Make CompilerDecl::GetName (always) return template
args
I ran into this while look at a different bug (patch coming soon). This
function has only two callers. The first is SBTypeStaticField::GetName
(which doesn't care about templates), and the other is
CompilerDecl::GetCompilerContext (in the TypeQuery constructor), which
does want template arguments.
This function was (normally) returning the name without template args.
Since this code is only used when looking up a type in another shared
library, the odds of running into this bug are relatively low, but I add
a test to demonstrate the scenario and the fix for it nonetheless.
Amazingly (and scarily), this test actually passes without this change
in the default configuration -- and only fails with
-gsimple-template-names. The reason for that is that in the
non-simplified case we create a regular CXXRecordDecl whose name is
"bar" (instead of a template record "foo" with an argument of
"int"). When evaluating the expression, we are somehow able to replace
this with a proper template specialization decl.
---
.../TypeSystem/Clang/TypeSystemClang.cpp | 2 +-
lldb/test/API/lang/cpp/forward/Makefile | 5 ++
.../cpp/forward/TestCPPForwardDeclaration.py | 61 +++
lldb/test/API/lang/cpp/forward/foo.cpp| 3 +
lldb/test/API/lang/cpp/forward/foo.h | 3 +
lldb/test/API/lang/cpp/forward/main.cpp | 13
6 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 lldb/test/API/lang/cpp/forward/Makefile
create mode 100644 lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
create mode 100644 lldb/test/API/lang/cpp/forward/foo.cpp
create mode 100644 lldb/test/API/lang/cpp/forward/foo.h
create mode 100644 lldb/test/API/lang/cpp/forward/main.cpp
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index f5063175d6e070..c5249088a291b8 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -9116,7 +9116,7 @@ ConstString TypeSystemClang::DeclGetName(void
*opaque_decl) {
clang::NamedDecl *nd =
llvm::dyn_cast((clang::Decl *)opaque_decl);
if (nd != nullptr)
- return ConstString(nd->getDeclName().getAsString());
+ return ConstString(GetTypeNameForDecl(nd, /*qualified=*/false));
}
return ConstString();
}
diff --git a/lldb/test/API/lang/cpp/forward/Makefile
b/lldb/test/API/lang/cpp/forward/Makefile
new file mode 100644
index 00..0b806b314397c5
--- /dev/null
+++ b/lldb/test/API/lang/cpp/forward/Makefile
@@ -0,0 +1,5 @@
+CXX_SOURCES := main.cpp
+DYLIB_CXX_SOURCES := foo.cpp
+DYLIB_NAME := foo
+
+include Makefile.rules
diff --git a/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
new file mode 100644
index 00..5e9dd9c2227dd5
--- /dev/null
+++ b/lldb/test/API/lang/cpp/forward/TestCPPForwardDeclaration.py
@@ -0,0 +1,61 @@
+"""Test that forward declaration of a c++ template gets resolved correctly."""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+
+
+class ForwardDeclarationTestCase(TestBase):
+def do_test(self, dictionary=None):
+"""Display *bar_ptr when stopped on a function with forward
declaration of struct bar."""
+self.build(dictionary=dictionary)
+exe = self.getBuildArtifact("a.out")
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+environment = self.registerSharedLibrariesWithTarget(target, [
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
@@ -169,6 +169,38 @@ Status ProcessWindows::DoDetach(bool keep_stopped) {
Log *log = GetLog(WindowsLog::Process);
StateType private_state = GetPrivateState();
if (private_state != eStateExited && private_state != eStateDetached) {
+if (!keep_stopped) {
+ // if the thread is suspended by lldb, we have to resume threads before
+ // detaching process. When we do after DetachProcess(), thread handles
+ // become invalid so we do before detach.
+ if (private_state == eStateStopped || private_state == eStateCrashed) {
+LLDB_LOG(log, "process {0} is in state {1}. Resuming for detach...",
+ m_session_data->m_debugger->GetProcess().GetProcessId(),
+ GetPrivateState());
+
+LLDB_LOG(log, "resuming {0} threads for detach.",
+ m_thread_list.GetSize());
+
+bool failed = false;
+for (uint32_t i = 0; i < m_thread_list.GetSize(); ++i) {
+ auto thread = std::static_pointer_cast(
+ m_thread_list.GetThreadAtIndex(i));
+ Status result = thread->DoResume();
anatawa12 wrote:
It's True, (as far as I know)
https://github.com/llvm/llvm-project/pull/115712
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
labath wrote: Just one more clarification. I'm sorry for this takes so long, but I'm not familiar with the windows debugging API, which means that I might not be getting some of the things that are obvious. I just want to make sure I understand what's happening here. > The first bug is the process may freeze in Suspended state on detaching > process. Okay, I think I understand this part. The process is "suspended" by the breakpoint and detaching from it does not automatically resume it. > The second bug is the process may crash (killed)on detaching process. I'm less sure about this one. Is that due to the breakpoint exception somehow remaining "pending" and that we need to clear/ignore/suppress it before detaching? https://github.com/llvm/llvm-project/pull/115712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Fix inline_sites_live.cpp Shell when run on Windows remotely from Linux (PR #115722)
https://github.com/dzhidzhoev closed https://github.com/llvm/llvm-project/pull/115722 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0afdac4 - [lldb][test] Fix inline_sites_live.cpp Shell when run on Windows remotely from Linux (#115722)
Author: Vladislav Dzhidzhoev
Date: 2024-11-13T18:49:32+01:00
New Revision: 0afdac41ceb9567c2f953092d0e8b6220c15acea
URL:
https://github.com/llvm/llvm-project/commit/0afdac41ceb9567c2f953092d0e8b6220c15acea
DIFF:
https://github.com/llvm/llvm-project/commit/0afdac41ceb9567c2f953092d0e8b6220c15acea.diff
LOG: [lldb][test] Fix inline_sites_live.cpp Shell when run on Windows remotely
from Linux (#115722)
This test fails on
https://lab.llvm.org/staging/#/builders/197/builds/76/steps/18/logs/FAIL__lldb-shell__inline_sites_live_cpp
because of a little difference in the lldb output.
```
# .---command stderr
# |
C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\test\Shell\SymbolFile\NativePDB\inline_sites_live.cpp:25:11:
error: CHECK: expected string not found in input
# | // CHECK: * thread #1, stop reason = breakpoint 1
# | ^
# | :1:1: note: scanning from here
# | (lldb) platform select remote-linux
# | ^
# | :28:27: note: possible intended match here
# | * thread #1, name = 'inline_sites_li', stop reason = breakpoint 1.3
# | ^
# |
```
Added:
Modified:
lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
Removed:
diff --git a/lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
b/lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
index df6353e28303a3..549bc881b19bb7 100644
--- a/lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
+++ b/lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
@@ -22,11 +22,11 @@ int main(int argc, char** argv) {
foo(argc);
}
-// CHECK: * thread #1, stop reason = breakpoint 1
+// CHECK: * thread #1, {{.*}}stop reason = breakpoint 1
// CHECK-NEXT:frame #0: {{.*}}`main [inlined] bar(param=2)
// CHECK: (lldb) expression param
// CHECK-NEXT: (int) $0 = 2
-// CHECK: * thread #1, stop reason = breakpoint 2
+// CHECK: * thread #1, {{.*}}stop reason = breakpoint 2
// CHECK-NEXT:frame #0: {{.*}}`main [inlined] foo(param=1)
// CHECK: (lldb) expression param
// CHECK-NEXT: (int) $1 = 1
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Fix inline_sites_live.cpp Shell when run on Windows remotely from Linux (PR #115722)
dzhidzhoev wrote: > If I understand correctly this is building the test on Linux and running it > on Windows. > > And it seems that the output is in fact better this way? Can't complain about > that. No, it's the opposite, we're running on Windows host and Linux target. > And if I had to guess, I'd say that all of this platform dancing causes it to > somehow switch the the lldb-server windows implementation, which sends thread > names (unlike the in-process one?). It makes sense. I also thought it was somehow related to remote vs local execution. > Overall, I guess the change is fine, though the combination is not > particularly useful to test. Thank you! Considering that there's "REQUIRES: system-windows" on top of the test, maybe I'll turn it off for target-linux at all? https://github.com/llvm/llvm-project/pull/115722 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -304,6 +304,42 @@ class StackFrame : public ExecutionContextScope, /// /// \return /// A shared pointer to the ValueObject described by var_expr. + lldb::ValueObjectSP LegacyGetValueForVariableExpressionPath( + llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic, + uint32_t options, lldb::VariableSP &var_sp, Status &error); + + /// Create a ValueObject for a variable name / pathname, possibly including + /// simple dereference/child selection syntax. + /// + /// \param[in] var_expr + /// The string specifying a variable to base the VariableObject off + /// of. + /// + /// \param[in] use_dynamic + /// Whether the correct dynamic type of an object pointer should be + /// determined before creating the object, or if the static type is + /// sufficient. One of the DynamicValueType enumerated values. + /// + /// \param[in] options + /// An unsigned integer of flags, values from + /// StackFrame::ExpressionPathOption + /// enum. + /// \param[in] var_sp + /// A VariableSP that will be set to the variable described in the + /// var_expr path. + /// + /// \param[in] error + /// Record any errors encountered while evaluating var_expr. + /// + /// \return + /// A shared pointer to the ValueObject described by var_expr. + lldb::ValueObjectSP DILGetValueForVariableExpressionPath( labath wrote: Can these be private (they should only be called from the dispatcher function, right)? (You can attach the doxygen comment to the public function, there's no need to repeat it everywhere) https://github.com/llvm/llvm-project/pull/115666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
@@ -169,6 +169,38 @@ Status ProcessWindows::DoDetach(bool keep_stopped) {
Log *log = GetLog(WindowsLog::Process);
StateType private_state = GetPrivateState();
if (private_state != eStateExited && private_state != eStateDetached) {
+if (!keep_stopped) {
+ // if the thread is suspended by lldb, we have to resume threads before
+ // detaching process. When we do after DetachProcess(), thread handles
+ // become invalid so we do before detach.
+ if (private_state == eStateStopped || private_state == eStateCrashed) {
+LLDB_LOG(log, "process {0} is in state {1}. Resuming for detach...",
+ m_session_data->m_debugger->GetProcess().GetProcessId(),
+ GetPrivateState());
+
+LLDB_LOG(log, "resuming {0} threads for detach.",
+ m_thread_list.GetSize());
+
+bool failed = false;
+for (uint32_t i = 0; i < m_thread_list.GetSize(); ++i) {
+ auto thread = std::static_pointer_cast(
+ m_thread_list.GetThreadAtIndex(i));
+ Status result = thread->DoResume();
labath wrote:
Does this mean that if the thread/process gets another exception before we
manage to detach from it, it will remain suspended? I'm not familiar with
windows debugging API, so I don't know if there's a way to handle this, but I
believe this is the reason why linux (and others) have a PTRACE_DETACH call
which (atomically) detaches from a process/thread *and* resumes it.
https://github.com/llvm/llvm-project/pull/115712
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/115712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -508,6 +508,32 @@ StackFrame::GetInScopeVariableList(bool get_file_globals,
ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
llvm::StringRef var_expr, DynamicValueType use_dynamic, uint32_t options,
VariableSP &var_sp, Status &error) {
+ // Check to see if we should use the DIL implementation.
+ lldb::TargetSP target_sp = CalculateTarget();
+ ExecutionContext exe_ctx;
+ CalculateExecutionContext(exe_ctx);
+ bool use_DIL = target_sp->GetUseDIL(&exe_ctx);
labath wrote:
```suggestion
ExecutionContext exe_ctx;
CalculateExecutionContext(exe_ctx);
bool use_DIL = exe_ctx.GetTargetRef().GetUseDIL(&exe_ctx);
```
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -508,6 +508,32 @@ StackFrame::GetInScopeVariableList(bool get_file_globals,
ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
llvm::StringRef var_expr, DynamicValueType use_dynamic, uint32_t options,
VariableSP &var_sp, Status &error) {
+ // Check to see if we should use the DIL implementation.
+ lldb::TargetSP target_sp = CalculateTarget();
+ ExecutionContext exe_ctx;
+ CalculateExecutionContext(exe_ctx);
+ bool use_DIL = target_sp->GetUseDIL(&exe_ctx);
+ if (use_DIL)
+return DILGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
+var_sp, error);
+ else
labath wrote:
https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return
(I also think the comments in this method don't tell us anything that's not
immediately obvious from the code. I'd just remove them.)
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
labath wrote: FWIW, I also think that having "continue" go sometimes backwards would be very confusing. If we only have forward execution, then the difference between "run forwards" and "resume the current thread plan (forwards)" is not big. However, the difference between "run forwards" and "resume current plan **backwards**" is huge, and I think we should avoid the possibility of confusing the two (for example, by requiring an explicit direction argument if the current thread plan wants to go backwards). https://github.com/llvm/llvm-project/pull/112079 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
https://github.com/labath commented: Thank you for looking into this. So, from what I was able to gather, there are two issues/bugs here, but I'm having trouble figuring out what they are. Can you explain what's the difference between them? I'm trying to figure out if we can/should have a separate test case for the other bug. https://github.com/llvm/llvm-project/pull/115712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c7df106 - Unify naming of internal pointer members in std::vector and std::__split_buffer (#115517)
Author: Peng Liu
Date: 2024-11-13T11:08:08+01:00
New Revision: c7df10643bda4acdc9a02406a2eee8aa4ced747f
URL:
https://github.com/llvm/llvm-project/commit/c7df10643bda4acdc9a02406a2eee8aa4ced747f
DIFF:
https://github.com/llvm/llvm-project/commit/c7df10643bda4acdc9a02406a2eee8aa4ced747f.diff
LOG: Unify naming of internal pointer members in std::vector and
std::__split_buffer (#115517)
Related to PR #114423, this PR proposes to unify the naming of the
internal pointer members in `std::vector` and `std::__split_buffer` for
consistency and clarity.
Both `std::vector` and `std::__split_buffer` originally used a
`__compressed_pair` member named `__end_cap_`
to store an internal capacity pointer and an allocator. However,
inconsistent naming changes have been made in both classes:
- `std::vector` now uses `__cap_` and `__alloc_` for its internal
pointer and allocator members.
- In contrast, `std::__split_buffer` retains the name `__end_cap_` for
the capacity pointer, along with `__alloc_`.
This inconsistency between the names `__cap_` and `__end_cap_` has
caused confusions (especially to myself when I was working on both
classes). I suggest unifying these names by renaming `__end_cap_` to
`__cap_` in `std::__split_buffer`.
Added:
Modified:
libcxx/include/__split_buffer
libcxx/include/__vector/vector.h
libcxx/include/deque
lldb/examples/synthetic/libcxx.py
Removed:
diff --git a/libcxx/include/__split_buffer b/libcxx/include/__split_buffer
index 63ead9b1efd36d..a44811c766735a 100644
--- a/libcxx/include/__split_buffer
+++ b/libcxx/include/__split_buffer
@@ -47,7 +47,7 @@ _LIBCPP_PUSH_MACROS
_LIBCPP_BEGIN_NAMESPACE_STD
// __split_buffer allocates a contiguous chunk of memory and stores objects in
the range [__begin_, __end_).
-// It has uninitialized memory in the ranges [__first_, __begin_) and
[__end_, __end_cap_.first()). That allows
+// It has uninitialized memory in the ranges [__first_, __begin_) and
[__end_, __cap_). That allows
// it to grow both in the front and back without having to move the data.
template >
@@ -78,20 +78,20 @@ public:
pointer __first_;
pointer __begin_;
pointer __end_;
- _LIBCPP_COMPRESSED_PAIR(pointer, __end_cap_, allocator_type, __alloc_);
+ _LIBCPP_COMPRESSED_PAIR(pointer, __cap_, allocator_type, __alloc_);
__split_buffer(const __split_buffer&)= delete;
__split_buffer& operator=(const __split_buffer&) = delete;
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI __split_buffer()
_NOEXCEPT_(is_nothrow_default_constructible::value)
- : __first_(nullptr), __begin_(nullptr), __end_(nullptr),
__end_cap_(nullptr) {}
+ : __first_(nullptr), __begin_(nullptr), __end_(nullptr), __cap_(nullptr)
{}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI explicit
__split_buffer(__alloc_rr& __a)
- : __first_(nullptr), __begin_(nullptr), __end_(nullptr),
__end_cap_(nullptr), __alloc_(__a) {}
+ : __first_(nullptr), __begin_(nullptr), __end_(nullptr),
__cap_(nullptr), __alloc_(__a) {}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI explicit
__split_buffer(const __alloc_rr& __a)
- : __first_(nullptr), __begin_(nullptr), __end_(nullptr),
__end_cap_(nullptr), __alloc_(__a) {}
+ : __first_(nullptr), __begin_(nullptr), __end_(nullptr),
__cap_(nullptr), __alloc_(__a) {}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI
__split_buffer(size_type __cap, size_type __start, __alloc_rr& __a);
@@ -123,7 +123,7 @@ public:
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI bool empty() const {
return __end_ == __begin_; }
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI size_type capacity()
const {
-return static_cast(__end_cap_ - __first_);
+return static_cast(__cap_ - __first_);
}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI size_type
__front_spare() const {
@@ -131,7 +131,7 @@ public:
}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI size_type __back_spare()
const {
-return static_cast(__end_cap_ - __end_);
+return static_cast(__cap_ - __end_);
}
_LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI reference front() {
return *__begin_; }
@@ -215,14 +215,14 @@ _LIBCPP_CONSTEXPR_SINCE_CXX20 bool __split_buffer<_Tp,
_Allocator>::__invariants
return false;
if (__end_ != nullptr)
return false;
-if (__end_cap_ != nullptr)
+if (__cap_ != nullptr)
return false;
} else {
if (__begin_ < __first_)
return false;
if (__end_ < __begin_)
return false;
-if (__end_cap_ < __end_)
+if (__cap_ < __end_)
return false;
}
return true;
@@ -262,8 +262,8 @@ _LIBCPP_CONSTEXPR_SINCE_CXX20 void
__split_buffer<_Tp, _Allocator>::__construct_at_end_with_sentinel(_Iterator
__first, _Sentinel __last) {
__alloc_rr& __a = __alloc_;
for (; __first != __last; ++
[Lldb-commits] [libcxx] [lldb] Unify naming of internal pointer members in std::vector and std::__split_buffer (PR #115517)
https://github.com/philnik777 closed https://github.com/llvm/llvm-project/pull/115517 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [lldb] Unify naming of internal pointer members in std::vector and std::__split_buffer (PR #115517)
Michael137 wrote: LLDB changes LGTM, thanks! The `tools/lldb-dap/evaluate/TestDAP_evaluate.py` is unrelated to this PR and has been failing on other PRs too. So feel free to merge if the libc++ changes are good to go https://github.com/llvm/llvm-project/pull/115517 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
https://github.com/cmtice updated
https://github.com/llvm/llvm-project/pull/115666
>From d757bf7ac49d504707e39fe6f3a0bc93da5aef30 Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Sun, 10 Nov 2024 10:07:22 -0800
Subject: [PATCH 1/3] [LLDB] Add framework for Data Inspection Language (DIL)
work.
Add the framework code for hooking up and calling the Data Inspection Language
(DIL) implementation, as an alternate implementation for the 'frame
variable' command. For now, this is an opt-in option, via a target setting
'target.experimental.use-DIL'. See
https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for more
information about this project.
This PR does not actually call any of the DIL code; instead the piece that will
eventually call the DIL code (StackFrame::DILEvaluateVariableExpression) calls
back into the original 'frame variable' implementation.
---
lldb/include/lldb/Target/StackFrame.h | 29 +++
lldb/include/lldb/Target/Target.h | 4 +++
lldb/source/API/SBFrame.cpp | 22 ++
lldb/source/Commands/CommandObjectFrame.cpp | 19 +---
.../Commands/CommandObjectWatchpoint.cpp | 14 +++--
lldb/source/Expression/UserExpression.cpp | 29 ++-
.../SymbolFile/DWARF/DWARFASTParser.cpp | 15 --
lldb/source/Target/StackFrame.cpp | 9 ++
lldb/source/Target/Target.cpp | 21 ++
lldb/source/Target/TargetProperties.td| 3 ++
10 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/lldb/include/lldb/Target/StackFrame.h
b/lldb/include/lldb/Target/StackFrame.h
index 3881137583b941..03128447b5d496 100644
--- a/lldb/include/lldb/Target/StackFrame.h
+++ b/lldb/include/lldb/Target/StackFrame.h
@@ -308,6 +308,35 @@ class StackFrame : public ExecutionContextScope,
llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
uint32_t options, lldb::VariableSP &var_sp, Status &error);
+ /// Create a ValueObject for a variable name / pathname, possibly including
+ /// simple dereference/child selection syntax.
+ ///
+ /// \param[in] var_expr
+ /// The string specifying a variable to base the VariableObject off
+ /// of.
+ ///
+ /// \param[in] use_dynamic
+ /// Whether the correct dynamic type of an object pointer should be
+ /// determined before creating the object, or if the static type is
+ /// sufficient. One of the DynamicValueType enumerated values.
+ ///
+ /// \param[in] options
+ /// An unsigned integer of flags, values from
+ /// StackFrame::ExpressionPathOption
+ /// enum.
+ /// \param[in] var_sp
+ /// A VariableSP that will be set to the variable described in the
+ /// var_expr path.
+ ///
+ /// \param[in] error
+ /// Record any errors encountered while evaluating var_expr.
+ ///
+ /// \return
+ /// A shared pointer to the ValueObject described by var_expr.
+ lldb::ValueObjectSP DILEvaluateVariableExpression(
+ llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
+ uint32_t options, lldb::VariableSP &var_sp, Status &error);
+
/// Determine whether this StackFrame has debug information available or not.
///
/// \return
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index cab21c29a7486f..b5becfb0e4fe17 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -252,6 +252,10 @@ class TargetProperties : public Properties {
bool GetInjectLocalVariables(ExecutionContext *exe_ctx) const;
+ bool GetUseDIL(ExecutionContext *exe_ctx) const;
+
+ void SetUseDIL(ExecutionContext *exe_ctx, bool b);
+
void SetRequireHardwareBreakpoints(bool b);
bool GetRequireHardwareBreakpoints() const;
diff --git a/lldb/source/API/SBFrame.cpp b/lldb/source/API/SBFrame.cpp
index dc41e80b457d7d..4e3e47b7a5f60b 100644
--- a/lldb/source/API/SBFrame.cpp
+++ b/lldb/source/API/SBFrame.cpp
@@ -472,6 +472,7 @@ lldb::SBValue SBFrame::GetValueForVariablePath(const char
*var_path,
StackFrame *frame = nullptr;
Target *target = exe_ctx.GetTargetPtr();
Process *process = exe_ctx.GetProcessPtr();
+ bool use_DIL = target->GetUseDIL(&exe_ctx);
if (target && process) {
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process->GetRunLock())) {
@@ -479,11 +480,22 @@ lldb::SBValue SBFrame::GetValueForVariablePath(const char
*var_path,
if (frame) {
VariableSP var_sp;
Status error;
-ValueObjectSP value_sp(frame->GetValueForVariableExpressionPath(
-var_path, eNoDynamicValues,
-StackFrame::eExpressionPathOptionCheckPtrVsMember |
-StackFrame::eExpressionPathOptionsAllowDirectIVarAccess,
-var_sp, error));
+ValueObjectSP value_sp;
+if (use_DIL) {
+ // Use DIL parser/evaluator.
+ value_sp = frame->DILEvaluateVariableExpression(
+
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -56,8 +56,19 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE
&parent_die,
if (auto frame = exe_ctx->GetFrameSP()) {
Status error;
lldb::VariableSP var_sp;
- auto valobj_sp = frame->GetValueForVariableExpressionPath(
- var_die.GetName(), eNoDynamicValues, 0, var_sp, error);
+ lldb::TargetSP target_sp = frame->CalculateTarget();
+ bool use_DIL = target_sp->GetUseDIL(
+ (lldb_private::ExecutionContext *)exe_ctx);
cmtice wrote:
This code & cast are gone now.
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 39b2979 - [lldb] Fix source display for artificial locations (#115876)
Author: Pavel Labath
Date: 2024-11-13T09:56:00+01:00
New Revision: 39b2979a434e70a4ce76d4adf91572dcfc9662ff
URL:
https://github.com/llvm/llvm-project/commit/39b2979a434e70a4ce76d4adf91572dcfc9662ff
DIFF:
https://github.com/llvm/llvm-project/commit/39b2979a434e70a4ce76d4adf91572dcfc9662ff.diff
LOG: [lldb] Fix source display for artificial locations (#115876)
When retrieving the location of the function declaration, we were
dropping the file component on the floor, which resulted in an amusingly
confusing situation were we displayed the file containing the
implementation of the function, but used the line number of the
declaration. This patch fixes that.
It required a small refactor Function::GetStartLineSourceLineInfo to
return a SupportFile (instead of just the file spec), which in turn
necessitated changes in a couple of other places as well.
Added:
lldb/test/API/source-manager/artificial_location.cpp
lldb/test/API/source-manager/artificial_location.h
Modified:
lldb/include/lldb/Symbol/Function.h
lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
lldb/source/Commands/CommandObjectSource.cpp
lldb/source/Core/Disassembler.cpp
lldb/source/Symbol/Function.cpp
lldb/source/Target/StackFrame.cpp
lldb/test/API/source-manager/TestSourceManager.py
Removed:
lldb/test/API/source-manager/artificial_location.c
diff --git a/lldb/include/lldb/Symbol/Function.h
b/lldb/include/lldb/Symbol/Function.h
index bbfc25fe74ea06..70f51a846f8d96 100644
--- a/lldb/include/lldb/Symbol/Function.h
+++ b/lldb/include/lldb/Symbol/Function.h
@@ -457,7 +457,8 @@ class Function : public UserID, public SymbolContextScope {
///
/// \param[out] line_no
/// The line number.
- void GetStartLineSourceInfo(FileSpec &source_file, uint32_t &line_no);
+ void GetStartLineSourceInfo(lldb::SupportFileSP &source_file_sp,
+ uint32_t &line_no);
/// Find the file and line number of the source location of the end of the
/// function.
diff --git a/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
b/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
index 8e7386df03e9bf..a94e9e23163d3e 100644
--- a/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
+++ b/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
@@ -139,21 +139,23 @@ void
BreakpointResolverFileLine::FilterContexts(SymbolContextList &sc_list) {
if (!sc.block)
continue;
-FileSpec file;
+SupportFileSP file_sp;
uint32_t line;
const Block *inline_block = sc.block->GetContainingInlinedBlock();
if (inline_block) {
const Declaration &inline_declaration =
inline_block->GetInlinedFunctionInfo()->GetDeclaration();
if (!inline_declaration.IsValid())
continue;
- file = inline_declaration.GetFile();
+ file_sp = std::make_shared(inline_declaration.GetFile());
line = inline_declaration.GetLine();
} else if (sc.function)
- sc.function->GetStartLineSourceInfo(file, line);
+ sc.function->GetStartLineSourceInfo(file_sp, line);
else
continue;
-if (file != sc.line_entry.GetFile()) {
+if (!file_sp ||
+!file_sp->Equal(*sc.line_entry.file_sp,
+SupportFile::eEqualFileSpecAndChecksumIfSet)) {
LLDB_LOG(log, "unexpected symbol context file {0}",
sc.line_entry.GetFile());
continue;
@@ -190,7 +192,8 @@ void
BreakpointResolverFileLine::FilterContexts(SymbolContextList &sc_list) {
const int decl_line_is_too_late_fudge = 1;
if (line &&
m_location_spec.GetLine() < line - decl_line_is_too_late_fudge) {
- LLDB_LOG(log, "removing symbol context at {0}:{1}", file, line);
+ LLDB_LOG(log, "removing symbol context at {0}:{1}",
+ file_sp->GetSpecOnly(), line);
sc_list.RemoveContextAtIndex(i);
--i;
}
diff --git a/lldb/source/Commands/CommandObjectSource.cpp
b/lldb/source/Commands/CommandObjectSource.cpp
index 86c090f9f36c16..c8295fd10cf221 100644
--- a/lldb/source/Commands/CommandObjectSource.cpp
+++ b/lldb/source/Commands/CommandObjectSource.cpp
@@ -784,9 +784,7 @@ class CommandObjectSourceList : public CommandObjectParsed {
if (sc.block == nullptr) {
// Not an inlined function
-FileSpec function_file_spec;
-sc.function->GetStartLineSourceInfo(function_file_spec, start_line);
-start_file = std::make_shared(function_file_spec);
+sc.function->GetStartLineSourceInfo(start_file, start_line);
if (start_line == 0) {
result.AppendErrorWithFormat("Could not find line information for "
"start of function: \"%s\".\n",
diff --git a/lldb/source/Core/Disassembler.cpp
b/lldb/source/Core/Disassembler.cpp
index 522a3ef2efc334..68e52144eb6ef8 100644
--- a/lldb/source/Core/Disassembler.cpp
+++ b/lldb/source
[Lldb-commits] [lldb] [lldb] Fix source display for artificial locations (PR #115876)
@@ -0,0 +1,8 @@
+#include "artificial_location.h"
+
+int A::foo() {
+#line 0
labath wrote:
Thanks for the pointer. Quite a coincidence that I end up touching the same
test just as Jaremy ends up breaking it :P
https://github.com/llvm/llvm-project/pull/115876
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Fix inline_sites_live.cpp Shell when run on Linux remotely from Windows (PR #115722)
https://github.com/dzhidzhoev edited https://github.com/llvm/llvm-project/pull/115722 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Handle an empty SBMemoryRegionInfo from scripted process (PR #115963)
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/115963
>From f8f1d70d1d9eac6d36c0fa84e2a94c032385da39 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Tue, 12 Nov 2024 15:55:15 -0800
Subject: [PATCH 1/4] [lldb] Handle an empty SBMemoryRegionInfo from scripted
process
A scripted process implementation might return an SBMemoryRegionInfo
object in its implementation of `get_memory_region_containing_address`
which will have an address 0 and size 0, without realizing the
problems this can cause. One problem happens when an expression
is run, and lldb needs to find part of the target's virtual address
space to store the result (actually stored in lldb's host memory),
it uses IRMemoryMap::FindSpace() to do that. If the process supports
GetMemoryRegionInfo, FindSpace will step through the allocated
memory ranges looking for an unused one. But if every request is
a memory region with address 0 + size 0, this loop will never
terminate. Detect this kind of response from a scripted process
plugin and return an error, so callers iterating over the address
space can exit.
Added a test where I copied dummy_scripted_process.py from the
TestScriptedProcess.py existing test, and added a bad
`get_memory_region_containing_address` implementation.
rdar://139678032
---
.../Process/scripted/ScriptedProcess.cpp | 9 +-
.../Makefile | 3 +
.../TestScriptedProcessEmptyMemoryRegion.py | 33 +
.../dummy_scripted_process.py | 137 ++
.../main.c| 1 +
5 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644
lldb/test/API/functionalities/scripted_process_empty_memory_region/Makefile
create mode 100644
lldb/test/API/functionalities/scripted_process_empty_memory_region/TestScriptedProcessEmptyMemoryRegion.py
create mode 100644
lldb/test/API/functionalities/scripted_process_empty_memory_region/dummy_scripted_process.py
create mode 100644
lldb/test/API/functionalities/scripted_process_empty_memory_region/main.c
diff --git a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
index d2111ce877ce55..c56e24a4ebd188 100644
--- a/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
+++ b/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, error))
+ GetInterface().GetMemoryRegionContainingAddress(load_addr, error)) {
region = *region_or_err;
+if (region.GetRange().GetRangeBase() == 0 &&
+(region.GetRange().GetByteSize() == 0 ||
+ region.GetRange().GetByteSize() == LLDB_INVALID_ADDRESS)) {
+ error = Status::FromErrorString(
+ "Invalid memory region from scripted process");
+}
+ }
return error;
}
diff --git
a/lldb/test/API/functionalities/scripted_process_empty_memory_region/Makefile
b/lldb/test/API/functionalities/scripted_process_empty_memory_region/Makefile
new file mode 100644
index 00..10495940055b63
--- /dev/null
+++
b/lldb/test/API/functionalities/scripted_process_empty_memory_region/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
diff --git
a/lldb/test/API/functionalities/scripted_process_empty_memory_region/TestScriptedProcessEmptyMemoryRegion.py
b/lldb/test/API/functionalities/scripted_process_empty_memory_region/TestScriptedProcessEmptyMemoryRegion.py
new file mode 100644
index 00..1ff084cfb0278e
--- /dev/null
+++
b/lldb/test/API/functionalities/scripted_process_empty_memory_region/TestScriptedProcessEmptyMemoryRegion.py
@@ -0,0 +1,33 @@
+"""
+Test python scripted process which returns an empty SBMemoryRegionInfo
+"""
+
+import os, shutil
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbtest
+
+
+class ScriptedProcessEmptyMemoryRegion(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_scripted_process_empty_memory_region(self):
+"""Test that lldb handles an empty SBMemoryRegionInfo object from
+a scripted process plugin."""
+self.build()
+
+target = self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
+self.assertTrue(target, VALID_TARGET)
+
+scripted_process_example_relpath = "dummy_scripted_process.py"
+self.runCmd(
+"command script import "
++ os.path.join(self.getSourceDir(),
scripted_process_example_relpath)
+)
+
+self.expect("memory region 0", error=True, substrs=["Invalid memory
region"])
+
+self.expect("expr -- 5", substrs=["5"])
diff --git
a/lldb/test/API/f
[Lldb-commits] [lldb] [lldb] Remove broken comments originally written as table headers (NFC) (PR #116089)
https://github.com/kastiglione created
https://github.com/llvm/llvm-project/pull/116089
Automatic formatting has removed the utility of these comments.
>From ae7f7d7e2167743f68118d1342cdb907ad478a95 Mon Sep 17 00:00:00 2001
From: Dave Lee
Date: Wed, 13 Nov 2024 10:24:38 -0800
Subject: [PATCH] [lldb] Remove broken comments originally written as table
headers (NFC)
Automatic formatting has removed the utility of these comments.
---
lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp | 6 --
lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp| 7 ---
lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp | 6 --
lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp| 6 --
.../Plugins/Process/Utility/RegisterContextDarwin_arm.cpp | 7 ---
.../Plugins/Process/Utility/RegisterContextDarwin_i386.cpp | 5 -
.../Process/Utility/RegisterContextDarwin_x86_64.cpp | 5 -
lldb/source/Plugins/Process/Utility/RegisterInfos_arm.h| 7 ---
.../Windows/Common/x64/RegisterContextWindows_x64.cpp | 6 --
.../Windows/Common/x86/RegisterContextWindows_x86.cpp | 6 --
10 files changed, 61 deletions(-)
diff --git a/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
b/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
index 08c613c7b0d0c3..6aadf652da7813 100644
--- a/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
+++ b/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
@@ -36,12 +36,6 @@ using namespace lldb;
using namespace lldb_private;
static const RegisterInfo g_register_infos[] = {
-// NAME ALT SZ OFF ENCODING FORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVE
-// == === == === =
-// === === ===
-// === ==
{"r0",
nullptr,
4,
diff --git a/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
b/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
index 1a0e44f1936b8d..d67591ffa109bc 100644
--- a/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
+++ b/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
@@ -38,13 +38,6 @@ using namespace lldb_private;
LLDB_PLUGIN_DEFINE(ABISysV_arm)
static const RegisterInfo g_register_infos[] = {
-// NAME ALT SZ OFF ENCODING FORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVEVALUE REGSINVALIDATE REGS
-// == === == === =
-// === === ===
-// === == ==
-// ===
{"r0",
nullptr,
4,
diff --git a/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
b/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
index d21ee8ac04a212..9c7312b975c4b6 100644
--- a/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
+++ b/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
@@ -78,12 +78,6 @@ enum dwarf_regnums {
};
static const RegisterInfo g_register_infos[] = {
-// NAME ALTSZ OFF ENCODINGFORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGINS
-// LLDB NATIVEVALUE REGS INVALIDATE REGS
-// == == === = ===
-// == =
-// === == =
{"r0",
"zero",
4,
diff --git a/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
b/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
index 100d52bfd1c8ba..4cc37dd7acf09e 100644
--- a/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
+++ b/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
@@ -78,12 +78,6 @@ enum dwarf_regnums {
};
static const RegisterInfo g_register_infos_mips64[] = {
-// NAME ALTSZ OFF ENCODINGFORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVE
-// == == === = == =
-// = =
-//
{"r0",
"zero",
8,
diff --git a/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
b/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
index c23e82a741a0ae..094b46bf861df7 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
@@ -184,13 +184,6 @@ enum {
sizeof(RegisterContextDarwin_arm::EXC))
static RegisterInfo g_register_infos[] = {
-// General purpose registers
-// NAMEALT SZ OFFSET ENCODINGFORMAT
-//
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/slydiman reopened https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/slydiman ready_for_review https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Handle an empty SBMemoryRegionInfo from scripted process (PR #115963)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff b0a4e958e85784cff46303c92b6a3a14b20fa1d8
aadf21dddfd0f053956b93cd431272e3f237d646 --extensions c,cpp --
lldb/test/API/functionalities/scripted_process_empty_memory_region/main.c
lldb/source/Target/Process.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index ba4701e266..5a847782ab 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -6190,8 +6190,7 @@ Status Process::GetMemoryRegionInfo(lldb::addr_t
load_addr,
if (error.Success() && range_info.GetRange().GetRangeBase() == 0 &&
(range_info.GetRange().GetByteSize() == 0 ||
range_info.GetRange().GetByteSize() == UINT64_MAX))
-error =
-Status::FromErrorString("Invalid memory region");
+error = Status::FromErrorString("Invalid memory region");
return error;
}
``
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Refactor lldb-dap/DAP.{h, cpp} to use its own instance instead of the global instance. (PR #115948)
https://github.com/walter-erquinigo approved this pull request. https://github.com/llvm/llvm-project/pull/115948 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/walter-erquinigo approved this pull request. thanks! https://github.com/llvm/llvm-project/pull/116045 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c658d07 - [lldb-dap] Adjust the evaluate test to use a different lldb command. (#116045)
Author: John Harrison
Date: 2024-11-13T11:17:07-08:00
New Revision: c658d07c4f8210555473c5721e1302f00f9fd25b
URL:
https://github.com/llvm/llvm-project/commit/c658d07c4f8210555473c5721e1302f00f9fd25b
DIFF:
https://github.com/llvm/llvm-project/commit/c658d07c4f8210555473c5721e1302f00f9fd25b.diff
LOG: [lldb-dap] Adjust the evaluate test to use a different lldb command.
(#116045)
Previously this used `var` as both an lldb command and variable in the
source to validate the behavior of the 'auto' repl mode. However, `var`
seems to occasionally fail in the CI test when attempting to print some
c++ types. Instead switch the command and variable name to `list` which
should not run the dynamic variable formatting code for c++ objects.
This should fix #116041.
Added:
Modified:
lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
lldb/test/API/tools/lldb-dap/evaluate/main.cpp
Removed:
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 0126d40d86fca2..251d77d79d0800 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
self.assertEvaluateFailure("my_struct") # type name
self.assertEvaluateFailure("int") # type name
@@ -162,7 +162,7 @@ def run_test_evaluate_expressions(
# Expressions at breakpoint 3, which is inside a_function
self.continue_to_next_stop()
-self.assertEvaluate("var", "42")
+self.assertEvaluate("list", "42")
self.assertEvaluate("static_int", "42")
self.assertEvaluate("non_static_int", "43")
@@ -176,13 +176,13 @@ def run_test_evaluate_expressions(
if self.isExpressionParsedExpected():
self.assertEvaluate("a_function", "0x.*a.out`a_function.*")
self.assertEvaluate("a_function(1)", "1")
-self.assertEvaluate("var + 1", "43")
+self.assertEvaluate("list + 1", "43")
self.assertEvaluate("foo_func", "0x.*a.out`foo_func.*")
self.assertEvaluate("foo_var", "44")
else:
self.assertEvaluateFailure("a_function")
self.assertEvaluateFailure("a_function(1)")
-self.assertEvaluateFailure("var + 1")
+self.assertEvaluateFailure("list + 1")
self.assertEvaluateFailure("foo_func")
self.assertEvaluateFailure("foo_var")
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
index 1c68716e3a6e11..1c3d258114b1ff 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
@@ -8,8 +8,8 @@ static int static_int = 42;
int non_static_int = 43;
-int a_function(int var) {
- return var; // breakpoint 3
+int a_function(int list) {
+ return list; // breakpoint 3
}
struct my_struct {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove broken comments originally written as table headers (NFC) (PR #116089)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dave Lee (kastiglione)
Changes
Automatic formatting has removed the utility of these comments.
---
Full diff: https://github.com/llvm/llvm-project/pull/116089.diff
10 Files Affected:
- (modified) lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp (-6)
- (modified) lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp (-7)
- (modified) lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp (-6)
- (modified) lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp (-6)
- (modified) lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
(-7)
- (modified) lldb/source/Plugins/Process/Utility/RegisterContextDarwin_i386.cpp
(-5)
- (modified)
lldb/source/Plugins/Process/Utility/RegisterContextDarwin_x86_64.cpp (-5)
- (modified) lldb/source/Plugins/Process/Utility/RegisterInfos_arm.h (-7)
- (modified)
lldb/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
(-6)
- (modified)
lldb/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
(-6)
``diff
diff --git a/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
b/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
index 08c613c7b0d0c3..6aadf652da7813 100644
--- a/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
+++ b/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
@@ -36,12 +36,6 @@ using namespace lldb;
using namespace lldb_private;
static const RegisterInfo g_register_infos[] = {
-// NAME ALT SZ OFF ENCODING FORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVE
-// == === == === =
-// === === ===
-// === ==
{"r0",
nullptr,
4,
diff --git a/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
b/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
index 1a0e44f1936b8d..d67591ffa109bc 100644
--- a/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
+++ b/lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
@@ -38,13 +38,6 @@ using namespace lldb_private;
LLDB_PLUGIN_DEFINE(ABISysV_arm)
static const RegisterInfo g_register_infos[] = {
-// NAME ALT SZ OFF ENCODING FORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVEVALUE REGSINVALIDATE REGS
-// == === == === =
-// === === ===
-// === == ==
-// ===
{"r0",
nullptr,
4,
diff --git a/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
b/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
index d21ee8ac04a212..9c7312b975c4b6 100644
--- a/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
+++ b/lldb/source/Plugins/ABI/Mips/ABISysV_mips.cpp
@@ -78,12 +78,6 @@ enum dwarf_regnums {
};
static const RegisterInfo g_register_infos[] = {
-// NAME ALTSZ OFF ENCODINGFORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGINS
-// LLDB NATIVEVALUE REGS INVALIDATE REGS
-// == == === = ===
-// == =
-// === == =
{"r0",
"zero",
4,
diff --git a/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
b/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
index 100d52bfd1c8ba..4cc37dd7acf09e 100644
--- a/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
+++ b/lldb/source/Plugins/ABI/Mips/ABISysV_mips64.cpp
@@ -78,12 +78,6 @@ enum dwarf_regnums {
};
static const RegisterInfo g_register_infos_mips64[] = {
-// NAME ALTSZ OFF ENCODINGFORMAT EH_FRAME
-// DWARF GENERIC PROCESS PLUGIN
-// LLDB NATIVE
-// == == === = == =
-// = =
-//
{"r0",
"zero",
8,
diff --git a/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
b/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
index c23e82a741a0ae..094b46bf861df7 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
@@ -184,13 +184,6 @@ enum {
sizeof(RegisterContextDarwin_arm::EXC))
static RegisterInfo g_register_infos[] = {
-// General purpose registers
-// NAMEALT SZ OFFSET ENCODINGFORMAT
-// EH_FRAMEDWARF GENERIC
-// PROCESS PLUGIN LLDB NATIVE
-// == === == =
[Lldb-commits] [lldb] a6d299d - [lldb-dap] Refactor lldb-dap/DAP.{h, cpp} to use its own instance instead of the global instance. (#115948)
Author: John Harrison
Date: 2024-11-13T11:17:50-08:00
New Revision: a6d299ddb9398e4641b23ce5c549ca5285dd2ef2
URL:
https://github.com/llvm/llvm-project/commit/a6d299ddb9398e4641b23ce5c549ca5285dd2ef2
DIFF:
https://github.com/llvm/llvm-project/commit/a6d299ddb9398e4641b23ce5c549ca5285dd2ef2.diff
LOG: [lldb-dap] Refactor lldb-dap/DAP.{h,cpp} to use its own instance instead
of the global instance. (#115948)
The refactor will unblock us for creating multiple DAP instances.
Added:
Modified:
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/lldb-dap.cpp
Removed:
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 10d2d5d79a74bf..bdb24fc78cfb64 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -477,12 +477,12 @@ lldb::SBFrame DAP::GetLLDBFrame(const llvm::json::Object
&arguments) {
llvm::json::Value DAP::CreateTopLevelScopes() {
llvm::json::Array scopes;
- scopes.emplace_back(CreateScope("Locals", VARREF_LOCALS,
- g_dap.variables.locals.GetSize(), false));
+ scopes.emplace_back(
+ CreateScope("Locals", VARREF_LOCALS, variables.locals.GetSize(), false));
scopes.emplace_back(CreateScope("Globals", VARREF_GLOBALS,
- g_dap.variables.globals.GetSize(), false));
+ variables.globals.GetSize(), false));
scopes.emplace_back(CreateScope("Registers", VARREF_REGS,
- g_dap.variables.registers.GetSize(), false));
+ variables.registers.GetSize(), false));
return llvm::json::Value(std::move(scopes));
}
@@ -490,8 +490,8 @@ ReplMode DAP::DetectReplMode(lldb::SBFrame frame,
std::string &expression,
bool partial_expression) {
// Check for the escape hatch prefix.
if (!expression.empty() &&
- llvm::StringRef(expression).starts_with(g_dap.command_escape_prefix)) {
-expression = expression.substr(g_dap.command_escape_prefix.size());
+ llvm::StringRef(expression).starts_with(command_escape_prefix)) {
+expression = expression.substr(command_escape_prefix.size());
return ReplMode::Command;
}
@@ -531,7 +531,7 @@ ReplMode DAP::DetectReplMode(lldb::SBFrame frame,
std::string &expression,
<< "Warning: Expression '" << term
<< "' is both an LLDB command and variable. It will be evaluated as "
"a variable. To evaluate the expression as an LLDB command, use '"
- << g_dap.command_escape_prefix << "' as a prefix.\n";
+ << command_escape_prefix << "' as a prefix.\n";
}
// Variables take preference to commands in auto, since commands can always
@@ -901,7 +901,7 @@ bool StartDebuggingRequestHandler::DoExecute(
return false;
}
- g_dap.SendReverseRequest(
+ dap.SendReverseRequest(
"startDebugging",
llvm::json::Object{{"request", request},
{"configuration", std::move(*configuration)}},
@@ -925,7 +925,7 @@ bool ReplModeRequestHandler::DoExecute(lldb::SBDebugger
debugger,
// If a new mode is not specified report the current mode.
if (!command || llvm::StringRef(command[0]).empty()) {
std::string mode;
-switch (g_dap.repl_mode) {
+switch (dap.repl_mode) {
case ReplMode::Variable:
mode = "variable";
break;
@@ -946,11 +946,11 @@ bool ReplModeRequestHandler::DoExecute(lldb::SBDebugger
debugger,
llvm::StringRef new_mode{command[0]};
if (new_mode == "variable") {
-g_dap.repl_mode = ReplMode::Variable;
+dap.repl_mode = ReplMode::Variable;
} else if (new_mode == "command") {
-g_dap.repl_mode = ReplMode::Command;
+dap.repl_mode = ReplMode::Command;
} else if (new_mode == "auto") {
-g_dap.repl_mode = ReplMode::Auto;
+dap.repl_mode = ReplMode::Auto;
} else {
lldb::SBStream error_message;
error_message.Printf("Invalid repl-mode '%s'. Expected one of 'variable', "
@@ -1022,7 +1022,7 @@ bool SendEventRequestHandler::DoExecute(lldb::SBDebugger
debugger,
event.try_emplace("body", std::move(*body));
}
- g_dap.SendJSON(llvm::json::Value(std::move(event)));
+ dap.SendJSON(llvm::json::Value(std::move(event)));
result.SetStatus(lldb::eReturnStatusSuccessFinishNoResult);
return true;
}
@@ -1031,14 +1031,13 @@ void DAP::SetFrameFormat(llvm::StringRef format) {
if (format.empty())
return;
lldb::SBError error;
- g_dap.frame_format = lldb::SBFormat(format.str().c_str(), error);
+ frame_format = lldb::SBFormat(format.str().c_str(), error);
if (error.Fail()) {
-g_dap.SendOutput(
-OutputType::Console,
-llvm::formatv(
-"The provided frame format '{0}' couldn't be parsed: {1}\n",
format,
-error.GetCString())
-.str());
+SendOutput(OutputType::
[Lldb-commits] [lldb] [lldb-dap] Refactor lldb-dap/DAP.{h, cpp} to use its own instance instead of the global instance. (PR #115948)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/115948 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/ashgti closed https://github.com/llvm/llvm-project/pull/116045 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
slydiman wrote: It is the last show stopper https://lab.llvm.org/staging/#/builders/197/builds/289 https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/Michael137 commented: Thanks for the quick fix. I'll let @walter-erquinigo give the final approval here as the original author of this test. https://github.com/llvm/llvm-project/pull/116045 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/ashgti edited https://github.com/llvm/llvm-project/pull/116045 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
Michael137 wrote:
Why does evaluating `list` in `a_function` fail?
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
Michael137 wrote:
Is the comment here now outdated?
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
ashgti wrote:
In the Debug Adapter Protocol `evaluate` request
(https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Evaluate)
the `context` changes whether we're looking for variables in the current frame
or lldb commands. If the context is `repl` then we'll try to evaluate
expressions as lldb commands, otherwise if the context is
`hover`/`watch`/`variables` then we only look for variables in the current
scope.
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/116045
Previously this used `var` as both an lldb command and variable in the source
to validate the behavior of the 'auto' repl mode. However, `var` seems to
occasionally fail in the CI test when attempting to print some c++ types.
Instead switch the command and variable name to `list` which should not run the
dynamic variable formatting code for c++ objects.
This should fix #116041.
>From c0663c53f0fad4a0afb20ec93a05151c5a1ae37f Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Wed, 13 Nov 2024 08:24:38 -0500
Subject: [PATCH] [lldb-dap] Adjust the evaluate test to use a different lldb
command.
Previously this used `var` as both an lldb command and variable in the source
to validate the behavior of the 'auto' repl mode. However, `var` seems to
occasionally fail in the CI test when attempting to print some c++ types.
Instead switch the command and variable name to `list` which should not run the
dynamic variable formatting code for c++ objects.
---
.../API/tools/lldb-dap/evaluate/TestDAP_evaluate.py| 10 +-
lldb/test/API/tools/lldb-dap/evaluate/main.cpp | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 0126d40d86fca2..251d77d79d0800 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
self.assertEvaluateFailure("my_struct") # type name
self.assertEvaluateFailure("int") # type name
@@ -162,7 +162,7 @@ def run_test_evaluate_expressions(
# Expressions at breakpoint 3, which is inside a_function
self.continue_to_next_stop()
-self.assertEvaluate("var", "42")
+self.assertEvaluate("list", "42")
self.assertEvaluate("static_int", "42")
self.assertEvaluate("non_static_int", "43")
@@ -176,13 +176,13 @@ def run_test_evaluate_expressions(
if self.isExpressionParsedExpected():
self.assertEvaluate("a_function", "0x.*a.out`a_function.*")
self.assertEvaluate("a_function(1)", "1")
-self.assertEvaluate("var + 1", "43")
+self.assertEvaluate("list + 1", "43")
self.assertEvaluate("foo_func", "0x.*a.out`foo_func.*")
self.assertEvaluate("foo_var", "44")
else:
self.assertEvaluateFailure("a_function")
self.assertEvaluateFailure("a_function(1)")
-self.assertEvaluateFailure("var + 1")
+self.assertEvaluateFailure("list + 1")
self.assertEvaluateFailure("foo_func")
self.assertEvaluateFailure("foo_var")
diff --git a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
index 1c68716e3a6e11..1c3d258114b1ff 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
@@ -8,8 +8,8 @@ static int static_int = 42;
int non_static_int = 43;
-int a_function(int var) {
- return var; // breakpoint 3
+int a_function(int list) {
+ return list; // breakpoint 3
}
struct my_struct {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
ashgti wrote:
Its still applicable, we're just using a different lldb variable name to shadow
`list` instead of `var`.
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Adjust the evaluate test to use a different lldb command. (PR #116045)
@@ -101,9 +101,9 @@ def run_test_evaluate_expressions(
if context == "repl":
# In the repl context expressions may be interpreted as lldb
# commands since no variables have the same name as the command.
-self.assertEvaluate("var", r"\(lldb\) var\n.*")
+self.assertEvaluate("list", r"\(lldb\) list\n.*")
else:
-self.assertEvaluateFailure("var") # local variable of a_function
+self.assertEvaluateFailure("list") # local variable of a_function
ashgti wrote:
Its also worth noting that we're at breakpoint 1 here, which is in `main` (line
25), not `a_function` (breakpoint 3, line 12), so the variable `list` is out of
scope.
https://github.com/llvm/llvm-project/pull/116045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
@@ -169,6 +169,38 @@ Status ProcessWindows::DoDetach(bool keep_stopped) {
Log *log = GetLog(WindowsLog::Process);
StateType private_state = GetPrivateState();
if (private_state != eStateExited && private_state != eStateDetached) {
+if (!keep_stopped) {
+ // if the thread is suspended by lldb, we have to resume threads before
+ // detaching process. When we do after DetachProcess(), thread handles
+ // become invalid so we do before detach.
+ if (private_state == eStateStopped || private_state == eStateCrashed) {
+LLDB_LOG(log, "process {0} is in state {1}. Resuming for detach...",
+ m_session_data->m_debugger->GetProcess().GetProcessId(),
+ GetPrivateState());
+
+LLDB_LOG(log, "resuming {0} threads for detach.",
+ m_thread_list.GetSize());
+
+bool failed = false;
+for (uint32_t i = 0; i < m_thread_list.GetSize(); ++i) {
+ auto thread = std::static_pointer_cast(
+ m_thread_list.GetThreadAtIndex(i));
+ Status result = thread->DoResume();
labath wrote:
> No, the process will not suspend.
> The process will receive the exception and the process handles it instead.
Ok, just so we're clear: If the exception happens after the last call to
`WaitForDebugEvent` (but before the call to `DebugActiveProcessStop`), the
process will *not* stay stopped, but it will receive the exception (and then
either handle it or get killed by it). True or false?
https://github.com/llvm/llvm-project/pull/115712
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove broken comments originally written as table headers (NFC) (PR #116089)
https://github.com/jasonmolenda approved this pull request. LGTM, this is surely fallout from the 80 column reformat of '16, where these tables used to have standard column positions (and very long lines). https://github.com/llvm/llvm-project/pull/116089 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove broken comments originally written as table headers (NFC) (PR #116089)
https://github.com/JDevlieghere approved this pull request. LGTM. https://github.com/llvm/llvm-project/pull/116089 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support overriding the disassembly CPU & features (PR #115382)
@@ -157,6 +157,12 @@ let Definition = "target" in {
DefaultEnumValue<"eX86DisFlavorDefault">,
EnumValues<"OptionEnumValues(g_x86_dis_flavor_value_types)">,
Desc<"The default disassembly flavor to use for x86 or x86-64 targets.">;
+ def DisassemblyCPU: Property<"disassembly-cpu", "String">,
+DefaultStringValue<"">,
+Desc<"Override the CPU for disassembling. Takes the same values as the
-mcpu compiler flag.">;
+ def DisassemblyFeatures: Property<"disassembly-features", "String">,
+DefaultStringValue<"">,
+Desc<"Specify additional CPU features for disassembling.">;
jasonmolenda wrote:
Oh, that's helpful, yes I was talking to Jonas about how you have to read the
RISCVFeatures.td table in the llvm sources to get the names that llvm uses for
the ISA extensions there, but we didn't want to document that. I didn't
realize there was a commandline way of dumping them.
https://github.com/llvm/llvm-project/pull/115382
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)
jimingham wrote: > FWIW, I also think that having "continue" go sometimes backwards would be > very confusing. If we only have forward execution, then the difference > between "run forwards" and "resume the current thread plan (forwards)" is not > big. However, the difference between "run forwards" and "resume current plan > **backwards**" is huge, and I think we should avoid the possibility of > confusing the two (for example, by requiring an explicit direction argument > if the current thread plan wants to go backwards). The problem I see with this is that the two operations really are: 1) Continue to do whatever I was doing in the direction I was doing it 2) Reverse direction When you reverse direction, you suspend and at some point possibly invalidate all the plans you were doing going in the previous direction, and start building up a new stack of intentions. That is going to happen each time you switch directions. That's why it makes more sense to me to have `continue` mean (1), and to have a more explicit gesture for switching direction. I must admit, I'm not so moved by "how much this will surprise people who don't know how lldb works..." It doesn't seem like such a difficult concept we should be bound by that... https://github.com/llvm/llvm-project/pull/112079 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support overriding the disassembly CPU & features (PR #115382)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/115382 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Function::GetAddress and redirect some uses (PR #115836)
https://github.com/jasonmolenda approved this pull request. LGTM, simple mechanical update. Apologies for not looking at the earlier PR for discontiguous range Functions. https://github.com/llvm/llvm-project/pull/115836 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Handle an empty SBMemoryRegionInfo from scripted process (PR #115963)
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, error))
+ GetInterface().GetMemoryRegionContainingAddress(load_addr, error)) {
region = *region_or_err;
+if (region.GetRange().GetRangeBase() == 0 &&
+(region.GetRange().GetByteSize() == 0 ||
+ region.GetRange().GetByteSize() == LLDB_INVALID_ADDRESS)) {
jasonmolenda wrote:
We had a gdb stub returning {0, UINT64_MAX} the other week and it broke
IRMemory::FindSpace() which will avoid any memory region with
read/write/execute flags if qMemoryRegionInfo packets are supported. The stub
claimed the entire address space, FindSpace() said it could not find any
address range available, and all expressions broke.
Yeah, a range of {0, 1} would result in algorithms like FindSpace() looping for
a very long time, and be nearly as bad. But so far the two instances I've seen
of people return bad ranges are {0,0} and {0,UINT64_MAX}.
https://github.com/llvm/llvm-project/pull/115963
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Function::GetAddress and redirect some uses (PR #115836)
@@ -407,6 +406,15 @@ CompileUnit *Function::GetCompileUnit() { return
m_comp_unit; }
const CompileUnit *Function::GetCompileUnit() const { return m_comp_unit; }
+Address Function::GetAddress() const {
+ if (m_ranges.empty())
+return Address();
+ // We're using a (DWARF-like) convention where the base address of the first
+ // interval denotes the entry point of the function. If that turns out to be
+ // insufficient, we can introduce a separate "entry point address" field.
+ return m_ranges[0].GetBaseAddress();
jasonmolenda wrote:
Function::CollapseRanges seems to imply that the first Range may not have the
lowest address of all ranges. Should this return `m_range.GetBaseAddress()`
using `CollapseRanges`'s calculation intsead?
https://github.com/llvm/llvm-project/pull/115836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: Target Process may crash or freezes on detaching process on windows (PR #115712)
anatawa12 wrote: > I'm less sure about this one. Is that due to the breakpoint exception somehow > remaining "pending" and that we need to clear/ignore/suppress it before > detaching? Sorry I don't know the reason of this behavior, but not calling corresponding ContinueDebugEvent for WaitForDebugEvent may cause crash is what I know. It looks leaving some "pending" events / exceptions in queue doesn't trigger problem, but leaving "processing" events / exceptions would cause this problem. --- I misunderstand the behavior a little. Sorry for confusion again. In my previous comment, I said "It think this bug will always happen on detaching process" for second bug but I found that this bug depends on the implementation of target process and a.out from TestDetachResumes would not have this problem. I fixed the previous comment. https://github.com/llvm/llvm-project/pull/115712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
https://github.com/cmtice updated
https://github.com/llvm/llvm-project/pull/115666
>From d757bf7ac49d504707e39fe6f3a0bc93da5aef30 Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Sun, 10 Nov 2024 10:07:22 -0800
Subject: [PATCH 1/4] [LLDB] Add framework for Data Inspection Language (DIL)
work.
Add the framework code for hooking up and calling the Data Inspection Language
(DIL) implementation, as an alternate implementation for the 'frame
variable' command. For now, this is an opt-in option, via a target setting
'target.experimental.use-DIL'. See
https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for more
information about this project.
This PR does not actually call any of the DIL code; instead the piece that will
eventually call the DIL code (StackFrame::DILEvaluateVariableExpression) calls
back into the original 'frame variable' implementation.
---
lldb/include/lldb/Target/StackFrame.h | 29 +++
lldb/include/lldb/Target/Target.h | 4 +++
lldb/source/API/SBFrame.cpp | 22 ++
lldb/source/Commands/CommandObjectFrame.cpp | 19 +---
.../Commands/CommandObjectWatchpoint.cpp | 14 +++--
lldb/source/Expression/UserExpression.cpp | 29 ++-
.../SymbolFile/DWARF/DWARFASTParser.cpp | 15 --
lldb/source/Target/StackFrame.cpp | 9 ++
lldb/source/Target/Target.cpp | 21 ++
lldb/source/Target/TargetProperties.td| 3 ++
10 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/lldb/include/lldb/Target/StackFrame.h
b/lldb/include/lldb/Target/StackFrame.h
index 3881137583b941..03128447b5d496 100644
--- a/lldb/include/lldb/Target/StackFrame.h
+++ b/lldb/include/lldb/Target/StackFrame.h
@@ -308,6 +308,35 @@ class StackFrame : public ExecutionContextScope,
llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
uint32_t options, lldb::VariableSP &var_sp, Status &error);
+ /// Create a ValueObject for a variable name / pathname, possibly including
+ /// simple dereference/child selection syntax.
+ ///
+ /// \param[in] var_expr
+ /// The string specifying a variable to base the VariableObject off
+ /// of.
+ ///
+ /// \param[in] use_dynamic
+ /// Whether the correct dynamic type of an object pointer should be
+ /// determined before creating the object, or if the static type is
+ /// sufficient. One of the DynamicValueType enumerated values.
+ ///
+ /// \param[in] options
+ /// An unsigned integer of flags, values from
+ /// StackFrame::ExpressionPathOption
+ /// enum.
+ /// \param[in] var_sp
+ /// A VariableSP that will be set to the variable described in the
+ /// var_expr path.
+ ///
+ /// \param[in] error
+ /// Record any errors encountered while evaluating var_expr.
+ ///
+ /// \return
+ /// A shared pointer to the ValueObject described by var_expr.
+ lldb::ValueObjectSP DILEvaluateVariableExpression(
+ llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
+ uint32_t options, lldb::VariableSP &var_sp, Status &error);
+
/// Determine whether this StackFrame has debug information available or not.
///
/// \return
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index cab21c29a7486f..b5becfb0e4fe17 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -252,6 +252,10 @@ class TargetProperties : public Properties {
bool GetInjectLocalVariables(ExecutionContext *exe_ctx) const;
+ bool GetUseDIL(ExecutionContext *exe_ctx) const;
+
+ void SetUseDIL(ExecutionContext *exe_ctx, bool b);
+
void SetRequireHardwareBreakpoints(bool b);
bool GetRequireHardwareBreakpoints() const;
diff --git a/lldb/source/API/SBFrame.cpp b/lldb/source/API/SBFrame.cpp
index dc41e80b457d7d..4e3e47b7a5f60b 100644
--- a/lldb/source/API/SBFrame.cpp
+++ b/lldb/source/API/SBFrame.cpp
@@ -472,6 +472,7 @@ lldb::SBValue SBFrame::GetValueForVariablePath(const char
*var_path,
StackFrame *frame = nullptr;
Target *target = exe_ctx.GetTargetPtr();
Process *process = exe_ctx.GetProcessPtr();
+ bool use_DIL = target->GetUseDIL(&exe_ctx);
if (target && process) {
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process->GetRunLock())) {
@@ -479,11 +480,22 @@ lldb::SBValue SBFrame::GetValueForVariablePath(const char
*var_path,
if (frame) {
VariableSP var_sp;
Status error;
-ValueObjectSP value_sp(frame->GetValueForVariableExpressionPath(
-var_path, eNoDynamicValues,
-StackFrame::eExpressionPathOptionCheckPtrVsMember |
-StackFrame::eExpressionPathOptionsAllowDirectIVarAccess,
-var_sp, error));
+ValueObjectSP value_sp;
+if (use_DIL) {
+ // Use DIL parser/evaluator.
+ value_sp = frame->DILEvaluateVariableExpression(
+
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -508,6 +508,32 @@ StackFrame::GetInScopeVariableList(bool get_file_globals,
ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
llvm::StringRef var_expr, DynamicValueType use_dynamic, uint32_t options,
VariableSP &var_sp, Status &error) {
+ // Check to see if we should use the DIL implementation.
+ lldb::TargetSP target_sp = CalculateTarget();
+ ExecutionContext exe_ctx;
+ CalculateExecutionContext(exe_ctx);
+ bool use_DIL = target_sp->GetUseDIL(&exe_ctx);
cmtice wrote:
Done.
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -304,6 +304,42 @@ class StackFrame : public ExecutionContextScope, /// /// \return /// A shared pointer to the ValueObject described by var_expr. + lldb::ValueObjectSP LegacyGetValueForVariableExpressionPath( + llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic, + uint32_t options, lldb::VariableSP &var_sp, Status &error); + + /// Create a ValueObject for a variable name / pathname, possibly including + /// simple dereference/child selection syntax. + /// + /// \param[in] var_expr + /// The string specifying a variable to base the VariableObject off + /// of. + /// + /// \param[in] use_dynamic + /// Whether the correct dynamic type of an object pointer should be + /// determined before creating the object, or if the static type is + /// sufficient. One of the DynamicValueType enumerated values. + /// + /// \param[in] options + /// An unsigned integer of flags, values from + /// StackFrame::ExpressionPathOption + /// enum. + /// \param[in] var_sp + /// A VariableSP that will be set to the variable described in the + /// var_expr path. + /// + /// \param[in] error + /// Record any errors encountered while evaluating var_expr. + /// + /// \return + /// A shared pointer to the ValueObject described by var_expr. + lldb::ValueObjectSP DILGetValueForVariableExpressionPath( cmtice wrote: Done. https://github.com/llvm/llvm-project/pull/115666 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add framework for Data Inspection Language (DIL) work. (PR #115666)
@@ -508,6 +508,32 @@ StackFrame::GetInScopeVariableList(bool get_file_globals,
ValueObjectSP StackFrame::GetValueForVariableExpressionPath(
llvm::StringRef var_expr, DynamicValueType use_dynamic, uint32_t options,
VariableSP &var_sp, Status &error) {
+ // Check to see if we should use the DIL implementation.
+ lldb::TargetSP target_sp = CalculateTarget();
+ ExecutionContext exe_ctx;
+ CalculateExecutionContext(exe_ctx);
+ bool use_DIL = target_sp->GetUseDIL(&exe_ctx);
+ if (use_DIL)
+return DILGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
+var_sp, error);
+ else
cmtice wrote:
Done.
https://github.com/llvm/llvm-project/pull/115666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support overriding the disassembly CPU & features (PR #115382)
@@ -157,6 +157,12 @@ let Definition = "target" in {
DefaultEnumValue<"eX86DisFlavorDefault">,
EnumValues<"OptionEnumValues(g_x86_dis_flavor_value_types)">,
Desc<"The default disassembly flavor to use for x86 or x86-64 targets.">;
+ def DisassemblyCPU: Property<"disassembly-cpu", "String">,
+DefaultStringValue<"">,
+Desc<"Override the CPU for disassembling. Takes the same values as the
-mcpu compiler flag.">;
+ def DisassemblyFeatures: Property<"disassembly-features", "String">,
+DefaultStringValue<"">,
+Desc<"Specify additional CPU features for disassembling.">;
jasonmolenda wrote:
FWIW my thought was that most e.g. RISC-V users will be specifying a CPU (a
collection of ISA extensions), using and they already had to do that when they
compiled the program so they would know the name that clang recognizes. It
seemed less common that someone would want/need to specify a set of ISA
extensions manually for a target, but an important capability to have available.
https://github.com/llvm/llvm-project/pull/115382
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/slydiman closed https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Fix inline_sites_live.cpp Shell when run on Linux remotely from Windows (PR #115722)
labath wrote: > Considering that there's "REQUIRES: system-windows" on top of the test, maybe > I'll turn it off for target-linux at all? This problem is not really linux specific any os!=windows will have the same problem. I think `REQUIRES: target-windows` would be better. https://github.com/llvm/llvm-project/pull/115722 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/slydiman updated
https://github.com/llvm/llvm-project/pull/94165
>From f2064da30ae1d4dae4f04587e97ee0fdc82eb734 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Sun, 2 Jun 2024 21:38:12 +0400
Subject: [PATCH 1/2] [lldb] Disable find-module.test in case of a remote
target
The target arch is `i386-pc-windows` after loading the dump. It updates to
`i386-pc-windows-msvc` or `i386-pc-windows-gnu` in
lldb\source\Plugins\Process\minidump\ProcessMinidump.cpp, line 218
```
GetTarget().MergeArchitecture(module->GetArchitecture());
```
But in case of the remote target (`remote-linux`) and the `Windows host` lldb
executed the following commands at the beginning
```
platform select remote-linux
platform connect connect://:
```
and then the target arch is `i386-pc-windows-msvc` immediately after loading
the dump.
GetTarget().MergeArchitecture(module->GetArchitecture()) does not update it to
`i386-pc-windows-gnu` when the module arch is `i386-pc-windows-gnu`.
---
lldb/test/Shell/Minidump/Windows/find-module.test | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lldb/test/Shell/Minidump/Windows/find-module.test
b/lldb/test/Shell/Minidump/Windows/find-module.test
index 7ac2f74f8039b1..b3a7ec36520f04 100644
--- a/lldb/test/Shell/Minidump/Windows/find-module.test
+++ b/lldb/test/Shell/Minidump/Windows/find-module.test
@@ -1,6 +1,8 @@
Test that we correctly find a PE/COFF file in our executable search path, and
use it when opening minidumps.
+UNSUPPORTED: remote{{.*}}
+
RUN: yaml2obj %S/Inputs/find-module.exe.yaml -o %T/find-module.exe
RUN: yaml2obj %S/Inputs/find-module.dmp.yaml -o %T/find-module.dmp
RUN: %lldb -O "settings set target.exec-search-paths %T" \
>From 5fb07193c7e22665618537e2eacabedb27fe2f8f Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev
Date: Thu, 14 Nov 2024 11:25:09 +0400
Subject: [PATCH 2/2] Update lldb/test/Shell/Minidump/Windows/find-module.test
Co-authored-by: Pavel Labath
---
lldb/test/Shell/Minidump/Windows/find-module.test | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/test/Shell/Minidump/Windows/find-module.test
b/lldb/test/Shell/Minidump/Windows/find-module.test
index b3a7ec36520f04..fe457f4123522f 100644
--- a/lldb/test/Shell/Minidump/Windows/find-module.test
+++ b/lldb/test/Shell/Minidump/Windows/find-module.test
@@ -1,7 +1,7 @@
Test that we correctly find a PE/COFF file in our executable search path, and
use it when opening minidumps.
-UNSUPPORTED: remote{{.*}}
+XFAIL: remote{{.*}}
RUN: yaml2obj %S/Inputs/find-module.exe.yaml -o %T/find-module.exe
RUN: yaml2obj %S/Inputs/find-module.dmp.yaml -o %T/find-module.dmp
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 3d3b0bc - [lldb] Disable find-module.test in case of a remote target (#94165)
Author: Dmitry Vasilyev
Date: 2024-11-14T11:28:17+04:00
New Revision: 3d3b0bc239cd9c6e8c65ae26bdcf1534515c4beb
URL:
https://github.com/llvm/llvm-project/commit/3d3b0bc239cd9c6e8c65ae26bdcf1534515c4beb
DIFF:
https://github.com/llvm/llvm-project/commit/3d3b0bc239cd9c6e8c65ae26bdcf1534515c4beb.diff
LOG: [lldb] Disable find-module.test in case of a remote target (#94165)
The target arch is `i386-pc-windows` after loading the dump. It updates
to `i386-pc-windows-msvc` or `i386-pc-windows-gnu` in
lldb\source\Plugins\Process\minidump\ProcessMinidump.cpp, line 218
```
GetTarget().MergeArchitecture(module->GetArchitecture());
```
But in case of the remote target (`remote-linux`) and the `Windows host`
lldb executed the following commands at the beginning
```
platform select remote-linux
platform connect connect://:
```
and then the target arch is `i386-pc-windows-msvc` immediately after
loading the dump.
GetTarget().MergeArchitecture(module->GetArchitecture()) does not update
it to `i386-pc-windows-gnu` when the module arch is
`i386-pc-windows-gnu`.
-
Co-authored-by: Pavel Labath
Added:
Modified:
lldb/test/Shell/Minidump/Windows/find-module.test
Removed:
diff --git a/lldb/test/Shell/Minidump/Windows/find-module.test
b/lldb/test/Shell/Minidump/Windows/find-module.test
index 7ac2f74f8039b1..fe457f4123522f 100644
--- a/lldb/test/Shell/Minidump/Windows/find-module.test
+++ b/lldb/test/Shell/Minidump/Windows/find-module.test
@@ -1,6 +1,8 @@
Test that we correctly find a PE/COFF file in our executable search path, and
use it when opening minidumps.
+XFAIL: remote{{.*}}
+
RUN: yaml2obj %S/Inputs/find-module.exe.yaml -o %T/find-module.exe
RUN: yaml2obj %S/Inputs/find-module.dmp.yaml -o %T/find-module.dmp
RUN: %lldb -O "settings set target.exec-search-paths %T" \
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
@@ -1,6 +1,8 @@
Test that we correctly find a PE/COFF file in our executable search path, and
use it when opening minidumps.
+UNSUPPORTED: remote{{.*}}
labath wrote:
```suggestion
XFAIL: remote{{.*}}
```
https://github.com/llvm/llvm-project/pull/94165
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Disable find-module.test in case of a remote target (PR #94165)
https://github.com/labath approved this pull request. XFAIL would probably be better as this sounds like something that should work. https://github.com/llvm/llvm-project/pull/94165 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add Function::GetAddress and redirect some uses (PR #115836)
@@ -407,6 +406,15 @@ CompileUnit *Function::GetCompileUnit() { return
m_comp_unit; }
const CompileUnit *Function::GetCompileUnit() const { return m_comp_unit; }
+Address Function::GetAddress() const {
+ if (m_ranges.empty())
+return Address();
+ // We're using a (DWARF-like) convention where the base address of the first
+ // interval denotes the entry point of the function. If that turns out to be
+ // insufficient, we can introduce a separate "entry point address" field.
+ return m_ranges[0].GetBaseAddress();
labath wrote:
There's no guarantee that the function's entry point will be its lowest
numbered address. DWARF even allows you (via `DW_AT_entry_pc`) to have the
entry pc point to the middle of a range. I don't think any compiler emits that,
and lldb doesn't support that right now, but if we wanted to do it, then we'd
need to have a separate `m_address` field here independent of any range (that's
what I'm alluding to in that comment).
The "base address for relocation of blocks and variables" use case is totally
under our control, so we could choose that to be based on the lowest address of
the function, but that would mean we'd have to have two accessors (and then be
careful about which one is used where). I think it's better to use the same
address for both -- and accept the fact that some of the block/variable offsets
may be negative. (Having written that, I realize this also means that we'd need
to change the block/variable offsets to signed representations. Right now
they're unsigned, which I might sort of make this patch a regression for those
kinds of functions, but given that discontinuous functions are barely supported
anyway, I'd like to do that separately.) This also fits in nicely with DWARF
which says that "The base address of the scope for any of the debugging
information entries listed
above is given by either the DW_AT_low_pc attribute or the first address in the
first range entry in the list of ranges given by the DW_AT_ranges attribute."
-- it doesn't care whether the base address is numerically lowest.
Let me know what you think.
https://github.com/llvm/llvm-project/pull/115836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
