[Lldb-commits] [lldb] [lldb][riscv] Fix setting breakpoint for undecoded instruction (PR #90075)

2024-07-15 Thread Pavel Labath via lldb-commits

https://github.com/labath approved this pull request.

Thanks for pinging this. Sorry it dropped off my radar.

https://github.com/llvm/llvm-project/pull/90075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

2024-07-15 Thread Pavel Labath via lldb-commits

https://github.com/labath approved this pull request.


https://github.com/llvm/llvm-project/pull/98330
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

2024-07-15 Thread Pavel Labath via lldb-commits


@@ -10,9 +10,10 @@
 
 
 class TestDAP_stepInTargets(lldbdap_testcase.DAPTestCaseBase):
-@skipIf(
-archs=no_match(["x86_64"])
-)  # InstructionControlFlowKind for ARM is not supported yet.
+@skipIf
+# InstructionControlFlowKind for ARM is not supported yet.
+# On x86_64 lldb-dap seems to ignore targetId when stepping into functions.

labath wrote:

Judging by everything said on this thread, I believe this is only true on 
x86_64 *windows*, so we should limit the exclusion to windows. Then you may 
actually be able to keep the xfail decorator, since the test is really expected 
to fail in this configuration (until the issue is fixed). (i.e., I think this 
should use `@expectedFailureAll(oslist=["windows"])` instead of the `@skipIf`).

https://github.com/llvm/llvm-project/pull/96687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

2024-07-15 Thread Pavel Labath via lldb-commits


@@ -824,6 +824,36 @@ DWARFASTParserClang::GetDIEClassTemplateParams(const 
DWARFDIE &die) {
   return {};
 }
 
+void DWARFASTParserClang::MappingDeclDIEToDefDIE(
+const lldb_private::plugin::dwarf::DWARFDIE &decl_die,
+const lldb_private::plugin::dwarf::DWARFDIE &def_die) {
+  LinkDeclContextToDIE(GetCachedClangDeclContextForDIE(decl_die), def_die);
+  SymbolFileDWARF *dwarf = def_die.GetDWARF();
+  ParsedDWARFTypeAttributes decl_attrs(decl_die);
+  ParsedDWARFTypeAttributes def_attrs(def_die);
+  ConstString unique_typename(decl_attrs.name);
+  Declaration decl_declaration(decl_attrs.decl);
+  if (Language::LanguageIsCPlusPlus(
+  SymbolFileDWARF::GetLanguage(*decl_die.GetCU( {
+std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+if (!qualified_name.empty())
+  unique_typename = ConstString(qualified_name);
+decl_declaration.Clear();
+  }

labath wrote:

Sorry, I meant `ParseStructureLikeDIE` (which is called from 
ParseTypeFromDWARF), roughly lines 1664--1673

https://github.com/llvm/llvm-project/pull/98361
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

2024-07-15 Thread Pavel Labath via lldb-commits


@@ -405,8 +405,11 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"],
+triple=no_match("aarch64-.*-android"),

labath wrote:

I'm fairly certain you don't need this line. Android testing is always remote, 
so I expect  that this bit was used as a proxy for "remote=False" (probably 
unknowingly, because it wasn't known that the remoteness of the config is the 
important aspect).

https://github.com/llvm/llvm-project/pull/98690
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][riscv] Fix setting breakpoint for undecoded instruction (PR #90075)

2024-07-15 Thread via lldb-commits

ita-sc wrote:

Thanks. Could you please merge this? (I do not write access yet)

https://github.com/llvm/llvm-project/pull/90075
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] Remove restriction for remote working directory (PR #89768)

2024-07-15 Thread via lldb-commits

ita-sc wrote:

Gentle ping

https://github.com/llvm/llvm-project/pull/89768
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][AST] fix ast-print of extern with >=2 declarators, fixed, fixed (PR #98795)

2024-07-15 Thread Aaron Ballman via lldb-commits

AaronBallman wrote:

> @AaronBallman could you please review?
> 
> I've fixed at least the LLDB tests. There was an actual bug in function 
> parameters construction that was revealed by the invariant check.
> 
> However, I can't run the whole LLDB suite. Even among the reported failing 
> tests, some are «unsupported» on my machine. Even without my changes, a lot 
> of LLDB tests are unsupported or failing, I guess some were killed by 
> oom-killer. On the first attempt, @gulfemsavrun suggested to run the LLDB 
> test suite on this PR. I would be glad, if that offer is still on.

CC @JDevlieghere 
 
> Regarding the orc-rt test failures: I tried building one of the failing 
> objects and I can't reproduce the failure. Perhaps, because the tests are run 
> on Windows and I'm running on Linux? It would be very helpful if @Prabhuk 
> could run the failing command on a debug build.

CC @lhames 

https://github.com/llvm/llvm-project/pull/98795
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 82af559 - [API] add GetSyntheticValue (#95959)

2024-07-15 Thread via lldb-commits

Author: Vincent Belliard
Date: 2024-07-15T17:28:56+02:00
New Revision: 82af55983d75d4a821b76ee926b19725ec7fa889

URL: 
https://github.com/llvm/llvm-project/commit/82af55983d75d4a821b76ee926b19725ec7fa889
DIFF: 
https://github.com/llvm/llvm-project/commit/82af55983d75d4a821b76ee926b19725ec7fa889.diff

LOG: [API] add GetSyntheticValue (#95959)

Adds GetSyntheticValue to the API on top of GetNonSyntheticValue.

-

Co-authored-by: Vincent Belliard 

Added: 


Modified: 
lldb/include/lldb/API/SBValue.h
lldb/source/API/SBValue.cpp
lldb/test/API/python_api/formatters/TestFormattersSBAPI.py
lldb/test/API/python_api/formatters/main.cpp
lldb/test/API/python_api/formatters/synth.py

Removed: 




diff  --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index 65920c76df7a8..bec816fb45184 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -89,6 +89,8 @@ class LLDB_API SBValue {
 
   lldb::SBValue GetNonSyntheticValue();
 
+  lldb::SBValue GetSyntheticValue();
+
   lldb::DynamicValueType GetPreferDynamicValue();
 
   void SetPreferDynamicValue(lldb::DynamicValueType use_dynamic);

diff  --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index 10a691c403419..96670481eca3f 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -764,6 +764,21 @@ lldb::SBValue SBValue::GetNonSyntheticValue() {
   return value_sb;
 }
 
+lldb::SBValue SBValue::GetSyntheticValue() {
+  LLDB_INSTRUMENT_VA(this);
+
+  SBValue value_sb;
+  if (IsValid()) {
+ValueImplSP proxy_sp(new ValueImpl(m_opaque_sp->GetRootSP(),
+   m_opaque_sp->GetUseDynamic(), true));
+value_sb.SetSP(proxy_sp);
+if (!value_sb.IsSynthetic()) {
+  return {};
+}
+  }
+  return value_sb;
+}
+
 lldb::DynamicValueType SBValue::GetPreferDynamicValue() {
   LLDB_INSTRUMENT_VA(this);
 

diff  --git a/lldb/test/API/python_api/formatters/TestFormattersSBAPI.py 
b/lldb/test/API/python_api/formatters/TestFormattersSBAPI.py
index 7e802f92da352..c01c466b70c82 100644
--- a/lldb/test/API/python_api/formatters/TestFormattersSBAPI.py
+++ b/lldb/test/API/python_api/formatters/TestFormattersSBAPI.py
@@ -143,6 +143,19 @@ def cleanup():
 self.dbg.GetCategory("JASSynth").SetEnabled(True)
 self.expect("frame variable foo", matching=True, substrs=["X = 1"])
 
+self.dbg.GetCategory("CCCSynth2").SetEnabled(True)
+self.expect(
+"frame variable ccc",
+matching=True,
+substrs=[
+"CCC object with leading synthetic value (int) b = 222",
+"a = 111",
+"b = 222",
+"c = 333",
+],
+)
+self.dbg.GetCategory("CCCSynth2").SetEnabled(False)
+
 self.dbg.GetCategory("CCCSynth").SetEnabled(True)
 self.expect(
 "frame variable ccc",
@@ -155,6 +168,15 @@ def cleanup():
 ],
 )
 
+self.dbg.GetCategory("BarIntSynth").SetEnabled(True)
+self.expect(
+"frame variable bar_int",
+matching=True,
+substrs=[
+"(int) bar_int = 20 bar_int synthetic: No value",
+],
+)
+
 foo_var = (
 self.dbg.GetSelectedTarget()
 .GetProcess()

diff  --git a/lldb/test/API/python_api/formatters/main.cpp 
b/lldb/test/API/python_api/formatters/main.cpp
index f21c956144c29..50c29657a09a9 100644
--- a/lldb/test/API/python_api/formatters/main.cpp
+++ b/lldb/test/API/python_api/formatters/main.cpp
@@ -52,6 +52,8 @@ int main(int argc, char const *argv[]) {
 
CCC ccc = {111, 222, 333};
 
+int bar_int = 20;
+
 Empty1 e1;
 Empty2 e2;
 

diff  --git a/lldb/test/API/python_api/formatters/synth.py 
b/lldb/test/API/python_api/formatters/synth.py
index 474c18bc62ebd..91afb26af8436 100644
--- a/lldb/test/API/python_api/formatters/synth.py
+++ b/lldb/test/API/python_api/formatters/synth.py
@@ -29,11 +29,28 @@ def ccc_summary(sbvalue, internal_dict):
 # This tests that the SBValue.GetNonSyntheticValue() actually returns a
 # non-synthetic value. If it does not, then 
sbvalue.GetChildMemberWithName("a")
 # in the following statement will call the 'get_child_index' method of the
-# synthetic child provider CCCSynthProvider below (which raises an
-# exception).
+# synthetic child provider CCCSynthProvider below (which return the "b" 
field").
 return "CCC object with leading value " + 
str(sbvalue.GetChildMemberWithName("a"))
 
 
+def ccc_synthetic(sbvalue, internal_dict):
+sbvalue = sbvalue.GetSyntheticValue()
+# This tests that the SBValue.GetSyntheticValue() actually returns a
+# synthetic value. If it does, then sbvalue.GetChildMemberWithName("a")
+# in the following statement will call the 'get_child_index'

[Lldb-commits] [lldb] [API] add GetSyntheticValue (PR #95959)

2024-07-15 Thread Pavel Labath via lldb-commits

https://github.com/labath closed https://github.com/llvm/llvm-project/pull/95959
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Walter Erquinigo via lldb-commits


@@ -1710,6 +1710,8 @@ void request_initialize(const llvm::json::Object 
&request) {
   body.try_emplace("supportsLogPoints", true);
   // The debug adapter supports data watchpoints.
   body.try_emplace("supportsDataBreakpoints", true);
+  // Putting version string. Note: this is not part of DAP spec.
+  body.try_emplace("version", g_dap.debugger.GetVersionString());

walter-erquinigo wrote:

please call this `__lldb_version`. We tend to add the `__lldb` prefix to 
anything that is non-standard.

https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

2024-07-15 Thread Vladislav Dzhidzhoev via lldb-commits

https://github.com/dzhidzhoev updated 
https://github.com/llvm/llvm-project/pull/98690

>From 377f4ad5c61846adc7048f31d4b092c3e2a7d905 Mon Sep 17 00:00:00 2001
From: Vladislav Dzhidzhoev 
Date: Tue, 23 Apr 2024 05:44:49 +
Subject: [PATCH] [LLDB] Make 'process load' take remote os path delimiter into
 account

Currently, if we execute 'process load' with remote debugging,
it uses host's path delimiter to lookup files on target machine.
If we run remote debugging of Linux target on Windows and execute
'process load C:\foo\a.so', lldb-server tries to load \foo\a.so
instead of /foo/a.so.

It affects several API tests.

This commit fixes that error. Also, it contains minor fixes for
TestLoadUnload.py for testing on Windows host and Linux target.
---
 lldb/source/Commands/CommandObjectProcess.cpp | 4 +++-
 .../API/functionalities/load_unload/TestLoadUnload.py | 8 +---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectProcess.cpp 
b/lldb/source/Commands/CommandObjectProcess.cpp
index 3587a8f529e4a..8685d5761557b 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -950,11 +950,13 @@ class CommandObjectProcessLoad : public 
CommandObjectParsed {
   ExecutionContext *execution_context) override {
   Status error;
   const int short_option = m_getopt_table[option_idx].val;
+  ArchSpec arch =
+  execution_context->GetProcessPtr()->GetSystemArchitecture();
   switch (short_option) {
   case 'i':
 do_install = true;
 if (!option_arg.empty())
-  install_path.SetFile(option_arg, FileSpec::Style::native);
+  install_path.SetFile(option_arg, arch.GetTriple());
 break;
   default:
 llvm_unreachable("Unimplemented option");
diff --git a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py 
b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
index e52fb8c87377f..cfbfaff10de3c 100644
--- a/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
+++ b/lldb/test/API/functionalities/load_unload/TestLoadUnload.py
@@ -62,7 +62,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 for f in shlibs:
 err = lldb.remote_platform.Put(
 lldb.SBFileSpec(self.getBuildArtifact(f)),
-lldb.SBFileSpec(os.path.join(wd, f)),
+lldb.SBFileSpec(lldbutil.join_remote_paths(wd, f)),
 )
 if err.Fail():
 raise RuntimeError(
@@ -71,7 +71,7 @@ def copy_shlibs_to_remote(self, hidden_dir=False):
 if hidden_dir:
 shlib = "libloadunload_d." + ext
 hidden_dir = os.path.join(wd, "hidden")
-hidden_file = os.path.join(hidden_dir, shlib)
+hidden_file = lldbutil.join_remote_paths(hidden_dir, shlib)
 err = lldb.remote_platform.MakeDirectory(hidden_dir)
 if err.Fail():
 raise RuntimeError(
@@ -405,8 +405,10 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"],
+remote=False,
 )
 @expectedFailureAll(oslist=["windows"], archs=["aarch64"])
 def test_static_init_during_load(self):

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Make 'process load' take remote os path delimiter into account (PR #98690)

2024-07-15 Thread Vladislav Dzhidzhoev via lldb-commits


@@ -405,8 +405,11 @@ def run_step_over_load(self):
 
 # We can't find a breakpoint location for d_init before launching because
 # executable dependencies are resolved relative to the debuggers PWD. Bug?
+# The remote lldb server resolves the executable dependencies correctly.
 @expectedFailureAll(
-oslist=["freebsd", "linux", "netbsd"], 
triple=no_match("aarch64-.*-android")
+oslist=["freebsd", "linux", "netbsd"],
+triple=no_match("aarch64-.*-android"),

dzhidzhoev wrote:

Updated.

https://github.com/llvm/llvm-project/pull/98690
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

2024-07-15 Thread Kendal Harland via lldb-commits

https://github.com/kendalharland updated 
https://github.com/llvm/llvm-project/pull/96687

>From 02f06f90a40cc7ed18a9744918acf4daf6212486 Mon Sep 17 00:00:00 2001
From: kendal 
Date: Mon, 24 Jun 2024 14:01:31 -0700
Subject: [PATCH 1/2] Fix test assertions in TestDAP_stepInTargets.py

---
 .../stepInTargets/TestDAP_stepInTargets.py| 24 +--
 .../API/tools/lldb-dap/stepInTargets/main.cpp |  6 ++---
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py 
b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
index 6296f6554d07e..6670989a58fe8 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
@@ -55,14 +55,24 @@ def test_basic(self):
 self.assertEqual(len(step_in_targets), 3, "expect 3 step in targets")
 
 # Verify the target names are correct.
-self.assertEqual(step_in_targets[0]["label"], "bar()", "expect bar()")
-self.assertEqual(step_in_targets[1]["label"], "bar2()", "expect 
bar2()")
-self.assertEqual(
-step_in_targets[2]["label"], "foo(int, int)", "expect foo(int, 
int)"
-)
+# The order of funcA and funcB may change depending on the compiler 
ABI.
+funcA_target = None
+funcB_target = None
+for target in step_in_targets[0:2]:
+if "funcB" in target["label"]:
+funcB_target = target
+elif "funcA" in target["label"]:
+funcA_target = target
+else:
+self.fail(f"Unexpected step in target: {target}")
+
+self.assertIsNotNone(funcA_target, "expect funcA")
+self.assertIsNotNone(funcB_target, "expect funcB")
+self.assertIn("foo", step_in_targets[2]["label"], "expect foo")
 
-# Choose to step into second target and verify that we are in bar2()
+# Choose to step into second target and verify that we are in the 
second target,
+# be it funcA or funcB.
 self.stepIn(threadId=tid, targetId=step_in_targets[1]["id"], 
waitForStop=True)
 leaf_frame = self.dap_server.get_stackFrame()
 self.assertIsNotNone(leaf_frame, "expect a leaf frame")
-self.assertEqual(leaf_frame["name"], "bar2()")
+self.assertEqual(step_in_targets[1]["label"], leaf_frame["name"])
diff --git a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp 
b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
index d3c3dbcc139ef..a48b79af0c760 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
@@ -1,11 +1,11 @@
 
 int foo(int val, int extra) { return val + extra; }
 
-int bar() { return 22; }
+int funcA() { return 22; }
 
-int bar2() { return 54; }
+int funcB() { return 54; }
 
 int main(int argc, char const *argv[]) {
-  foo(bar(), bar2()); // set breakpoint here
+  foo(funcA(), funcB()); // set breakpoint here
   return 0;
 }

>From 8735430b3f99ba78791fca6c44891cb51cdb90f9 Mon Sep 17 00:00:00 2001
From: kendal 
Date: Thu, 11 Jul 2024 11:52:03 -0700
Subject: [PATCH 2/2] Disable this test on all platforms with issue ID

---
 .../tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py 
b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
index 6670989a58fe8..07acfe07c9ffc 100644
--- a/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
+++ b/lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
@@ -10,9 +10,11 @@
 
 
 class TestDAP_stepInTargets(lldbdap_testcase.DAPTestCaseBase):
-@skipIf(
-archs=no_match(["x86_64"])
-)  # InstructionControlFlowKind for ARM is not supported yet.
+@expectedFailureAll(oslist=["windows"])
+@skipIf(archs=no_match(["x86_64"]))
+# InstructionControlFlowKind for ARM is not supported yet.
+# On Windows, lldb-dap seems to ignore targetId when stepping into 
functions.
+# For more context, see https://github.com/llvm/llvm-project/issues/98509.
 def test_basic(self):
 """
 Tests the basic stepping in targets with directly calls.

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix test assertions in TestDAP_stepInTargets.py (PR #96687)

2024-07-15 Thread Kendal Harland via lldb-commits


@@ -10,9 +10,10 @@
 
 
 class TestDAP_stepInTargets(lldbdap_testcase.DAPTestCaseBase):
-@skipIf(
-archs=no_match(["x86_64"])
-)  # InstructionControlFlowKind for ARM is not supported yet.
+@skipIf
+# InstructionControlFlowKind for ARM is not supported yet.
+# On x86_64 lldb-dap seems to ignore targetId when stepping into functions.

kendalharland wrote:

Ah thanks for catching that. I added back the original `@skipIf` since the 
comment indicates that running the test on ARM is a waste, given that 
InstructionControlFlowKind is unsupported, and combined that with the 
`@expectedFailureAll` you gave above to expect failure on Windows 
configurations.

https://github.com/llvm/llvm-project/pull/96687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #98361)

2024-07-15 Thread Zequan Wu via lldb-commits

https://github.com/ZequanWu updated 
https://github.com/llvm/llvm-project/pull/98361

>From 37b6878b9125c314c75053f7d5b0ba520111e9a3 Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Tue, 9 Jul 2024 15:28:19 -0700
Subject: [PATCH 1/4] Reapply [lldb][DWARF] Delay struct/class/union definition
 DIE searching when parsing declaration DIEs.

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 279 --
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  67 +++--
 .../SymbolFile/DWARF/SymbolFileDWARF.h|  15 +-
 .../DWARF/SymbolFileDWARFDebugMap.h   |   9 +
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.cpp   |   2 +-
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.h |   3 +-
 .../SymbolFile/DWARF/UniqueDWARFASTType.cpp   | 117 
 .../SymbolFile/DWARF/UniqueDWARFASTType.h |  36 +--
 .../delayed-definition-die-searching.test |  36 +++
 .../x86/simple-template-names-context.cpp |   4 +-
 10 files changed, 301 insertions(+), 267 deletions(-)
 create mode 100644 
lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 8e297141f4e13..7b93f6941ddda 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1603,41 +1603,74 @@ DWARFASTParserClang::GetCPlusPlusQualifiedName(const 
DWARFDIE &die) {
 
 TypeSP
 DWARFASTParserClang::ParseStructureLikeDIE(const SymbolContext &sc,
-   const DWARFDIE &decl_die,
+   const DWARFDIE &die,
ParsedDWARFTypeAttributes &attrs) {
   CompilerType clang_type;
-  const dw_tag_t tag = decl_die.Tag();
-  SymbolFileDWARF *dwarf = decl_die.GetDWARF();
-  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*decl_die.GetCU());
+  const dw_tag_t tag = die.Tag();
+  SymbolFileDWARF *dwarf = die.GetDWARF();
+  LanguageType cu_language = SymbolFileDWARF::GetLanguage(*die.GetCU());
   Log *log = GetLog(DWARFLog::TypeCompletion | DWARFLog::Lookups);
 
-  // UniqueDWARFASTType is large, so don't create a local variables on the
-  // stack, put it on the heap. This function is often called recursively and
-  // clang isn't good at sharing the stack space for variables in different
-  // blocks.
-  auto unique_ast_entry_up = std::make_unique();
-
   ConstString unique_typename(attrs.name);
   Declaration unique_decl(attrs.decl);
+  uint64_t byte_size = attrs.byte_size.value_or(0);
+  if (attrs.byte_size && *attrs.byte_size == 0 && attrs.name &&
+  !die.HasChildren() && cu_language == eLanguageTypeObjC) {
+// Work around an issue with clang at the moment where forward
+// declarations for objective C classes are emitted as:
+//  DW_TAG_structure_type [2]
+//  DW_AT_name( "ForwardObjcClass" )
+//  DW_AT_byte_size( 0x00 )
+//  DW_AT_decl_file( "..." )
+//  DW_AT_decl_line( 1 )
+//
+// Note that there is no DW_AT_declaration and there are no children,
+// and the byte size is zero.
+attrs.is_forward_declaration = true;
+  }
 
   if (attrs.name) {
 if (Language::LanguageIsCPlusPlus(cu_language)) {
   // For C++, we rely solely upon the one definition rule that says
   // only one thing can exist at a given decl context. We ignore the
   // file and line that things are declared on.
-  std::string qualified_name = GetCPlusPlusQualifiedName(decl_die);
+  std::string qualified_name = GetCPlusPlusQualifiedName(die);
   if (!qualified_name.empty())
 unique_typename = ConstString(qualified_name);
   unique_decl.Clear();
 }
 
-if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, decl_die, unique_decl,
-attrs.byte_size.value_or(-1), *unique_ast_entry_up)) {
-  if (TypeSP type_sp = unique_ast_entry_up->m_type_sp) {
+if (UniqueDWARFASTType *unique_ast_entry_type =
+dwarf->GetUniqueDWARFASTTypeMap().Find(
+unique_typename, die, unique_decl, byte_size,
+attrs.is_forward_declaration)) {
+  if (TypeSP type_sp = unique_ast_entry_type->m_type_sp) {
+dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
 LinkDeclContextToDIE(
-GetCachedClangDeclContextForDIE(unique_ast_entry_up->m_die),
-decl_die);
+GetCachedClangDeclContextForDIE(unique_ast_entry_type->m_die), 
die);
+// If the DIE being parsed in this function is a definition and the
+// entry in the map is a declaration, then we need to update the entry
+// to point to the definition DIE.
+if (!attrs.is_forward_declaration &&
+unique_ast_entry_type->m_is_forward_declaration) {
+  unique_ast_entry_type->m_die = die;
+  unique_ast_entry_type->m_byte_size = byte_size;
+  un

[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

Ah no, I misunderstood.  The Increment method of Progress is intended for use 
where you have one progress status display that takes multiple steps to 
complete.  It's a separate mechanism from "finding dSYM for file x" etc.  I 
can't use an Increment style progress reporting in this PR.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Greg Clayton via lldb-commits

https://github.com/clayborg requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Greg Clayton via lldb-commits

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -1710,6 +1710,8 @@ void request_initialize(const llvm::json::Object 
&request) {
   body.try_emplace("supportsLogPoints", true);
   // The debug adapter supports data watchpoints.
   body.try_emplace("supportsDataBreakpoints", true);
+  // Putting version string. Note: this is not part of DAP spec.
+  body.try_emplace("version", g_dap.debugger.GetVersionString());

clayborg wrote:

I would add a dictionary named "__lldb" and the contents will be the "version": 
 like:
```
"__lldb": {
  "version": ""
}
```
Then we can add more stuff in here in the future if we need to  know things. 
The Python version would be interesting as well possibly in the future.

https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

2024-07-15 Thread Greg Clayton via lldb-commits

clayborg wrote:

This feature hides what other threads are doing when you stop and any other 
threads that stop for a reason can be hidden from the user. For example if we 
have 5 threads stop at a breakpoint, but we only report 1 for thread 1, do we 
see the right stop reason for the threads 2-5 in the UI? Can we tell they 
stopped at a breakpoint? Or we are pretending that they just stopped for no 
reason as far as the IDE is concerned? Do we need to type "thread list" in the 
debug console to see the real stop reasons?

My main issue with this is lets say you set a breakpoint somewhere and this 
breakpoint is important and if you hit this breakpoint then you have found your 
bug. But you are stepping in another thread with this feature enabled. You will 
never know that this breakpoint was hit unless it eventually causes a fatal 
error. So it is easy to miss important breakpoints.

That being said, Jeffrey's reason for this patch is the VS Code IDE doesn't do 
a great job at showing the current thread when you might be debugging some code 
that multiple threads are executing at the same time. You see a mess of thread 
PC indicators and the colors don't clearly tell you which one is your current 
thread and it becomes confusing for users. So I am not opposed to this feature 
as long as the description for the launch config option has a big warning in 
the description.

https://github.com/llvm/llvm-project/pull/98568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -255,45 +253,75 @@ void SendThreadStoppedEvent() {
   lldb::tid_t first_tid_with_reason = LLDB_INVALID_THREAD_ID;
   uint32_t num_threads_with_reason = 0;
   bool focus_thread_exists = false;
+  lldb::SBThread focus_thread, first_thread_with_reason;
   for (uint32_t thread_idx = 0; thread_idx < num_threads; ++thread_idx) {
 lldb::SBThread thread = process.GetThreadAtIndex(thread_idx);
 const lldb::tid_t tid = thread.GetThreadID();
 const bool has_reason = ThreadHasStopReason(thread);
 // If the focus thread doesn't have a stop reason, clear the thread ID
 if (tid == g_dap.focus_tid) {
+  focus_thread = thread;
   focus_thread_exists = true;
   if (!has_reason)
 g_dap.focus_tid = LLDB_INVALID_THREAD_ID;
 }
 if (has_reason) {
   ++num_threads_with_reason;
-  if (first_tid_with_reason == LLDB_INVALID_THREAD_ID)
+  if (first_tid_with_reason == LLDB_INVALID_THREAD_ID) {
 first_tid_with_reason = tid;
+first_thread_with_reason = thread;
+  }
 }
   }
 
   // We will have cleared g_dap.focus_tid if the focus thread doesn't have
   // a stop reason, so if it was cleared, or wasn't set, or doesn't exist,
   // then set the focus thread to the first thread with a stop reason.
-  if (!focus_thread_exists || g_dap.focus_tid == LLDB_INVALID_THREAD_ID)
+  if (!focus_thread_exists || g_dap.focus_tid == LLDB_INVALID_THREAD_ID) {
 g_dap.focus_tid = first_tid_with_reason;
+focus_thread = first_thread_with_reason;
+  }
 
   // If no threads stopped with a reason, then report the first one so
   // we at least let the UI know we stopped.
   if (num_threads_with_reason == 0) {
 lldb::SBThread thread = process.GetThreadAtIndex(0);
 g_dap.focus_tid = thread.GetThreadID();
 g_dap.SendJSON(CreateThreadStopped(thread, stop_id));
+  } else if (g_dap.single_stopped_event) {
+// If single_stopped_event option is true only one stopped event will
+// be sent during debugger stop. The focused thread's stopped event is
+// preferred if it is stopped with a reason; otherwise, we simply use
+// the first stopped thread.
+//
+// This option would be preferred for VSCode IDE because multiple
+// stopped events would cause confusing UX.
+//
+// TODO: do we need to give priority to exception/signal stopped event
+// over normal stepping complete/breakpoint?

clayborg wrote:

This would be important

https://github.com/llvm/llvm-project/pull/98568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Support single stopped event in lldb-dap (PR #98568)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -1625,6 +1657,11 @@ void request_initialize(const llvm::json::Object 
&request) {
   "Get or set the repl behavior of lldb-dap evaluation requests.");
 
   g_dap.progress_event_thread = std::thread(ProgressEventThreadFunction);
+  // singleStoppedEvent option is not from formal DAP specification. It is an
+  // lldb specific option to experiment stopped events behaivor against
+  // application with multiple threads.
+  g_dap.single_stopped_event =
+  GetBoolean(arguments, "singleStoppedEvent", false);

clayborg wrote:

Can we add this key/value pair as a launch configuration instead of adding it 
from the IDE? Then we can document the feature in the package.json with lots of 
warning text. Also the name should be lldb specific to ensure we don't conflict 
with future VS code key/value pairs. Maybe add a "__lldbSingleStopEvent"? 

There is also a type script plug-in in the upstream LLDB where you can add the 
necessary setting to so if we leave this in the initialize packet, it can get 
sent down here

https://github.com/llvm/llvm-project/pull/98568
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Fix remote executables load and caching (PR #98623)

2024-07-15 Thread Greg Clayton via lldb-commits

clayborg wrote:

Very nice. We really need to get an android test in for this, or at least a 
test that simulates what android does in some way to verify we don't regress 
this in the future.

https://github.com/llvm/llvm-project/pull/98623
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Fix Android debugging (PR #98581)

2024-07-15 Thread Greg Clayton via lldb-commits

clayborg wrote:

We really need there to be some tests somehow or somewhere for this. Without 
tests we can't verify this doesn't get broken in the future. If we can't test 
with true android we could create a test platform layer that is only available 
in debug builds that could allow us to simulate things.

https://github.com/llvm/llvm-project/pull/98581
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] Add a layout simulator test for std::unique_ptr (PR #98330)

2024-07-15 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/98330

>From a25b3c8a6a36326730d00d1060ff84181bece26e Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/6] [WIP][lldb][test] Add a layout simulator test for
 std::unique_ptr

---
 .../libcxx-simulators/compressed_pair.h   | 89 +++
 .../libcxx-simulators/unique_ptr/Makefile |  3 +
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 32 +++
 .../libcxx-simulators/unique_ptr/main.cpp | 43 +
 4 files changed, 167 insertions(+)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/main.cpp

diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
new file mode 100644
index 0..ec978b8053646
--- /dev/null
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/compressed_pair.h
@@ -0,0 +1,89 @@
+#ifndef STD_LLDB_COMPRESSED_PAIR_H
+#define STD_LLDB_COMPRESSED_PAIR_H
+
+#include <__memory/compressed_pair.h>
+#include 
+
+namespace std {
+namespace __lldb {
+
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
+struct __value_init_tag {};
+struct __default_init_tag {};
+
+template ::value && !std::is_final<_Tp>::value>
+struct __compressed_pair_elem {
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : __value_() {}
+
+  explicit __compressed_pair_elem(_Tp __t) : __value_(__t) {}
+
+  _Tp &__get() { return __value_; }
+
+private:
+  _Tp __value_;
+};
+
+template 
+struct __compressed_pair_elem<_Tp, _Idx, true> : private _Tp {
+  explicit __compressed_pair_elem(_Tp __t) : _Tp(__t) {}
+  explicit __compressed_pair_elem(__default_init_tag) {}
+  explicit __compressed_pair_elem(__value_init_tag) : _Tp() {}
+
+  _Tp &__get() { return *this; }
+};
+
+template 
+class __compressed_pair : private __compressed_pair_elem<_T1, 0>,
+  private __compressed_pair_elem<_T2, 1> {
+public:
+  using _Base1 = __compressed_pair_elem<_T1, 0>;
+  using _Base2 = __compressed_pair_elem<_T2, 1>;
+
+  explicit __compressed_pair(_T1 __t1, _T2 __t2) : _Base1(__t1), _Base2(__t2) 
{}
+  explicit __compressed_pair()
+  : _Base1(__value_init_tag()), _Base2(__value_init_tag()) {}
+
+  template 
+  explicit __compressed_pair(_U1 &&__t1, _U2 &&__t2)
+  : _Base1(std::forward<_U1>(__t1)), _Base2(std::forward<_U2>(__t2)) {}
+
+  _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
+};
+#elif COMPRESSED_PAIR_REV == 1
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _)
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding1_, __LINE__, _);   
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding2_, __LINE__, _);   
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding _LIBCPP_CONCAT3( 
\
+  __padding3_, __LINE__, _)
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1; 

[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread via lldb-commits

https://github.com/jeffreytan81 updated 
https://github.com/llvm/llvm-project/pull/98703

>From 4c8619989ffd647fbbabeb124ef101bb9ec495be Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Fri, 12 Jul 2024 17:34:31 -0700
Subject: [PATCH 1/2] Add lldb version into initialize response

---
 .../tools/lldb-dap/launch/TestDAP_launch.py   | 30 +++
 lldb/tools/lldb-dap/lldb-dap.cpp  |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py 
b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
index b1b3d05ed4548..66d6d04cde882 100644
--- a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
+++ b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
@@ -475,3 +475,33 @@ def test_terminate_commands(self):
 pattern=terminateCommands[0],
 )
 self.verify_commands("terminateCommands", output, terminateCommands)
+
+@skipIfWindows
+def test_version(self):
+"""
+Tests that "initialize" response contains the "version" string the same
+as the one returned by "version" command.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+source = "main.c"
+breakpoint_line = line_number(source, "// breakpoint 1")
+lines = [breakpoint_line]
+# Set breakpoint in the thread function so we can step the threads
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+version_eval_response = self.dap_server.request_evaluate(
+"`version", context="repl"
+)
+version_eval_output = version_eval_response["body"]["result"]
+
+# The first line is the prompt line like "(lldb) version", so we skip 
it.
+version_eval_output_without_prompt_line = 
version_eval_output.splitlines()[1:]
+version_string = self.dap_server.get_initialize_value("version")
+self.assertEqual(
+version_eval_output_without_prompt_line,
+version_string.splitlines(),
+"version string does not match",
+)
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index b74474b9d383c..020e08bfb75d0 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1710,6 +1710,8 @@ void request_initialize(const llvm::json::Object 
&request) {
   body.try_emplace("supportsLogPoints", true);
   // The debug adapter supports data watchpoints.
   body.try_emplace("supportsDataBreakpoints", true);
+  // Putting version string. Note: this is not part of DAP spec.
+  body.try_emplace("version", g_dap.debugger.GetVersionString());
 
   response.try_emplace("body", std::move(body));
   g_dap.SendJSON(llvm::json::Value(std::move(response)));

>From 1ded00112144aaddd8f8de7d69f979e6771a7190 Mon Sep 17 00:00:00 2001
From: jeffreytan81 
Date: Mon, 15 Jul 2024 16:50:51 -0400
Subject: [PATCH 2/2] Address review feedback

---
 lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py | 3 ++-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 7 +--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py 
b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
index 66d6d04cde882..dd47a2db8709b 100644
--- a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
+++ b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
@@ -499,7 +499,8 @@ def test_version(self):
 
 # The first line is the prompt line like "(lldb) version", so we skip 
it.
 version_eval_output_without_prompt_line = 
version_eval_output.splitlines()[1:]
-version_string = self.dap_server.get_initialize_value("version")
+lldb_json = self.dap_server.get_initialize_value("__lldb")
+version_string = lldb_json["version"]
 self.assertEqual(
 version_eval_output_without_prompt_line,
 version_string.splitlines(),
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 020e08bfb75d0..9559248a0548c 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1710,8 +1710,11 @@ void request_initialize(const llvm::json::Object 
&request) {
   body.try_emplace("supportsLogPoints", true);
   // The debug adapter supports data watchpoints.
   body.try_emplace("supportsDataBreakpoints", true);
-  // Putting version string. Note: this is not part of DAP spec.
-  body.try_emplace("version", g_dap.debugger.GetVersionString());
+
+  // Put in non-DAP specification lldb specific information.
+  llvm::json::Object lldb_json;
+  lldb_json.try_emplace("version", g_dap.debugger.GetVersionString());
+  body.try_emplace("__lldb", std::move(lldb_json));
 
   response.try_emplace("body", std::move(body));
   g_dap.SendJSON(llvm::json::Value(std::move(response)));

___
lldb-commi

[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread Greg Clayton via lldb-commits

https://github.com/clayborg approved this pull request.


https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Greg Clayton via lldb-commits

https://github.com/clayborg requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Greg Clayton via lldb-commits

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -195,20 +196,40 @@ ModuleSP DynamicLoader::LoadBinaryWithUUIDAndAddress(
   Target &target = process->GetTarget();
   Status error;
 
+  StreamString prog_str;
+  if (!name.empty()) {
+prog_str << name.str() << " ";
+  }
+  if (uuid.IsValid())
+prog_str << uuid.GetAsString();
+  if (value_is_offset == 0 && value != LLDB_INVALID_ADDRESS) {
+prog_str << "at 0x";
+prog_str.PutHex64(value);
+  }
+
   if (!uuid.IsValid() && !value_is_offset) {
+Progress progress_memread("Reading load commands from memory",

clayborg wrote:

I would change this string to "Reading object file from memory" instead of 
"Reading load commands from memory". This function is currently only used by 
Mach-O core files and the GDB remote stub, but this could be used for loading 
ELF files from memory as well. 

Maybe this Progress dialog should go into `ReadUnnamedMemoryModule` so anyone 
that calls this function gets progress events when loading an object file from 
memory?

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -195,20 +196,40 @@ ModuleSP DynamicLoader::LoadBinaryWithUUIDAndAddress(
   Target &target = process->GetTarget();
   Status error;
 
+  StreamString prog_str;
+  if (!name.empty()) {
+prog_str << name.str() << " ";
+  }
+  if (uuid.IsValid())
+prog_str << uuid.GetAsString();
+  if (value_is_offset == 0 && value != LLDB_INVALID_ADDRESS) {
+prog_str << "at 0x";
+prog_str.PutHex64(value);
+  }
+
   if (!uuid.IsValid() && !value_is_offset) {
+Progress progress_memread("Reading load commands from memory",
+  prog_str.GetString().str());
 memory_module_sp = ReadUnnamedMemoryModule(process, value, name);
 
-if (memory_module_sp)
+if (memory_module_sp) {
   uuid = memory_module_sp->GetUUID();
+  if (uuid.IsValid()) {
+prog_str << " ";
+prog_str << uuid.GetAsString();
+  }
+}
   }
   ModuleSpec module_spec;
   module_spec.GetUUID() = uuid;
   FileSpec name_filespec(name);
-  if (FileSystem::Instance().Exists(name_filespec))
-module_spec.GetFileSpec() = name_filespec;
 
   if (uuid.IsValid()) {
+Progress progress("Locating external symbol file",
+  prog_str.GetString().str());
+
 // Has lldb already seen a module with this UUID?
+// Or have external lookup enabled in DebugSymbols on macOS.

clayborg wrote:

Should this go into `ModuleList::GetSharedModule()` or at some function that is 
called by `ModuleList::GetSharedModule()`? If the 
`ModuleList::GetSharedModule()` function is really quick, I hate to add really 
spammy progress notifications that aren't useful. If there is code down in 
`ModuleList::GetSharedModule()` that locates an external symbol file, then the 
progress should go in that function that is known to take some amount of time, 
but not here in a general area IMHO

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Greg Clayton via lldb-commits


@@ -757,11 +758,32 @@ bool 
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule(
 const ModuleList &target_images = target.GetImages();
 m_module_sp = target_images.FindModule(m_uuid);
 
+StreamString prog_str;
+// 'mach_kernel' is a fake name we make up to find kernels
+// that were located by the local filesystem scan.
+if (GetName() != "mach_kernel")
+  prog_str << GetName() << " ";
+if (GetUUID().IsValid())
+  prog_str << GetUUID().GetAsString() << " ";
+if (GetLoadAddress() != LLDB_INVALID_ADDRESS) {
+  prog_str << "at 0x";
+  prog_str.PutHex64(GetLoadAddress());
+}
+std::unique_ptr progress_wp;
+if (IsKernel())
+  progress_wp = std::make_unique("Loading kernel",
+   prog_str.GetString().str());
+else
+  progress_wp = std::make_unique("Loading kext",
+   prog_str.GetString().str());
+
 // Search for the kext on the local filesystem via the UUID
 if (!m_module_sp && m_uuid.IsValid()) {
   ModuleSpec module_spec;
   module_spec.GetUUID() = m_uuid;
-  module_spec.GetArchitecture() = target.GetArchitecture();
+  if (!m_uuid.IsValid())
+module_spec.GetArchitecture() = target.GetArchitecture();

clayborg wrote:

Did you mean to check if the UUID is valid in the if statement and then set the 
architecture?

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits


@@ -757,11 +758,32 @@ bool 
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule(
 const ModuleList &target_images = target.GetImages();
 m_module_sp = target_images.FindModule(m_uuid);
 
+StreamString prog_str;
+// 'mach_kernel' is a fake name we make up to find kernels
+// that were located by the local filesystem scan.
+if (GetName() != "mach_kernel")
+  prog_str << GetName() << " ";
+if (GetUUID().IsValid())
+  prog_str << GetUUID().GetAsString() << " ";
+if (GetLoadAddress() != LLDB_INVALID_ADDRESS) {
+  prog_str << "at 0x";
+  prog_str.PutHex64(GetLoadAddress());
+}
+std::unique_ptr progress_wp;
+if (IsKernel())
+  progress_wp = std::make_unique("Loading kernel",
+   prog_str.GetString().str());
+else
+  progress_wp = std::make_unique("Loading kext",
+   prog_str.GetString().str());
+
 // Search for the kext on the local filesystem via the UUID
 if (!m_module_sp && m_uuid.IsValid()) {
   ModuleSpec module_spec;
   module_spec.GetUUID() = m_uuid;
-  module_spec.GetArchitecture() = target.GetArchitecture();
+  if (!m_uuid.IsValid())
+module_spec.GetArchitecture() = target.GetArchitecture();

jasonmolenda wrote:

If I have a UUID, it's authoritative, whereas the ArchSpec might be 
heuristically determined.  I don't like setting both in a ModuleSpec if the 
UUID is valid, it it noramlly fine but it's a little footgun waiting for some 
unusual combination where the heuristically determined ArchSpec is not quite 
the same ("compatible") with the arch of the UUID specified.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits


@@ -757,11 +758,32 @@ bool 
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule(
 const ModuleList &target_images = target.GetImages();
 m_module_sp = target_images.FindModule(m_uuid);
 
+StreamString prog_str;
+// 'mach_kernel' is a fake name we make up to find kernels
+// that were located by the local filesystem scan.
+if (GetName() != "mach_kernel")
+  prog_str << GetName() << " ";
+if (GetUUID().IsValid())
+  prog_str << GetUUID().GetAsString() << " ";
+if (GetLoadAddress() != LLDB_INVALID_ADDRESS) {
+  prog_str << "at 0x";
+  prog_str.PutHex64(GetLoadAddress());
+}
+std::unique_ptr progress_wp;
+if (IsKernel())
+  progress_wp = std::make_unique("Loading kernel",
+   prog_str.GetString().str());
+else
+  progress_wp = std::make_unique("Loading kext",
+   prog_str.GetString().str());
+
 // Search for the kext on the local filesystem via the UUID
 if (!m_module_sp && m_uuid.IsValid()) {
   ModuleSpec module_spec;
   module_spec.GetUUID() = m_uuid;
-  module_spec.GetArchitecture() = target.GetArchitecture();
+  if (!m_uuid.IsValid())
+module_spec.GetArchitecture() = target.GetArchitecture();

jasonmolenda wrote:

I know I shouldn't be making changes like this at the same time as adding 
progress status logging, but it irked me when I saw it.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fixed the error `unable to launch a GDB server` in API tests (PR #98833)

2024-07-15 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman edited 
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Add frame recognizer for __builtin_verbose_trap (PR #80368)

2024-07-15 Thread Greg Clayton via lldb-commits

clayborg wrote:

I am fine with landing as is. Maybe we should add some `TODO:` comments in the 
3 frame recognizers with comments saying what we really should do to put these 
kinds of frame plug-ins in the right places.

https://github.com/llvm/llvm-project/pull/80368
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 44d9692 - Private process events were being delivered to the secondary listener (#98571)

2024-07-15 Thread via lldb-commits

Author: jimingham
Date: 2024-07-15T15:07:01-07:00
New Revision: 44d9692e6a657ec46e98e4912ac56417da67cfee

URL: 
https://github.com/llvm/llvm-project/commit/44d9692e6a657ec46e98e4912ac56417da67cfee
DIFF: 
https://github.com/llvm/llvm-project/commit/44d9692e6a657ec46e98e4912ac56417da67cfee.diff

LOG: Private process events were being delivered to the secondary listener 
(#98571)

This fixes a bug where Process events were being delivered to secondary
listeners when the Private state thread listener was processing the
event. That meant the secondary listener could get an event before the
Primary listener did. That in turn meant the state when the secondary
listener got the event wasn't right yet. Plus it meant that the
secondary listener saw more events than the primary (not all events get
forwarded from the private to the public Process listener.)

This bug became much more evident when we had a stop hook that did some
work, since that delays the Primary listener event delivery. So I also
added a stop-hook to the test, and put a little delay in as well.

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Utility/Event.h
lldb/source/Target/Process.cpp
lldb/source/Utility/Event.cpp
lldb/test/API/python_api/event/TestEvents.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index ceaf547ebddaf..c8475db8ae160 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -465,6 +465,8 @@ class Process : public 
std::enable_shared_from_this,
 static bool SetUpdateStateOnRemoval(Event *event_ptr);
 
   private:
+bool ForwardEventToPendingListeners(Event *event_ptr) override;
+
 void SetUpdateStateOnRemoval() { m_update_state++; }
 
 void SetRestarted(bool new_value) { m_restarted = new_value; }

diff  --git a/lldb/include/lldb/Utility/Event.h 
b/lldb/include/lldb/Utility/Event.h
index 461d711b8c3f2..4f58f257d4a26 100644
--- a/lldb/include/lldb/Utility/Event.h
+++ b/lldb/include/lldb/Utility/Event.h
@@ -48,6 +48,17 @@ class EventData {
   virtual void Dump(Stream *s) const;
 
 private:
+  /// This will be queried for a Broadcaster with a primary and some secondary
+  /// listeners after the primary listener pulled the event from the event 
queue
+  /// and ran its DoOnRemoval, right before the event is delivered.
+  /// If it returns true, the event will also be forwarded to the secondary
+  /// listeners, and if false, event propagation stops at the primary listener.
+  /// Some broadcasters (particularly the Process broadcaster) fetch events on
+  /// a private Listener, and then forward the event to the Public Listeners
+  /// after some processing.  The Process broadcaster does not want to forward
+  /// to the secondary listeners at the private processing stage.
+  virtual bool ForwardEventToPendingListeners(Event *event_ptr) { return true; 
}
+
   virtual void DoOnRemoval(Event *event_ptr) {}
 
   EventData(const EventData &) = delete;

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b91446e1c0e49..7abe5dcb88845 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -4236,7 +4236,22 @@ bool Process::ProcessEventData::ShouldStop(Event 
*event_ptr,
   return still_should_stop;
 }
 
+bool Process::ProcessEventData::ForwardEventToPendingListeners(
+Event *event_ptr) {
+  // STDIO and the other async event notifications should always be forwarded.
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return true;
+
+  // For state changed events, if the update state is zero, we are handling
+  // this on the private state thread.  We should wait for the public event.
+  return m_update_state == 1;
+}
+
 void Process::ProcessEventData::DoOnRemoval(Event *event_ptr) {
+  // We only have work to do for state changed events:
+  if (event_ptr->GetType() != Process::eBroadcastBitStateChanged)
+return;
+
   ProcessSP process_sp(m_process_wp.lock());
 
   if (!process_sp)

diff  --git a/lldb/source/Utility/Event.cpp b/lldb/source/Utility/Event.cpp
index 863167e56bce6..5f431c0a6dd89 100644
--- a/lldb/source/Utility/Event.cpp
+++ b/lldb/source/Utility/Event.cpp
@@ -83,14 +83,20 @@ void Event::Dump(Stream *s) const {
 void Event::DoOnRemoval() {
   std::lock_guard guard(m_listeners_mutex);
 
-  if (m_data_sp)
-m_data_sp->DoOnRemoval(this);
+  if (!m_data_sp)
+return;
+
+  m_data_sp->DoOnRemoval(this);
+
   // Now that the event has been handled by the primary event Listener, forward
   // it to the other Listeners.
+
   EventSP me_sp = shared_from_this();
-  for (auto listener_sp : m_pending_listeners)
-listener_sp->AddEvent(me_sp);
-  m_pending_listeners.clear();
+  if (m_data_sp->ForwardEventToPendingListeners(this)) {
+for (auto listener_sp : m_pending_listeners)
+  listener_sp->AddEven

[Lldb-commits] [lldb] Private process events were being delivered to the secondary listener (PR #98571)

2024-07-15 Thread via lldb-commits

https://github.com/jimingham closed 
https://github.com/llvm/llvm-project/pull/98571
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits


@@ -757,11 +758,32 @@ bool 
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule(
 const ModuleList &target_images = target.GetImages();
 m_module_sp = target_images.FindModule(m_uuid);
 
+StreamString prog_str;
+// 'mach_kernel' is a fake name we make up to find kernels
+// that were located by the local filesystem scan.
+if (GetName() != "mach_kernel")
+  prog_str << GetName() << " ";
+if (GetUUID().IsValid())
+  prog_str << GetUUID().GetAsString() << " ";
+if (GetLoadAddress() != LLDB_INVALID_ADDRESS) {
+  prog_str << "at 0x";
+  prog_str.PutHex64(GetLoadAddress());
+}
+std::unique_ptr progress_wp;
+if (IsKernel())
+  progress_wp = std::make_unique("Loading kernel",
+   prog_str.GetString().str());
+else
+  progress_wp = std::make_unique("Loading kext",
+   prog_str.GetString().str());
+
 // Search for the kext on the local filesystem via the UUID
 if (!m_module_sp && m_uuid.IsValid()) {
   ModuleSpec module_spec;
   module_spec.GetUUID() = m_uuid;
-  module_spec.GetArchitecture() = target.GetArchitecture();
+  if (!m_uuid.IsValid())
+module_spec.GetArchitecture() = target.GetArchitecture();

jasonmolenda wrote:

just to be clear, it's almost always the "environment" or "os" part of the 
triple, which is nearly an entire fiction with firmware style debugging, that 
is the problem.  One binary will say "hey I'm iOS" and another binary that 
needs to be loaded also is like "I'm something else" and lldb will reject the 
module load even though the UUIDs match.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Add frame recognizer for __builtin_verbose_trap (PR #80368)

2024-07-15 Thread via lldb-commits

jimingham wrote:

Sure.

Jim


> On Jul 13, 2024, at 2:20 AM, Michael Buch ***@***.***> wrote:
> 
> 
> @jimingham  @JDevlieghere 
>  @clayborg  
> just to confirm, are you still ok with me landing this and address the 
> question of a common CLanguageRuntime plugin as a follow-up?
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



https://github.com/llvm/llvm-project/pull/80368
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fixed the error `unable to launch a GDB server` in API tests (PR #98833)

2024-07-15 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman edited 
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (PR #98975)

2024-07-15 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/98975

This patch hoists the `SymbolLocation` struct from the `AssertFrameRecognizer` 
source file, since it's pretty generic and could be reused for other purposes.

>From d22b491ab6557e4d53ed722a46de58ff126af4a6 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 15 Jul 2024 16:00:07 -0700
Subject: [PATCH] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer
 to reuse it

This patch hoists the `SymbolLocation` struct from the
`AssertFrameRecognizer` source file, since it's pretty generic and could
be reused for other purposes.

Signed-off-by: Med Ismail Bennani 
---
 lldb/include/lldb/Symbol/SymbolLocation.h| 32 
 lldb/source/Target/AssertFrameRecognizer.cpp | 13 +---
 2 files changed, 33 insertions(+), 12 deletions(-)
 create mode 100644 lldb/include/lldb/Symbol/SymbolLocation.h

diff --git a/lldb/include/lldb/Symbol/SymbolLocation.h 
b/lldb/include/lldb/Symbol/SymbolLocation.h
new file mode 100644
index 0..be590c403b6e2
--- /dev/null
+++ b/lldb/include/lldb/Symbol/SymbolLocation.h
@@ -0,0 +1,32 @@
+//===-- SymbolLocation.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SYMBOL_SYMBOLLOCATION_H
+#define LLDB_SYMBOL_SYMBOLLOCATION_H
+
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/lldb-private.h"
+
+#include 
+
+namespace lldb_private {
+
+/// Stores a function module spec, symbol name and possibly an alternate symbol
+/// name.
+struct SymbolLocation {
+  FileSpec module_spec;
+  std::vector symbols;
+
+  // The symbols are regular expressions. In such case all symbols are matched
+  // with their trailing @VER symbol version stripped.
+  bool symbols_are_regex = false;
+};
+
+} // namespace lldb_private
+#endif // LLDB_SYMBOL_SYMBOLLOCATION_H
diff --git a/lldb/source/Target/AssertFrameRecognizer.cpp 
b/lldb/source/Target/AssertFrameRecognizer.cpp
index 5f4682bd5c11a..da7c102645c01 100644
--- a/lldb/source/Target/AssertFrameRecognizer.cpp
+++ b/lldb/source/Target/AssertFrameRecognizer.cpp
@@ -2,6 +2,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/SymbolLocation.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/StackFrameList.h"
 #include "lldb/Target/Target.h"
@@ -13,18 +14,6 @@ using namespace lldb;
 using namespace lldb_private;
 
 namespace lldb_private {
-
-/// Stores a function module spec, symbol name and possibly an alternate symbol
-/// name.
-struct SymbolLocation {
-  FileSpec module_spec;
-  std::vector symbols;
-
-  // The symbols are regular expressions. In such case all symbols are matched
-  // with their trailing @VER symbol version stripped.
-  bool symbols_are_regex = false;
-};
-
 /// Fetches the abort frame location depending on the current platform.
 ///
 /// \param[in] os

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fixed the error `unable to launch a GDB server` in API tests (PR #98833)

2024-07-15 Thread Dmitry Vasilyev via lldb-commits

slydiman wrote:

It seems `StartDebugserverProcess()` ignores the port anyway and parameters 
`--min-gdbserver-port`, `--max-gdbserver-port`, `--gdbserver-port` are useless 
at all, but it is out of scope of this patch.

https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fixed the error `unable to launch a GDB server` in API tests (PR #98833)

2024-07-15 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman edited 
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (PR #98975)

2024-07-15 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Med Ismail Bennani (medismailben)


Changes

This patch hoists the `SymbolLocation` struct from the `AssertFrameRecognizer` 
source file, since it's pretty generic and could be reused for other purposes.

---
Full diff: https://github.com/llvm/llvm-project/pull/98975.diff


2 Files Affected:

- (added) lldb/include/lldb/Symbol/SymbolLocation.h (+32) 
- (modified) lldb/source/Target/AssertFrameRecognizer.cpp (+1-12) 


``diff
diff --git a/lldb/include/lldb/Symbol/SymbolLocation.h 
b/lldb/include/lldb/Symbol/SymbolLocation.h
new file mode 100644
index 0..be590c403b6e2
--- /dev/null
+++ b/lldb/include/lldb/Symbol/SymbolLocation.h
@@ -0,0 +1,32 @@
+//===-- SymbolLocation.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SYMBOL_SYMBOLLOCATION_H
+#define LLDB_SYMBOL_SYMBOLLOCATION_H
+
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/lldb-private.h"
+
+#include 
+
+namespace lldb_private {
+
+/// Stores a function module spec, symbol name and possibly an alternate symbol
+/// name.
+struct SymbolLocation {
+  FileSpec module_spec;
+  std::vector symbols;
+
+  // The symbols are regular expressions. In such case all symbols are matched
+  // with their trailing @VER symbol version stripped.
+  bool symbols_are_regex = false;
+};
+
+} // namespace lldb_private
+#endif // LLDB_SYMBOL_SYMBOLLOCATION_H
diff --git a/lldb/source/Target/AssertFrameRecognizer.cpp 
b/lldb/source/Target/AssertFrameRecognizer.cpp
index 5f4682bd5c11a..da7c102645c01 100644
--- a/lldb/source/Target/AssertFrameRecognizer.cpp
+++ b/lldb/source/Target/AssertFrameRecognizer.cpp
@@ -2,6 +2,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/SymbolLocation.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/StackFrameList.h"
 #include "lldb/Target/Target.h"
@@ -13,18 +14,6 @@ using namespace lldb;
 using namespace lldb_private;
 
 namespace lldb_private {
-
-/// Stores a function module spec, symbol name and possibly an alternate symbol
-/// name.
-struct SymbolLocation {
-  FileSpec module_spec;
-  std::vector symbols;
-
-  // The symbols are regular expressions. In such case all symbols are matched
-  // with their trailing @VER symbol version stripped.
-  bool symbols_are_regex = false;
-};
-
 /// Fetches the abort frame location depending on the current platform.
 ///
 /// \param[in] os

``




https://github.com/llvm/llvm-project/pull/98975
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] a7816c8 - git add a test file from a previous commit.

2024-07-15 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-07-15T16:02:10-07:00
New Revision: a7816c8e0086c1ae9b8ea15a6c252ca97f0405d1

URL: 
https://github.com/llvm/llvm-project/commit/a7816c8e0086c1ae9b8ea15a6c252ca97f0405d1
DIFF: 
https://github.com/llvm/llvm-project/commit/a7816c8e0086c1ae9b8ea15a6c252ca97f0405d1.diff

LOG: git add a test file from a previous commit.

A new file was added to the python_api/events test, but I forgot to
git add it before making the PR.  The commit was:

44d9692e6a657ec46e98e4912ac56417da67cfee

Added: 
lldb/test/API/python_api/event/stop_hook.py

Modified: 
lldb/unittests/Process/ProcessEventDataTest.cpp

Removed: 




diff  --git a/lldb/test/API/python_api/event/stop_hook.py 
b/lldb/test/API/python_api/event/stop_hook.py
new file mode 100644
index 0..932fa913366bc
--- /dev/null
+++ b/lldb/test/API/python_api/event/stop_hook.py
@@ -0,0 +1,35 @@
+import lldb
+import time
+
+class StopHook:
+# These dictionaries are used to pass data back to the test case.
+# Since these are global, we need to know which test run is which.
+# The test passes a key in the extra_args, we use that as the key
+# for these dictionaries, and then the test can fetch out the right
+# one.
+counter = {}
+non_stops = {}
+def __init__(self, target, extra_args, dict):
+self.target = target
+self.regs = {}
+self.instance = 
extra_args.GetValueForKey("instance").GetStringValue(100)
+StopHook.counter[self.instance] = 0
+StopHook.non_stops[self.instance] = 0
+
+def handle_stop(self, exe_ctx, stream):
+import time
+# All this stop hook does is sleep a bit and count.  There was a bug
+# where we were sending the secondary listener events when the
+# private state thread's DoOnRemoval completed, rather than when
+# the primary public process Listener consumes the event.  That
+# became really clear when a stop hook artificially delayed the
+# delivery of the primary listener's event - since IT had to come
+# after the stop hook ran.
+time.sleep(0.5)
+StopHook.counter[self.instance] += 1
+# When we were sending events too early, one symptom was the stop
+# event would get triggered before the state had been changed.
+# Watch for that here.
+if exe_ctx.process.GetState() != lldb.eStateStopped:
+StopHook.non_stops[self.instance] += 1
+

diff  --git a/lldb/unittests/Process/ProcessEventDataTest.cpp 
b/lldb/unittests/Process/ProcessEventDataTest.cpp
index e793c6eae20a2..9f65b71fc1c31 100644
--- a/lldb/unittests/Process/ProcessEventDataTest.cpp
+++ b/lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -142,6 +142,13 @@ ThreadSP CreateThread(ProcessSP &process_sp, bool 
should_stop,
   return thread_sp;
 }
 
+// Disable this test till I figure out why changing how events are sent
+// to Secondary Listeners (44d9692e6a657ec46e98e4912ac56417da67cfee)
+// caused this test to fail.  It is testing responses to events that are
+// not delivered in the way Process events are meant to be delivered, it
+// bypasses the private event queue, and I'm not sure is testing real
+// behaviors.
+#if 0
 TEST_F(ProcessEventDataTest, DoOnRemoval) {
   ArchSpec arch("x86_64-apple-macosx-");
 
@@ -181,6 +188,7 @@ TEST_F(ProcessEventDataTest, DoOnRemoval) {
->m_should_stop_hit_count == 0;
   ASSERT_TRUE(result);
 }
+#endif 
 
 TEST_F(ProcessEventDataTest, ShouldStop) {
   ArchSpec arch("x86_64-apple-macosx-");



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (PR #98975)

2024-07-15 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere approved this pull request.


https://github.com/llvm/llvm-project/pull/98975
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (PR #98975)

2024-07-15 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.


https://github.com/llvm/llvm-project/pull/98975
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fixed the error `unable to launch a GDB server` in API tests (PR #98833)

2024-07-15 Thread Dmitry Vasilyev via lldb-commits

https://github.com/slydiman edited 
https://github.com/llvm/llvm-project/pull/98833
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 1c85496 - [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (#98975)

2024-07-15 Thread via lldb-commits

Author: Med Ismail Bennani
Date: 2024-07-15T16:06:29-07:00
New Revision: 1c854965fb20b3b8e0118318357516428ac244b2

URL: 
https://github.com/llvm/llvm-project/commit/1c854965fb20b3b8e0118318357516428ac244b2
DIFF: 
https://github.com/llvm/llvm-project/commit/1c854965fb20b3b8e0118318357516428ac244b2.diff

LOG: [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it 
(#98975)

This patch hoists the `SymbolLocation` struct from the
`AssertFrameRecognizer` source file, since it's pretty generic and could
be reused for other purposes.

Signed-off-by: Med Ismail Bennani 

Added: 
lldb/include/lldb/Symbol/SymbolLocation.h

Modified: 
lldb/source/Target/AssertFrameRecognizer.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/SymbolLocation.h 
b/lldb/include/lldb/Symbol/SymbolLocation.h
new file mode 100644
index 0..be590c403b6e2
--- /dev/null
+++ b/lldb/include/lldb/Symbol/SymbolLocation.h
@@ -0,0 +1,32 @@
+//===-- SymbolLocation.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SYMBOL_SYMBOLLOCATION_H
+#define LLDB_SYMBOL_SYMBOLLOCATION_H
+
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/lldb-private.h"
+
+#include 
+
+namespace lldb_private {
+
+/// Stores a function module spec, symbol name and possibly an alternate symbol
+/// name.
+struct SymbolLocation {
+  FileSpec module_spec;
+  std::vector symbols;
+
+  // The symbols are regular expressions. In such case all symbols are matched
+  // with their trailing @VER symbol version stripped.
+  bool symbols_are_regex = false;
+};
+
+} // namespace lldb_private
+#endif // LLDB_SYMBOL_SYMBOLLOCATION_H

diff  --git a/lldb/source/Target/AssertFrameRecognizer.cpp 
b/lldb/source/Target/AssertFrameRecognizer.cpp
index 5f4682bd5c11a..da7c102645c01 100644
--- a/lldb/source/Target/AssertFrameRecognizer.cpp
+++ b/lldb/source/Target/AssertFrameRecognizer.cpp
@@ -2,6 +2,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/SymbolLocation.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/StackFrameList.h"
 #include "lldb/Target/Target.h"
@@ -13,18 +14,6 @@ using namespace lldb;
 using namespace lldb_private;
 
 namespace lldb_private {
-
-/// Stores a function module spec, symbol name and possibly an alternate symbol
-/// name.
-struct SymbolLocation {
-  FileSpec module_spec;
-  std::vector symbols;
-
-  // The symbols are regular expressions. In such case all symbols are matched
-  // with their trailing @VER symbol version stripped.
-  bool symbols_are_regex = false;
-};
-
 /// Fetches the abort frame location depending on the current platform.
 ///
 /// \param[in] os



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb/Symbol] Hoist SymbolLocation from AssertFrameRecognizer to reuse it (PR #98975)

2024-07-15 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben closed 
https://github.com/llvm/llvm-project/pull/98975
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix help syntax for add-dsym (target symbols add) (PR #98976)

2024-07-15 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/98976

The help output incorrectly states that this command takes a shared library 
name () while really it takes a path to a symbol file.

rdar://131777043

>From 6cc124159e40ca432eba328828c04a9f3d66f103 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Mon, 15 Jul 2024 16:29:15 -0700
Subject: [PATCH] [lldb] Fix help syntax for add-dsym (target symbols add)

The help output incorrectly states that this command takes a shared
library name () while really it takes a path to a symbol
file.

rdar://131777043
---
 lldb/source/Commands/CommandObjectTarget.cpp | 2 +-
 lldb/test/Shell/SymbolFile/add-dsym.test | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 80181a9b3cb71..d594330934ad7 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -4252,7 +4252,7 @@ class CommandObjectTargetSymbolsAdd : public 
CommandObjectParsed {
 m_option_group.Append(&m_current_stack_option, LLDB_OPT_SET_2,
   LLDB_OPT_SET_2);
 m_option_group.Finalize();
-AddSimpleArgumentList(eArgTypeShlibName);
+AddSimpleArgumentList(eArgTypeFilename);
   }
 
   ~CommandObjectTargetSymbolsAdd() override = default;
diff --git a/lldb/test/Shell/SymbolFile/add-dsym.test 
b/lldb/test/Shell/SymbolFile/add-dsym.test
index cdcba641957d1..52d1a1363feef 100644
--- a/lldb/test/Shell/SymbolFile/add-dsym.test
+++ b/lldb/test/Shell/SymbolFile/add-dsym.test
@@ -1,5 +1,8 @@
 # REQUIRES: system-darwin
 
+# RUN: %lldb -o 'help add-dsym' | FileCheck %s --check-prefix=HELP
+# HELP: Syntax: add-dsym  
+
 # RUN: yaml2obj %S/Inputs/a.yaml -o %t.out
 # RUN: LLDB_APPLE_DSYMFORUUID_EXECUTABLE=%S/Inputs/dsymforuuid.sh %lldb %t.out 
-o 'add-dsym -u 41945CA4-5D9D-3CDE-82B4-37E4C09750B5' 2>&1 | FileCheck %s
 # CHECK: UUID information was not found

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix help syntax for add-dsym (target symbols add) (PR #98976)

2024-07-15 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

The help output incorrectly states that this command takes a shared library 
name () while really it takes a path to a symbol file.

rdar://131777043

---
Full diff: https://github.com/llvm/llvm-project/pull/98976.diff


2 Files Affected:

- (modified) lldb/source/Commands/CommandObjectTarget.cpp (+1-1) 
- (modified) lldb/test/Shell/SymbolFile/add-dsym.test (+3) 


``diff
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 80181a9b3cb71..d594330934ad7 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -4252,7 +4252,7 @@ class CommandObjectTargetSymbolsAdd : public 
CommandObjectParsed {
 m_option_group.Append(&m_current_stack_option, LLDB_OPT_SET_2,
   LLDB_OPT_SET_2);
 m_option_group.Finalize();
-AddSimpleArgumentList(eArgTypeShlibName);
+AddSimpleArgumentList(eArgTypeFilename);
   }
 
   ~CommandObjectTargetSymbolsAdd() override = default;
diff --git a/lldb/test/Shell/SymbolFile/add-dsym.test 
b/lldb/test/Shell/SymbolFile/add-dsym.test
index cdcba641957d1..52d1a1363feef 100644
--- a/lldb/test/Shell/SymbolFile/add-dsym.test
+++ b/lldb/test/Shell/SymbolFile/add-dsym.test
@@ -1,5 +1,8 @@
 # REQUIRES: system-darwin
 
+# RUN: %lldb -o 'help add-dsym' | FileCheck %s --check-prefix=HELP
+# HELP: Syntax: add-dsym  
+
 # RUN: yaml2obj %S/Inputs/a.yaml -o %t.out
 # RUN: LLDB_APPLE_DSYMFORUUID_EXECUTABLE=%S/Inputs/dsymforuuid.sh %lldb %t.out 
-o 'add-dsym -u 41945CA4-5D9D-3CDE-82B4-37E4C09750B5' 2>&1 | FileCheck %s
 # CHECK: UUID information was not found

``




https://github.com/llvm/llvm-project/pull/98976
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix help syntax for add-dsym (target symbols add) (PR #98976)

2024-07-15 Thread via lldb-commits

jimingham wrote:

I'm a little surprised we don't have an argument type for eArgTypeSymbolFile.  
But I guess this is really the only command that uses it.
I don't think it matters all that much, however, eArgTypeFilename is fine.

https://github.com/llvm/llvm-project/pull/98976
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix help syntax for add-dsym (target symbols add) (PR #98976)

2024-07-15 Thread via lldb-commits

https://github.com/jimingham approved this pull request.

This is fine.

https://github.com/llvm/llvm-project/pull/98976
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] db9ac92 - Add lldb version into initialize response lldb-dap (#98703)

2024-07-15 Thread via lldb-commits

Author: jeffreytan81
Date: 2024-07-15T20:03:50-04:00
New Revision: db9ac92501509ce02ed188bb20a5211a9f29d5d3

URL: 
https://github.com/llvm/llvm-project/commit/db9ac92501509ce02ed188bb20a5211a9f29d5d3
DIFF: 
https://github.com/llvm/llvm-project/commit/db9ac92501509ce02ed188bb20a5211a9f29d5d3.diff

LOG: Add lldb version into initialize response lldb-dap (#98703)

Frequently, while troubleshooting user's debugging issues in VScode, we
would like to know lldb version so that we can confirm if certain
patch/feature is in or not.

This PR adds version string into `initialize` response so that telemetry
can track it.

-

Co-authored-by: jeffreytan81 

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py 
b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
index b1b3d05ed4548..dd47a2db8709b 100644
--- a/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
+++ b/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
@@ -475,3 +475,34 @@ def test_terminate_commands(self):
 pattern=terminateCommands[0],
 )
 self.verify_commands("terminateCommands", output, terminateCommands)
+
+@skipIfWindows
+def test_version(self):
+"""
+Tests that "initialize" response contains the "version" string the same
+as the one returned by "version" command.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+source = "main.c"
+breakpoint_line = line_number(source, "// breakpoint 1")
+lines = [breakpoint_line]
+# Set breakpoint in the thread function so we can step the threads
+breakpoint_ids = self.set_source_breakpoints(source, lines)
+self.continue_to_breakpoints(breakpoint_ids)
+
+version_eval_response = self.dap_server.request_evaluate(
+"`version", context="repl"
+)
+version_eval_output = version_eval_response["body"]["result"]
+
+# The first line is the prompt line like "(lldb) version", so we skip 
it.
+version_eval_output_without_prompt_line = 
version_eval_output.splitlines()[1:]
+lldb_json = self.dap_server.get_initialize_value("__lldb")
+version_string = lldb_json["version"]
+self.assertEqual(
+version_eval_output_without_prompt_line,
+version_string.splitlines(),
+"version string does not match",
+)

diff  --git a/lldb/tools/lldb-dap/lldb-dap.cpp 
b/lldb/tools/lldb-dap/lldb-dap.cpp
index b50d40acb51a2..ea84f31aec3a6 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -1719,6 +1719,11 @@ void request_initialize(const llvm::json::Object 
&request) {
   // The debug adapter supports data watchpoints.
   body.try_emplace("supportsDataBreakpoints", true);
 
+  // Put in non-DAP specification lldb specific information.
+  llvm::json::Object lldb_json;
+  lldb_json.try_emplace("version", g_dap.debugger.GetVersionString());
+  body.try_emplace("__lldb", std::move(lldb_json));
+
   response.try_emplace("body", std::move(body));
   g_dap.SendJSON(llvm::json::Value(std::move(response)));
 }



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add lldb version into initialize response lldb-dap (PR #98703)

2024-07-15 Thread via lldb-commits

https://github.com/jeffreytan81 closed 
https://github.com/llvm/llvm-project/pull/98703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits


@@ -195,20 +196,40 @@ ModuleSP DynamicLoader::LoadBinaryWithUUIDAndAddress(
   Target &target = process->GetTarget();
   Status error;
 
+  StreamString prog_str;
+  if (!name.empty()) {
+prog_str << name.str() << " ";
+  }
+  if (uuid.IsValid())
+prog_str << uuid.GetAsString();
+  if (value_is_offset == 0 && value != LLDB_INVALID_ADDRESS) {
+prog_str << "at 0x";
+prog_str.PutHex64(value);
+  }
+
   if (!uuid.IsValid() && !value_is_offset) {
+Progress progress_memread("Reading load commands from memory",

jasonmolenda wrote:

Good suggestion.  I think I'll conditionalize this progress with a `if 
(!process->GetCoreFile())` -- reading a binary out of a local corefile will be 
very fast.  Over a live gdb-remote connection, not so much.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits


@@ -195,20 +196,40 @@ ModuleSP DynamicLoader::LoadBinaryWithUUIDAndAddress(
   Target &target = process->GetTarget();
   Status error;
 
+  StreamString prog_str;
+  if (!name.empty()) {
+prog_str << name.str() << " ";
+  }
+  if (uuid.IsValid())
+prog_str << uuid.GetAsString();
+  if (value_is_offset == 0 && value != LLDB_INVALID_ADDRESS) {
+prog_str << "at 0x";
+prog_str.PutHex64(value);
+  }
+
   if (!uuid.IsValid() && !value_is_offset) {
+Progress progress_memread("Reading load commands from memory",
+  prog_str.GetString().str());
 memory_module_sp = ReadUnnamedMemoryModule(process, value, name);
 
-if (memory_module_sp)
+if (memory_module_sp) {
   uuid = memory_module_sp->GetUUID();
+  if (uuid.IsValid()) {
+prog_str << " ";
+prog_str << uuid.GetAsString();
+  }
+}
   }
   ModuleSpec module_spec;
   module_spec.GetUUID() = uuid;
   FileSpec name_filespec(name);
-  if (FileSystem::Instance().Exists(name_filespec))
-module_spec.GetFileSpec() = name_filespec;
 
   if (uuid.IsValid()) {
+Progress progress("Locating external symbol file",
+  prog_str.GetString().str());
+
 // Has lldb already seen a module with this UUID?
+// Or have external lookup enabled in DebugSymbols on macOS.

jasonmolenda wrote:

It's a little tricky because we do call ModuleList::GetSharedModule which will 
return a module if it's already in the global module cache, and it will call 
into the DebugSymbols framework on macOS, where it might call an external 
program to do a slow copy of a binary to the local computer.   But after that, 
it then goes on to call `LocateExecutableSymbolFile` 
`LocateExecutableObjectFile` looking in known local filesystem locations.  If 
that fails, then it calls `DownloadObjectAndSymbolFile 
(force_symbol_search=true)` which can call out to an external program to do a 
slow copy of a binary to the local computer.

I wanted to log one message to cover possibly all of these being run.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/98845

>From cead9ae6de627ee64fb58a829fa3485f526a0afc Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Sun, 14 Jul 2024 16:59:51 -0700
Subject: [PATCH 1/3] [lldb] progressive progress reporting for darwin
 kernel/firmware

When doing firmware/kernel debugging, it is frequent that
binaries and debug info need to be retrieved / downloaded,
and the lack of progress reports made for a poor experience,
with lldb seemingly hung while downloading things over the
network. This PR adds progress reports to the critical sites
for these use cases.
---
 lldb/source/Core/DynamicLoader.cpp| 27 +++--
 .../DynamicLoaderDarwinKernel.cpp | 39 ---
 2 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/lldb/source/Core/DynamicLoader.cpp 
b/lldb/source/Core/DynamicLoader.cpp
index 7871be6fc451d..a59136381c23b 100644
--- a/lldb/source/Core/DynamicLoader.cpp
+++ b/lldb/source/Core/DynamicLoader.cpp
@@ -13,6 +13,7 @@
 #include "lldb/Core/ModuleList.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/MemoryRegionInfo.h"
@@ -195,20 +196,40 @@ ModuleSP DynamicLoader::LoadBinaryWithUUIDAndAddress(
   Target &target = process->GetTarget();
   Status error;
 
+  StreamString prog_str;
+  if (!name.empty()) {
+prog_str << name.str() << " ";
+  }
+  if (uuid.IsValid())
+prog_str << uuid.GetAsString();
+  if (value_is_offset == 0 && value != LLDB_INVALID_ADDRESS) {
+prog_str << "at ";
+prog_str.PutHex64(value);
+  }
+
   if (!uuid.IsValid() && !value_is_offset) {
+Progress progress_memread("Reading load commands from memory",
+  prog_str.GetString().str());
 memory_module_sp = ReadUnnamedMemoryModule(process, value, name);
 
-if (memory_module_sp)
+if (memory_module_sp) {
   uuid = memory_module_sp->GetUUID();
+  if (uuid.IsValid()) {
+prog_str << " ";
+prog_str << uuid.GetAsString();
+  }
+}
   }
   ModuleSpec module_spec;
   module_spec.GetUUID() = uuid;
   FileSpec name_filespec(name);
-  if (FileSystem::Instance().Exists(name_filespec))
-module_spec.GetFileSpec() = name_filespec;
 
   if (uuid.IsValid()) {
+Progress progress("Locating external symbol file",
+  prog_str.GetString().str());
+
 // Has lldb already seen a module with this UUID?
+// Or have external lookup enabled in DebugSymbols on macOS.
 if (!module_sp)
   error = ModuleList::GetSharedModule(module_spec, module_sp, nullptr,
   nullptr, nullptr);
diff --git 
a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp 
b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
index 8d83937aab668..93eb1e7b9dea9 100644
--- 
a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
+++ 
b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
@@ -13,6 +13,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Interpreter/OptionValueProperties.h"
 #include "lldb/Symbol/ObjectFile.h"
@@ -757,6 +758,23 @@ bool 
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule(
 const ModuleList &target_images = target.GetImages();
 m_module_sp = target_images.FindModule(m_uuid);
 
+std::unique_ptr progress_up;
+if (IsKernel()) {
+  StreamString prog_str;
+  // 'mach_kernel' is a fake name we make up to find kernels
+  // that were located by the local filesystem scan.
+  if (GetName() != "mach_kernel")
+prog_str << GetName() << " ";
+  if (GetUUID().IsValid())
+prog_str << GetUUID().GetAsString() << " ";
+  if (GetLoadAddress() != LLDB_INVALID_ADDRESS) {
+prog_str << "at ";
+prog_str.PutHex64(GetLoadAddress());
+  }
+  progress_up = std::make_unique("Loading kernel",
+   prog_str.GetString().str());
+}
+
 // Search for the kext on the local filesystem via the UUID
 if (!m_module_sp && m_uuid.IsValid()) {
   ModuleSpec module_spec;
@@ -1058,12 +1076,9 @@ void 
DynamicLoaderDarwinKernel::LoadKernelModuleIfNeeded() {
 }
   }
 }
-
-if (m_kernel.GetLoadAddress() != LLDB_INVALID_ADDRESS) {
-  if (!m_kernel.LoadImageUsingMemoryModule(m_process)) {
+if (m_kernel.GetLoadAddress() != LLDB_INVALID_ADDRESS)
+  if (!m_kernel.LoadImageUsingMemoryModule(m_process))
 m_kernel.LoadImageAtFileAddress(m_process);
-  }
-}
 
 // The operating system plugin gets loaded and initialized in
 // LoadImageUsingMemoryModule when we

[Lldb-commits] [lldb] [lldb] progressive progress reporting for darwin kernel/firmware (PR #98845)

2024-07-15 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

Thanks for the helpful feedback @clayborg pushed an update.

https://github.com/llvm/llvm-project/pull/98845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 27b2f4f - [LLDB] Revert #98351 and #98344

2024-07-15 Thread walter erquinigo via lldb-commits

Author: walter erquinigo
Date: 2024-07-15T23:00:17-04:00
New Revision: 27b2f4f861b8aeeabc4eb1a97649062de8fa3992

URL: 
https://github.com/llvm/llvm-project/commit/27b2f4f861b8aeeabc4eb1a97649062de8fa3992
DIFF: 
https://github.com/llvm/llvm-project/commit/27b2f4f861b8aeeabc4eb1a97649062de8fa3992.diff

LOG: [LLDB] Revert #98351 and #98344

This reverts commit 2fa1220a37a3f55b76a29803d8333b3a3937d53a.
This reverts commit b9496a74eb4029629ca2e440c5441614e766f773.

The patch #98344 causes a crash in LLDB when parsing some files like 
`numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in 
https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link
 if you want to troubleshoot yourself).

The assert that is hit is the following:

```
llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: 
std::pair 
> ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, 
lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed.
[383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] 
Crashpad isn't enabled
```

This object file doesn't have apparently a strings table but LLDB still tries 
to process it due to the code that is being reverted.

Added: 


Modified: 
lldb/include/lldb/Host/Config.h.cmake
lldb/packages/Python/lldbsuite/test/decorators.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
lldb/source/API/SBDebugger.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolLocator/CMakeLists.txt
lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp

Removed: 
lldb/test/API/debuginfod/Normal/Makefile
lldb/test/API/debuginfod/Normal/TestDebuginfod.py
lldb/test/API/debuginfod/Normal/main.c
lldb/test/API/debuginfod/SplitDWARF/Makefile
lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py
lldb/test/API/debuginfod/SplitDWARF/main.c



diff  --git a/lldb/include/lldb/Host/Config.h.cmake 
b/lldb/include/lldb/Host/Config.h.cmake
index 9e538534086a2..3defa454f6d42 100644
--- a/lldb/include/lldb/Host/Config.h.cmake
+++ b/lldb/include/lldb/Host/Config.h.cmake
@@ -33,8 +33,6 @@
 
 #cmakedefine01 LLDB_ENABLE_LZMA
 
-#cmakedefine01 LLVM_ENABLE_CURL
-
 #cmakedefine01 LLDB_ENABLE_CURSES
 
 #cmakedefine01 CURSES_HAVE_NCURSES_CURSES_H

diff  --git a/lldb/packages/Python/lldbsuite/test/decorators.py 
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 0e8ca159efd55..ecc7b81035f11 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -1053,10 +1053,6 @@ def _get_bool_config_skip_if_decorator(key):
 return unittest.skipIf(not have, "requires " + key)
 
 
-def skipIfCurlSupportMissing(func):
-return _get_bool_config_skip_if_decorator("curl")(func)
-
-
 def skipIfCursesSupportMissing(func):
 return _get_bool_config_skip_if_decorator("curses")(func)
 

diff  --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules 
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index d1a2de8b2478a..3d562285ce9cc 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -51,7 +51,7 @@ LLDB_BASE_DIR := $(THIS_FILE_DIR)/../../../../../
 #
 # GNUWin32 uname gives "windows32" or "server version windows32" while
 # some versions of MSYS uname return "MSYS_NT*", but most environments
-# standardize on "Windows_NT", so we'll make it consistent here.
+# standardize on "Windows_NT", so we'll make it consistent here. 
 # When running tests from Visual Studio, the environment variable isn't
 # inherited all the way down to the process spawned for make.
 #--
@@ -213,12 +213,6 @@ else
ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES"
DSYM = $(EXE).debug
endif
-
-   ifeq "$(MAKE_DWP)" "YES"
-   MAKE_DWO := YES
-   DWP_NAME = $(EXE).dwp
-   DYLIB_DWP_NAME = $(DYLIB_NAME).dwp
-   endif
 endif
 
 LIMIT_DEBUG_INFO_FLAGS =
@@ -367,17 +361,6 @@ ifneq "$(OS)" "Darwin"
 
OBJCOPY ?= $(call replace_cc_with,objcopy)
ARCHIVER ?= $(call replace_cc_with,ar)
-   # Look for llvm-dwp or gnu dwp
-   DWP ?= $(call replace_cc_with,llvm-dwp)
-   ifeq ($(wildcard $(DWP)),)
-   DWP = $(call replace_cc_with,dwp)
-   ifeq ($(wildcard $(DWP)),)
-   DWP = $(shell command -v llvm-dwp 2> /dev/null)
-   ifeq ($(wildcard $(DWP)),)
-   DWP = $(shell command -v dwp 2> /dev/null)
-   endif
-   endif
-   endif
override AR = $(ARCHIVER)
 endif
 
@@ -548,10 +531,6 @@ ifneq "$(CXX)" ""
endif
 endif
 
-ifeq "$(GEN_GNU_BUILD_ID)" "YES"
-   LDF

[Lldb-commits] [lldb] [lldb] DebugInfoD tests & fixes (but with dwp testing disabled) (PR #98344)

2024-07-15 Thread Walter Erquinigo via lldb-commits

walter-erquinigo wrote:

@kevinfrei , I'm so sorry to tell you that I have reverted this patch. The 
revert commit is 27b2f4f861b8aeeabc4eb1a97649062de8fa3992 and I left some notes 
there, which I also copy here:


The patch #98344 causes a crash in LLDB when parsing some files like 
`numpy.libs/libgfortran-daac5196.so.5.0.0` on graviton (you can download it in 
https://drive.google.com/file/d/12ygLjJwWpzdYsrzBPp1JGiFHxcgM0-XY/view?usp=drive_link
 if you want to troubleshoot yourself).

The assert that is hit is the following:

```
llvm-project/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2452: 
std::pair 
> ObjectFileELF::ParseSymbolTable(lldb_private::Symtab*, lldb::user_id_t, 
lldb_private::Section*): Assertion `strtab->GetObjectFile() == this' failed.
[383588:383636:20240716,025305.572639:ERROR crashpad_client_linux.cc:780] 
Crashpad isn't enabled


https://github.com/llvm/llvm-project/pull/98344
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][lldb] Don't assert structure layout correctness for layouts provided by LLDB (PR #93809)

2024-07-15 Thread Michael Buch via lldb-commits

Michael137 wrote:

Closing in favour of https://github.com/llvm/llvm-project/pull/96422

https://github.com/llvm/llvm-project/pull/93809
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][lldb] Don't assert structure layout correctness for layouts provided by LLDB (PR #93809)

2024-07-15 Thread Michael Buch via lldb-commits

https://github.com/Michael137 closed 
https://github.com/llvm/llvm-project/pull/93809
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits