[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
@@ -0,0 +1,40 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows vogelsgesang wrote: @walter-erquinigo based on https://github.com/llvm/llvm-project/pull/105604, it seems that all DAP tests are in fact disabled for Windows. Should I reintroduce the `SkipIfWindows`? https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
DavidSpickett wrote: Does anyone know why these tests are disabled, is there one underlying reason? https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][aix] Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/DavidSpickett approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/105523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/DavidSpickett edited https://github.com/llvm/llvm-project/pull/105523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 1b664fe - [lldb][AIX] Updating XCOFF, PPC entry in LLDB ArchSpec (#105523)
Author: Dhruv Srivastava
Date: 2024-08-22T09:56:49+01:00
New Revision: 1b664fe2548d4cd5ce7a495cde4a86b5531af123
URL:
https://github.com/llvm/llvm-project/commit/1b664fe2548d4cd5ce7a495cde4a86b5531af123
DIFF:
https://github.com/llvm/llvm-project/commit/1b664fe2548d4cd5ce7a495cde4a86b5531af123.diff
LOG: [lldb][AIX] Updating XCOFF,PPC entry in LLDB ArchSpec (#105523)
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657
The complete changes for porting are present in this draft PR:
#102601
The changes in this PR are intended to update the Architecture entry for
LLDB with XCOFF,PPC.
1. Added new ArchitectureType `eArchTypeXCOFF`
2. Added a new `ArchDefinitionEntry g_xcoff_arch_entries[]`
3. Added a new case for `XCOFF in ArchSpec::SetArchitecture(..)`
4. Updated `ArchDefinition *g_arch_definitions[]`
Added:
Modified:
lldb/include/lldb/lldb-private-enumerations.h
lldb/source/Utility/ArchSpec.cpp
Removed:
diff --git a/lldb/include/lldb/lldb-private-enumerations.h
b/lldb/include/lldb/lldb-private-enumerations.h
index c24a3538f58dac..98c1e956bf8f7b 100644
--- a/lldb/include/lldb/lldb-private-enumerations.h
+++ b/lldb/include/lldb/lldb-private-enumerations.h
@@ -65,6 +65,7 @@ enum ArchitectureType {
eArchTypeMachO,
eArchTypeELF,
eArchTypeCOFF,
+ eArchTypeXCOFF,
kNumArchTypes
};
diff --git a/lldb/source/Utility/ArchSpec.cpp
b/lldb/source/Utility/ArchSpec.cpp
index 07ef435ef451d2..4fd1a800023ce3 100644
--- a/lldb/source/Utility/ArchSpec.cpp
+++ b/lldb/source/Utility/ArchSpec.cpp
@@ -16,6 +16,7 @@
#include "llvm/BinaryFormat/COFF.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/BinaryFormat/MachO.h"
+#include "llvm/BinaryFormat/XCOFF.h"
#include "llvm/Support/Compiler.h"
#include "llvm/TargetParser/ARMTargetParser.h"
@@ -459,10 +460,23 @@ static const ArchDefinition g_coff_arch_def = {
"pe-coff",
};
+static const ArchDefinitionEntry g_xcoff_arch_entries[] = {
+{ArchSpec::eCore_ppc_generic, llvm::XCOFF::TCPU_COM, LLDB_INVALID_CPUTYPE,
+ 0xu, 0xu},
+{ArchSpec::eCore_ppc64_generic, llvm::XCOFF::TCPU_PPC64,
+ LLDB_INVALID_CPUTYPE, 0xu, 0xu}};
+
+static const ArchDefinition g_xcoff_arch_def = {
+eArchTypeXCOFF,
+std::size(g_xcoff_arch_entries),
+g_xcoff_arch_entries,
+"xcoff",
+};
+
//===--===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
-&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
+&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def, &g_xcoff_arch_def};
//===--===//
// Static helper functions.
@@ -903,6 +917,9 @@ bool ArchSpec::SetArchitecture(ArchitectureType arch_type,
uint32_t cpu,
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
+} else if (arch_type == eArchTypeXCOFF && os == llvm::Triple::AIX) {
+ m_triple.setVendor(llvm::Triple::IBM);
+ m_triple.setOS(llvm::Triple::AIX);
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Updating XCOFF, PPC entry in LLDB ArchSpec (PR #105523)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/105523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][RISCV] Support optionally disabled FPR (PR #104547)
DavidSpickett wrote: Just from lldb's side, the code is organised such that we end up with separate code for 32 and 64 bit in a lot of cases. So a PR for 64 bit only is fine (in fact preferable, as this PR will provide a template for anyone wanting to implement 32 bit support). Of course it's up to @AlexeyMerzlyakov what their plans are here. https://github.com/llvm/llvm-project/pull/104547 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend frame recognizers to hide frames from backtraces (PR #104523)
gribozavr wrote: @adrian-prantl I'm going to revert this PR because it fails msan due to uninitialized variables. Specifically, `StackFrame::m_frame_recognizer_generation` and `StackFrameRecognizerManager::m_generation` are never initialized. Sample msan failure on `lldb/test/Shell/Unwind/eh-frame-small-fde`: ``` ==4576==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x557c5364 in lldb_private::StackFrame::GetRecognizedFrame() third_party/llvm/llvm-project/lldb/source/Target/StackFrame.cpp:1986:7 #1 0x557d24e7 in lldb_private::StackFrameList::SelectMostRelevantFrame() third_party/llvm/llvm-project/lldb/source/Target/StackFrameList.cpp:817:58 #2 0x557d2ba2 in lldb_private::StackFrameList::GetSelectedFrameIndex(SelectMostRelevant) third_party/llvm/llvm-project/lldb/source/Target/StackFrameList.cpp:838:5 #3 0x55799920ee11 in lldb_private::Thread::GetSelectedFrameIndex(SelectMostRelevant) third_party/llvm/llvm-project/lldb/include/lldb/Target/Thread.h:445:33 #4 0x55771af0 in lldb_private::Process::HandleProcessStateChangedEvent(std::__msan::shared_ptr const&, lldb_private::Stream*, SelectMostRelevant, bool&) third_party/llvm/llvm-project/lldb/source/Target/Process.cpp:939:26 #5 0x5577025d in lldb_private::Process::WaitForProcessToStop(lldb_private::Timeout> const&, std::__msan::shared_ptr*, bool, std::__msan::shared_ptr, lldb_private::Stream*, bool, SelectMostRelevant) third_party/llvm/llvm-project/lldb/source/Target/Process.cpp:722:5 #6 0x5577676f in lldb_private::Process::ResumeSynchronous(lldb_private::Stream*) third_party/llvm/llvm-project/lldb/source/Target/Process.cpp:1415:9 #7 0x557999a198e1 in lldb_private::Target::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::Stream*) third_party/llvm/llvm-project/lldb/source/Target/Target.cpp:3339:21 #8 0x557999274a55 in CommandObjectProcessLaunch::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) third_party/llvm/llvm-project/lldb/source/Commands/CommandObjectProcess.cpp:236:28 #9 0x55799933f44c in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandObject.cpp:835:9 #10 0x55799916d868 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2071:14 #11 0x557999176120 in lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__msan::basic_string, std::__msan::allocator>&) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:3167:3 #12 0x55799917656c in non-virtual thunk to lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__msan::basic_string, std::__msan::allocat or>&) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp #13 0x55799902338c in lldb_private::IOHandlerEditline::Run() third_party/llvm/llvm-project/lldb/source/Core/IOHandler.cpp:600:22 #14 0x557998fdbbff in lldb_private::Debugger::RunIOHandlerSync(std::__msan::shared_ptr const&) third_party/llvm/llvm-project/lldb/source/Core/Debugger.cpp:1131:20 #15 0x5579991715f9 in lldb_private::CommandInterpreter::HandleCommandsFromFile(lldb_private::FileSpec&, lldb_private::CommandInterpreterRunOptions const&, lldb_private::CommandReturnObject&) third_party/llvm/ll vm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2853:12 #16 0x5579991ab51e in CommandObjectCommandsSource::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) third_party/llvm/llvm-project/lldb/source/Commands/CommandObjectCommands.cpp:169:19 #17 0x55799933f44c in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandObject.cpp:835:9 #18 0x55799916d868 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) third_party/llvm/llvm-project/lldb/source/Interpreter/Command Interpreter.cpp:2071:14 #19 0x557999176120 in lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__msan::basic_string, std::__msan::allocator>&) third_par ty/llvm/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:3167:3 #20 0x55799917656c in non-virtual thunk to lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__msan::basic_string, std::__msan::allocat or>&) third_party/llvm/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp #21 0x55799902338c in lldb_private::IOHandlerEditline::Run() third_party/llvm/llvm-project/lldb/source/Core/IOHandler.cpp:600:22 #22 0x557998fdb7d6 in lldb_private::Debugger::RunIOHandlers() third_party/llvm/llv
[Lldb-commits] [lldb] 7323e7e - Revert "[lldb][swig] Use the correct variable in the return statement"
Author: Dmitri Gribenko Date: 2024-08-22T13:14:30+02:00 New Revision: 7323e7eee3a819e9a2d8ec29f00d362bcad87731 URL: https://github.com/llvm/llvm-project/commit/7323e7eee3a819e9a2d8ec29f00d362bcad87731 DIFF: https://github.com/llvm/llvm-project/commit/7323e7eee3a819e9a2d8ec29f00d362bcad87731.diff LOG: Revert "[lldb][swig] Use the correct variable in the return statement" This reverts commit 65281570afd7e35e01533b07c6c2937de410fc52. I'm reverting https://github.com/llvm/llvm-project/pull/104523 (https://github.com/llvm/llvm-project/commit/f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9) and this fixup belongs to the same series of changes. Added: Modified: lldb/bindings/python/python-wrapper.swig Removed: diff --git a/lldb/bindings/python/python-wrapper.swig b/lldb/bindings/python/python-wrapper.swig index 360c392235a866..2ce42e3e017d5b 100644 --- a/lldb/bindings/python/python-wrapper.swig +++ b/lldb/bindings/python/python-wrapper.swig @@ -837,7 +837,7 @@ bool lldb_private::python::SWIGBridge::LLDBSwigPython_ShouldHide( bool ret_val = result ? PyObject_IsTrue(result) : false; Py_XDECREF(result); - return ret_val; + return result; } void *lldb_private::python::SWIGBridge::LLDBSWIGPython_GetDynamicSetting( ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 547917a - Revert "[lldb] Extend frame recognizers to hide frames from backtraces (#104523)"
Author: Dmitri Gribenko
Date: 2024-08-22T13:24:57+02:00
New Revision: 547917aebd1e79a8929b53f0ddf3b5185ee4df74
URL:
https://github.com/llvm/llvm-project/commit/547917aebd1e79a8929b53f0ddf3b5185ee4df74
DIFF:
https://github.com/llvm/llvm-project/commit/547917aebd1e79a8929b53f0ddf3b5185ee4df74.diff
LOG: Revert "[lldb] Extend frame recognizers to hide frames from backtraces
(#104523)"
This reverts commit f01f80ce6ca7640bb0e267b84b1ed0e89b57e2d9.
This commit introduces an msan violation. See the discussion on
https://github.com/llvm/llvm-project/pull/104523.
Added:
Modified:
lldb/bindings/python/python-wrapper.swig
lldb/include/lldb/API/SBFrame.h
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/include/lldb/Target/StackFrame.h
lldb/include/lldb/Target/StackFrameList.h
lldb/include/lldb/Target/StackFrameRecognizer.h
lldb/include/lldb/Target/Thread.h
lldb/source/API/SBFrame.cpp
lldb/source/API/SBThread.cpp
lldb/source/Commands/CommandCompletions.cpp
lldb/source/Commands/CommandObjectFrame.cpp
lldb/source/Commands/CommandObjectMemory.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Commands/Options.td
lldb/source/Core/Debugger.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
lldb/source/Target/Process.cpp
lldb/source/Target/StackFrame.cpp
lldb/source/Target/StackFrameList.cpp
lldb/source/Target/StackFrameRecognizer.cpp
lldb/source/Target/Thread.cpp
lldb/source/Target/ThreadPlanStepOut.cpp
lldb/test/API/commands/frame/recognizer/TestFrameRecognizer.py
lldb/test/API/commands/frame/recognizer/main.m
lldb/test/API/commands/frame/recognizer/recognizer.py
Removed:
lldb/test/API/lang/cpp/std-function-recognizer/Makefile
lldb/test/API/lang/cpp/std-function-recognizer/TestStdFunctionRecognizer.py
lldb/test/API/lang/cpp/std-function-recognizer/main.cpp
diff --git a/lldb/bindings/python/python-wrapper.swig
b/lldb/bindings/python/python-wrapper.swig
index 2ce42e3e017d5b..8f050643fa68b3 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -813,7 +813,7 @@ PythonObject
lldb_private::python::SWIGBridge::LLDBSWIGPython_CreateFrameRecogni
}
PyObject
*lldb_private::python::SWIGBridge::LLDBSwigPython_GetRecognizedArguments(
-PyObject *implementor, const lldb::StackFrameSP &frame_sp) {
+PyObject * implementor, const lldb::StackFrameSP &frame_sp) {
static char callee_name[] = "get_recognized_arguments";
PythonObject arg = SWIGBridge::ToSWIGWrapper(frame_sp);
@@ -824,22 +824,6 @@ PyObject
*lldb_private::python::SWIGBridge::LLDBSwigPython_GetRecognizedArgument
return result;
}
-bool lldb_private::python::SWIGBridge::LLDBSwigPython_ShouldHide(
-PyObject *implementor, const lldb::StackFrameSP &frame_sp) {
- static char callee_name[] = "should_hide";
-
- PythonObject arg = SWIGBridge::ToSWIGWrapper(frame_sp);
-
- PythonString str(callee_name);
-
- PyObject *result =
- PyObject_CallMethodObjArgs(implementor, str.get(), arg.get(), NULL);
- bool ret_val = result ? PyObject_IsTrue(result) : false;
- Py_XDECREF(result);
-
- return result;
-}
-
void *lldb_private::python::SWIGBridge::LLDBSWIGPython_GetDynamicSetting(
void *module, const char *setting, const lldb::TargetSP &target_sp) {
if (!module || !setting)
diff --git a/lldb/include/lldb/API/SBFrame.h b/lldb/include/lldb/API/SBFrame.h
index e0d15c3ecc5b1c..821ff3cf7ce519 100644
--- a/lldb/include/lldb/API/SBFrame.h
+++ b/lldb/include/lldb/API/SBFrame.h
@@ -104,10 +104,6 @@ class LLDB_API SBFrame {
bool IsArtificial() const;
- /// Return whether a frame recognizer decided this frame should not
- /// be displayes in backtraces etc.
- bool IsHidden() const;
-
/// The version that doesn't supply a 'use_dynamic' value will use the
/// target's default.
lldb::SBValue EvaluateExpression(const char *expr);
diff --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index 89a480a28880aa..05f0d7f0955f3e 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -252,11 +252,6 @@ class ScriptInterpreter : public PluginInterface {
return lldb::ValueObjectListSP();
}
- virtual bool ShouldHide(const StructuredData::ObjectSP &implementor,
- lldb::StackFrameSP frame_sp) {
-return false;
- }
-
virtual StructuredData::GenericSP
CreateScriptedBreakpointResolver(const char *class_name,
[Lldb-commits] [lldb] aa70f83 - Revert "[lldb-dap] Mark hidden frames as "subtle" (#105457)"
Author: Dmitri Gribenko
Date: 2024-08-22T13:24:57+02:00
New Revision: aa70f83e660453c006193aab7ba67c94db236948
URL:
https://github.com/llvm/llvm-project/commit/aa70f83e660453c006193aab7ba67c94db236948
DIFF:
https://github.com/llvm/llvm-project/commit/aa70f83e660453c006193aab7ba67c94db236948.diff
LOG: Revert "[lldb-dap] Mark hidden frames as "subtle" (#105457)"
This reverts commit 6f456024c37424d9c8cc1cea07126a28f246588d, which
depends on https://github.com/llvm/llvm-project/pull/104523, which I'm
reverting.
Added:
Modified:
lldb/tools/lldb-dap/JSONUtils.cpp
Removed:
lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/Makefile
lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/main.cpp
diff --git a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/Makefile
b/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/Makefile
deleted file mode 100644
index 8b20bcb050..00
--- a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-CXX_SOURCES := main.cpp
-
-include Makefile.rules
diff --git
a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
b/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
deleted file mode 100644
index 1e41e841e39bc8..00
---
a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.py
+++ /dev/null
@@ -1,29 +0,0 @@
-"""
-Test lldb-dap stack trace response
-"""
-
-
-import dap_server
-from lldbsuite.test.decorators import *
-
-import lldbdap_testcase
-from lldbsuite.test.lldbtest import *
-
-
-class TestDAP_subtleFrames(lldbdap_testcase.DAPTestCaseBase):
-@add_test_categories(["libc++"])
-def test_subtleFrames(self):
-"""
-Internal stack frames (such as the ones used by `std::function`) are
marked as "subtle".
-"""
-program = self.getBuildArtifact("a.out")
-self.build_and_launch(program)
-source = "main.cpp"
-self.set_source_breakpoints(source, [line_number(source, "BREAK
HERE")])
-self.continue_to_next_stop()
-
-frames = self.get_stackFrames()
-for f in frames:
-if "__function" in f["name"]:
-self.assertEqual(f["presentationHint"], "subtle")
-self.assertTrue(any(f.get("presentationHint") == "subtle" for f in
frames))
diff --git a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/main.cpp
b/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/main.cpp
deleted file mode 100644
index 71944528441e38..00
--- a/lldb/test/API/tools/lldb-dap/stackTrace/subtleFrames/main.cpp
+++ /dev/null
@@ -1,13 +0,0 @@
-#include
-#include
-
-void greet() {
- // BREAK HERE
- std::cout << "Hello\n";
-}
-
-int main() {
- std::function func{greet};
- func();
- return 0;
-}
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp
b/lldb/tools/lldb-dap/JSONUtils.cpp
index c080fd395b7288..a8b85f55939e17 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -763,9 +763,6 @@ llvm::json::Value CreateStackFrame(lldb::SBFrame &frame) {
object.try_emplace("instructionPointerReference", formatted_addr);
}
- if (frame.IsArtificial() || frame.IsHidden())
-object.try_emplace("presentationHint", "subtle");
-
return llvm::json::Value(std::move(object));
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Mark hidden frames as "subtle" (PR #105457)
gribozavr wrote: Sorry, but I had to revert this PR because it depends on https://github.com/llvm/llvm-project/pull/104523, which I'm reverting because it fails under msan. Revert commits: https://github.com/llvm/llvm-project/commit/7323e7eee3a819e9a2d8ec29f00d362bcad87731 https://github.com/llvm/llvm-project/commit/aa70f83e660453c006193aab7ba67c94db236948 https://github.com/llvm/llvm-project/commit/547917aebd1e79a8929b53f0ddf3b5185ee4df74 https://github.com/llvm/llvm-project/pull/105457 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend frame recognizers to hide frames from backtraces (PR #104523)
gribozavr wrote: Revert commits: https://github.com/llvm/llvm-project/commit/7323e7eee3a819e9a2d8ec29f00d362bcad87731 https://github.com/llvm/llvm-project/commit/aa70f83e660453c006193aab7ba67c94db236948 https://github.com/llvm/llvm-project/commit/547917aebd1e79a8929b53f0ddf3b5185ee4df74 https://github.com/llvm/llvm-project/pull/104523 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 9f41805 - [lldb] Pick the correct architecutre when target and core file disagree (#105576)
Author: Jonas Devlieghere
Date: 2024-08-22T08:29:48-07:00
New Revision: 9f418057dc73e4e5cb94a7cd671097275ffc29fc
URL:
https://github.com/llvm/llvm-project/commit/9f418057dc73e4e5cb94a7cd671097275ffc29fc
DIFF:
https://github.com/llvm/llvm-project/commit/9f418057dc73e4e5cb94a7cd671097275ffc29fc.diff
LOG: [lldb] Pick the correct architecutre when target and core file disagree
(#105576)
In f9f3316, Adrian fixed an issue where LLDB wouldn't update the
target's architecture when the process reported a different triple that
only differed in its sub-architecture.
This unintentionally regressed core file debugging when the core file
reports the base architecture (e.g. armv7) while the main binary knows
the correct CPU subtype (e.g. armv7em). After the aforementioned change,
we update the target architecture from armv7em to armv7. Fix the issue
by trusting the target architecture over the ProcessMachCore process.
rdar://133834304
Added:
lldb/test/Shell/Process/Inputs/a.out.yaml
lldb/test/Shell/Process/Inputs/corefile.yaml
lldb/test/Shell/Process/ProcessMachCoreArch.test
Modified:
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
Removed:
diff --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index 930c707604bb38..348b18e38560a6 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -562,17 +562,22 @@ Status ProcessMachCore::DoLoadCore() {
SetCanJIT(false);
- // The corefile's architecture is our best starting point.
- ArchSpec arch(m_core_module_sp->GetArchitecture());
- if (arch.IsValid())
-GetTarget().SetArchitecture(arch);
-
CreateMemoryRegions();
LoadBinariesAndSetDYLD();
CleanupMemoryRegionPermissions();
+ ModuleSP exe_module_sp = GetTarget().GetExecutableModule();
+ if (exe_module_sp && exe_module_sp->GetArchitecture().IsValid()) {
+GetTarget().SetArchitecture(exe_module_sp->GetArchitecture());
+ } else {
+// The corefile's architecture is our best starting point.
+ArchSpec arch(m_core_module_sp->GetArchitecture());
+if (arch.IsValid())
+ GetTarget().SetArchitecture(arch);
+ }
+
AddressableBits addressable_bits = core_objfile->GetAddressableBits();
SetAddressableBitMasks(addressable_bits);
diff --git a/lldb/test/Shell/Process/Inputs/a.out.yaml
b/lldb/test/Shell/Process/Inputs/a.out.yaml
new file mode 100644
index 00..f63457d39824c6
--- /dev/null
+++ b/lldb/test/Shell/Process/Inputs/a.out.yaml
@@ -0,0 +1,62 @@
+--- !mach-o
+FileHeader:
+ magic: 0xFEEDFACE
+ cputype: 0xC
+ cpusubtype: 0x10
+ filetype:0x2
+ ncmds: 3
+ sizeofcmds: 272
+ flags: 0x200085
+LoadCommands:
+ - cmd: LC_SEGMENT
+cmdsize: 56
+segname: __PAGEZERO
+vmaddr: 0
+vmsize: 16384
+fileoff: 0
+filesize:0
+maxprot: 0
+initprot:0
+nsects: 0
+flags: 0
+ - cmd: LC_SEGMENT
+cmdsize: 192
+segname: __TEXT
+vmaddr: 16384
+vmsize: 32768
+fileoff: 0
+filesize:32768
+maxprot: 5
+initprot:5
+nsects: 2
+flags: 0
+Sections:
+ - sectname:__text
+segname: __TEXT
+addr:0xBFB4
+size:4
+offset: 0x7FB4
+align: 1
+reloff: 0x0
+nreloc: 0
+flags: 0x8400
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content: '00207047'
+ - sectname:__unwind_info
+segname: __TEXT
+addr:0xBFB8
+size:72
+offset: 0x7FB8
+align: 2
+reloff: 0x0
+nreloc: 0
+flags: 0x0
+reserved1: 0x0
+reserved2: 0x0
+reserved3: 0x0
+content:
01001C001C001C000200B57F34003400BA7F340003000C0001001100
+ - cmd: LC_UUID
+cmdsize: 24
+uuid:C2065535-C63D-3C6A-BF79-19CF960DEF2E
diff --git a/lldb/test/Shell/Process/Inputs/corefile.yaml
b/lldb/test/Shell/Process/Inputs/corefile.yaml
new file mode 100644
index 00..537da8e85cba35
--- /dev/null
+++ b/lldb/test/Shell/Process/Inputs/corefile.yaml
@@ -0,0 +1,22 @@
+--- !mach-o
+FileHeader:
+ magic: 0xFEEDFACF
+ cputype: 0xC
+ cpusubtype: 0x9
+ filetype:0x4
+ ncmds: 1
+ s
[Lldb-commits] [lldb] [lldb] Pick the correct architecutre when target and core file disagree (PR #105576)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/105576 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Provide `declarationLocation` for variables (PR #102928)
@@ -0,0 +1,40 @@ +""" +Test lldb-dap locations request +""" + + +import dap_server +from lldbsuite.test.decorators import * +from lldbsuite.test.lldbtest import * +from lldbsuite.test import lldbutil +import lldbdap_testcase +import os + + +class TestDAP_locations(lldbdap_testcase.DAPTestCaseBase): +@skipIfWindows walter-erquinigo wrote: Oof, this is quite unfortunate. I remember that not long ago there was someone who was trying to make these tests past on window, but it seems that this effort wasn't successful. And well, yes, in order to have an easier time with buildbots, feel free to reintroduce the `SkipIfWindows` decorator in your tests. https://github.com/llvm/llvm-project/pull/102928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
walter-erquinigo wrote: @DavidSpickett I think this has been mostly an issue with the fact that no one has tried long enough to make lldb-dap work nicely on windows. But I'm sure most tests should just pass without too much effort. https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
DavidSpickett wrote: Cool, I'll try them when I've got some spare time. https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4078,6 +4255,9 @@ void RegisterRequestCallbacks() {
g_dap.RegisterRequestCallback("threads", request_threads);
g_dap.RegisterRequestCallback("variables", request_variables);
g_dap.RegisterRequestCallback("disassemble", request_disassemble);
+ // Instruction breapoint request
santhoshe447 wrote:
@vogelsgesang
Thanks for bringing this point.
The GDB remote protocol does not have a specific packet for instruction
breakpoints, which is likely why LLDB manages instruction breakpoints using the
z0 packet, just like it does for software breakpoints.
The challenge is distinguishing between instruction breakpoints and software
breakpoints when they use the same packet type.
**Instruction breakpoints packet info:**
$[{"name":"mandelbrot","reason":"breakpoint","registers":{"16":"3046","6":"10e3ff7f","7":"00e3ff7f"}],"signal":5,"tid":12342}]]#72
**Source breakpoint packet info:**
$[{"name":"mandelbrot","reason":"breakpoint","registers":{"16":"2e46","6":"10e3ff7f","7":"00e3ff7f"}],"signal":5,"tid":12342}]]#a6
It would be helpful if you could share any insights on this.
https://github.com/llvm/llvm-project/pull/105278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -0,0 +1,6 @@ +CXX_SOURCES := main-copy.cpp +CXXFLAGS_EXTRAS := -O1 -g santhoshe447 wrote: I just verified with -O1, so same has been submitted. I have changed it to "-O0" https://github.com/llvm/llvm-project/pull/105278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Skip the lldb-dap output test on windows, it seems all the lldb-dap tests are disabled on windows. (PR #105604)
walter-erquinigo wrote: > Cool, I'll try them when I've got some spare time. I'd very much appreciate it. I sometimes have time, but I don't even have access to a proper Windows machine to make that work :( https://github.com/llvm/llvm-project/pull/105604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 0926255 - [lldb] Fix typos in ScriptedInterface.h
Author: David Spickett
Date: 2024-08-22T16:15:05Z
New Revision: 09262553fa1874bec04aebb1ecd3fd3386d316d5
URL:
https://github.com/llvm/llvm-project/commit/09262553fa1874bec04aebb1ecd3fd3386d316d5
DIFF:
https://github.com/llvm/llvm-project/commit/09262553fa1874bec04aebb1ecd3fd3386d316d5.diff
LOG: [lldb] Fix typos in ScriptedInterface.h
Added:
Modified:
lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
Removed:
diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
index 3ce47d0584a8a7..3850edf879ac45 100644
--- a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
@@ -36,8 +36,8 @@ class ScriptedInterface {
template
static Ret ErrorWithMessage(llvm::StringRef caller_name,
llvm::StringRef error_msg, Status &error,
- LLDBLog log_caterogy = LLDBLog::Process) {
-LLDB_LOGF(GetLog(log_caterogy), "%s ERROR = %s", caller_name.data(),
+ LLDBLog log_category = LLDBLog::Process) {
+LLDB_LOGF(GetLog(log_category), "%s ERROR = %s", caller_name.data(),
error_msg.data());
std::string full_error_message =
llvm::Twine(caller_name + llvm::Twine(" ERROR = ") +
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Add frame recognizers for libc++ `std::invoke` (PR #105695)
https://github.com/vogelsgesang created
https://github.com/llvm/llvm-project/pull/105695
With this commit, we also hide the implementation details of `std::invoke`. To
do so, the `LibCXXFrameRecognizer` got a couple more regular expressions.
The regular expression passed into the `AddRecognizer` became problematic, as
it was evaluated on the demangled name. Those names also included result types
for C++ symbols. For `std::__invoke` the return type is a huge `decltype(...)`,
making the regular expresison really hard to write.
Instead, I added support for `AddRecognizer` to match on the demangled names
without result type and argument types.
By hiding the implementation details of `invoke`, also the back traces for
`std::function` become even nicer, because `std::function` is using `__invoke`
internally.
>From 18365311d0cee76bced3ba26d1ed08d9f5c6cb28 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Thu, 22 Aug 2024 10:50:13 +
Subject: [PATCH] [lldb-dap] Add frame recognizers for libc++ `std::invoke`
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.
The regular expression passed into the `AddRecognizer` became
problematic, as it was evaluated on the demangled name. Those names also
included result types for C++ symbols. For `std::__invoke` the return
type is a huge `decltype(...)`, making the regular expresison really
hard to write.
Instead, I added support for `AddRecognizer` to match on the demangled
names without result type and argument types.
By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.
---
.../lldb/Target/StackFrameRecognizer.h| 9 +++-
lldb/source/Commands/Options.td | 2 +-
.../CPlusPlus/CPPLanguageRuntime.cpp | 48 ++-
lldb/source/Target/StackFrameRecognizer.cpp | 41 ++--
.../TestStdFunctionRecognizer.py | 21 +++-
.../lang/cpp/std-invoke-recognizer/Makefile | 5 ++
.../TestStdInvokeRecognizer.py| 28 +++
.../lang/cpp/std-invoke-recognizer/main.cpp | 40
8 files changed, 173 insertions(+), 21 deletions(-)
create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/Makefile
create mode 100644
lldb/test/API/lang/cpp/std-invoke-recognizer/TestStdInvokeRecognizer.py
create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/main.cpp
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 8acebc12c4b1dc..585f0b0bb59009 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -107,12 +107,14 @@ class StackFrameRecognizerManager {
public:
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
ConstString module, llvm::ArrayRef symbols,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
lldb::RegularExpressionSP module,
lldb::RegularExpressionSP symbol,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
@@ -143,10 +145,13 @@ class StackFrameRecognizerManager {
std::vector symbols;
lldb::RegularExpressionSP symbol_regexp;
bool first_instruction_only;
+Mangled::NamePreference mangling_preference;
};
std::deque m_recognizers;
uint16_t m_generation;
+ std::unordered_set m_used_manglings;
+
};
/// \class ValueObjectRecognizerSynthesizedValue
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 9c4dbed6939ba9..df906e9d7c808f 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1049,7 +1049,7 @@ let Command = "thread backtrace" in {
def thread_backtrace_extended : Option<"extended", "e">, Group<1>,
Arg<"Boolean">, Desc<"Show the extended backtrace, if available">;
def thread_backtrace_unfiltered : Option<"unfiltered", "u">, Group<1>,
- Desc<"Filter out frames according to installed frame recognizers">;
+ Desc<"Do not filter out frames according to installed frame recognizers">;
}
let Command = "thread step scope" in {
diff --git
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index c60200ab186d09..3665e1a4c77e55 100644
--- a/lldb/sourc
[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/105695 ___ 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 recognizers for libc++ `std::invoke` (PR #105695)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Vogelsgesang (vogelsgesang)
Changes
With this commit, we also hide the implementation details of `std::invoke`. To
do so, the `LibCXXFrameRecognizer` got a couple more regular expressions.
The regular expression passed into the `AddRecognizer` became problematic, as
it was evaluated on the demangled name. Those names also included result types
for C++ symbols. For `std::__invoke` the return type is a huge `decltype(...)`,
making the regular expresison really hard to write.
Instead, I added support for `AddRecognizer` to match on the demangled names
without result type and argument types.
By hiding the implementation details of `invoke`, also the back traces for
`std::function` become even nicer, because `std::function` is using `__invoke`
internally.
---
Full diff: https://github.com/llvm/llvm-project/pull/105695.diff
8 Files Affected:
- (modified) lldb/include/lldb/Target/StackFrameRecognizer.h (+7-2)
- (modified) lldb/source/Commands/Options.td (+1-1)
- (modified)
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp (+36-12)
- (modified) lldb/source/Target/StackFrameRecognizer.cpp (+37-4)
- (modified)
lldb/test/API/lang/cpp/std-function-recognizer/TestStdFunctionRecognizer.py
(+19-2)
- (added) lldb/test/API/lang/cpp/std-invoke-recognizer/Makefile (+5)
- (added)
lldb/test/API/lang/cpp/std-invoke-recognizer/TestStdInvokeRecognizer.py (+28)
- (added) lldb/test/API/lang/cpp/std-invoke-recognizer/main.cpp (+40)
``diff
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 8acebc12c4b1dc..585f0b0bb59009 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -107,12 +107,14 @@ class StackFrameRecognizerManager {
public:
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
ConstString module, llvm::ArrayRef symbols,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
lldb::RegularExpressionSP module,
lldb::RegularExpressionSP symbol,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
@@ -143,10 +145,13 @@ class StackFrameRecognizerManager {
std::vector symbols;
lldb::RegularExpressionSP symbol_regexp;
bool first_instruction_only;
+Mangled::NamePreference mangling_preference;
};
std::deque m_recognizers;
uint16_t m_generation;
+ std::unordered_set m_used_manglings;
+
};
/// \class ValueObjectRecognizerSynthesizedValue
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 9c4dbed6939ba9..df906e9d7c808f 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1049,7 +1049,7 @@ let Command = "thread backtrace" in {
def thread_backtrace_extended : Option<"extended", "e">, Group<1>,
Arg<"Boolean">, Desc<"Show the extended backtrace, if available">;
def thread_backtrace_unfiltered : Option<"unfiltered", "u">, Group<1>,
- Desc<"Filter out frames according to installed frame recognizers">;
+ Desc<"Do not filter out frames according to installed frame recognizers">;
}
let Command = "thread step scope" in {
diff --git
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index c60200ab186d09..3665e1a4c77e55 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -7,6 +7,7 @@
//===--===//
#include
+#include
#include
@@ -44,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
/// A frame recognizer that is installed to hide libc++ implementation
/// details from the backtrace.
class LibCXXFrameRecognizer : public StackFrameRecognizer {
- RegularExpression m_hidden_function_regex;
+ std::array m_hidden_regex;
RecognizedStackFrameSP m_hidden_frame;
struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
public:
LibCXXFrameRecognizer()
- : m_hidden_function_regex(
-R"(^std::__1::(__function.*::operator\(\)|__invoke))"
-R"((\[.*\])?)"// ABI tag.
-R"(( const)?$)"), // const.
+ : m_hidden_regex{
+// i
[Lldb-commits] [lldb] c1e401f - [lldb] Change the two remaining SInt64 settings in Target to uint (#105460)
Author: Jason Molenda
Date: 2024-08-22T10:10:15-07:00
New Revision: c1e401f3624780f85f4c9a26960752ee3f37fafb
URL:
https://github.com/llvm/llvm-project/commit/c1e401f3624780f85f4c9a26960752ee3f37fafb
DIFF:
https://github.com/llvm/llvm-project/commit/c1e401f3624780f85f4c9a26960752ee3f37fafb.diff
LOG: [lldb] Change the two remaining SInt64 settings in Target to uint (#105460)
TargetProperties.td had a few settings listed as signed integral values,
but the Target.cpp methods reading those values were reading them as
unsigned. e.g. target.max-memory-read-size, some accesses of
target.max-children-count, still today, previously
target.max-string-summary-length.
After Jonas' change to use templates to read these values in
https://reviews.llvm.org/D149774, when the code tried to fetch these
values, we'd eventually end up calling OptionValue::GetAsUInt64 which
checks that the value is actually a UInt64 before returning it; finding
that it was an SInt64, it would drop the user setting and return the
default value. This manifested as a bug that target.max-memory-read-size
is never used for memory read.
target.max-children-count is less straightforward, where one read of
that setting was fetching it as an int64_t, the other as a uint64_t.
I suspect all of these settings were originally marked as SInt64 so a
user could do -1 for "infinite", getting it static_cast to a UINT64_MAX
value along the way. I can't find any documentation for this behavior,
but it seems like something Greg would have done. We've partially lost
that behavior already via
https://github.com/llvm/llvm-project/pull/72233 for
target.max-string-summary-length, and this further removes it.
We're still fetching UInt64's and returning them as uint32_t's but I'm
not overly pressed about someone setting a count/size limit over 4GB.
I added a simple API test for the memory read setting limit.
Added:
lldb/test/API/functionalities/memory/big-read/Makefile
lldb/test/API/functionalities/memory/big-read/TestMemoryReadMaximumSize.py
lldb/test/API/functionalities/memory/big-read/main.c
Modified:
lldb/source/Target/Target.cpp
lldb/source/Target/TargetProperties.td
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/forward_list/TestDataFormatterGenericForwardList.py
Removed:
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 5a5d689e03fbc0..260974bddedf3a 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4609,7 +4609,7 @@ uint32_t
TargetProperties::GetMaxZeroPaddingInFloatFormat() const {
uint32_t TargetProperties::GetMaximumNumberOfChildrenToDisplay() const {
const uint32_t idx = ePropertyMaxChildrenCount;
- return GetPropertyAtIndexAs(
+ return GetPropertyAtIndexAs(
idx, g_target_properties[idx].default_uint_value);
}
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index 421252aa4aea26..7bb5bd53688b14 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -92,7 +92,7 @@ let Definition = "target" in {
def MaxZeroPaddingInFloatFormat:
Property<"max-zero-padding-in-float-format", "UInt64">,
DefaultUnsignedValue<6>,
Desc<"The maximum number of zeroes to insert when displaying a very small
float before falling back to scientific notation.">;
- def MaxChildrenCount: Property<"max-children-count", "SInt64">,
+ def MaxChildrenCount: Property<"max-children-count", "UInt64">,
DefaultUnsignedValue<256>,
Desc<"Maximum number of children to expand in any level of depth.">;
def MaxChildrenDepth: Property<"max-children-depth", "UInt64">,
@@ -101,7 +101,7 @@ let Definition = "target" in {
def MaxSummaryLength: Property<"max-string-summary-length", "UInt64">,
DefaultUnsignedValue<1024>,
Desc<"Maximum number of characters to show when using %s in summary
strings.">;
- def MaxMemReadSize: Property<"max-memory-read-size", "SInt64">,
+ def MaxMemReadSize: Property<"max-memory-read-size", "UInt64">,
DefaultUnsignedValue<1024>,
Desc<"Maximum number of bytes that 'memory read' will fetch before --force
must be specified.">;
def BreakpointUseAvoidList: Property<"breakpoints-use-platform-avoid-list",
"Boolean">,
diff --git
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/forward_list/TestDataFormatterGenericForwardList.py
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/forward_list/TestDataFormatterGenericForwardList.py
index 072a580afe24e4..185a24cf6dce30 100644
---
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/forward_list/TestDataFormatterGenericForwardList.py
+++
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/forward_list/TestDataFormatterGenericForwardList.py
@@ -2,7 +2,6 @@
Test lldb data fo
[Lldb-commits] [lldb] [lldb] Change the two remaining SInt64 settings in Target to uint (PR #105460)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/105460 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4078,6 +4255,9 @@ void RegisterRequestCallbacks() {
g_dap.RegisterRequestCallback("threads", request_threads);
g_dap.RegisterRequestCallback("variables", request_variables);
g_dap.RegisterRequestCallback("disassemble", request_disassemble);
+ // Instruction breapoint request
vogelsgesang wrote:
I don't really know about those differences on the gdb protocol. I was only
reading
https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetInstructionBreakpoints
> When an instruction breakpoint is hit, a stopped event (with reason
> `instruction breakpoint`) is generated.
https://github.com/llvm/llvm-project/pull/105278
___
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 recognizers for libc++ `std::invoke` (PR #105695)
vogelsgesang wrote: @mordante @ldionne FYI. Would be interested which other functions come to mind that should be hidden. See https://github.com/llvm/llvm-project/pull/105457#issuecomment-226404 for screenshots of how this looks from a user's perspective https://github.com/llvm/llvm-project/pull/105695 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -45,7 +45,6 @@ class LLDB_API SBMemoryRegionInfoList {
private:
friend class SBProcess;
-
clayborg wrote:
revert whitespace only change
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -1222,6 +1222,7 @@ enum SaveCoreStyle {
eSaveCoreFull = 1,
eSaveCoreDirtyOnly = 2,
eSaveCoreStackOnly = 3,
+ eSaveCoreCustom = 4,
clayborg wrote:
Should we name this `eSaveCoreCustomOnly`? We should add some header doc for
each of these above ones as well explaining what will be done and how they
interact with any custom ranges that are specified.
```
/// Save all memory ranges that are readable to the core file. If
/// custom memory ranges are specified, they will be ingored.
eSaveCoreFull = 1,
/// If the platform supports detecting dirty pages within read/write
/// regions, save only the modified pages. If the platform doesn't
/// support detecting dirty pages, then save all regions with read +
/// write permissions. If custom memory ranges are specified, they
/// will be merged into the regions that get saved.
eSaveCoreDirtyOnly = 2,
/// Save the stacks for all threads. Minimal stacks will be saved
/// where only the SP to the top of the stack will be saved taking
/// into account the red zone. If custom memory ranges are specified,
/// they will be merged into the regions that get saved.
eSaveCoreStackOnly = 3,
/// Save only the custom regions that are specified.
eSaveCoreCustom = 4,
```
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -6686,9 +6710,12 @@ Status Process::CalculateCoreFileSaveRanges(const
SaveCoreOptions &options,
if (err.Fail())
return err;
- if (ranges.empty())
+ if (ranges.IsEmpty())
return Status("no valid address ranges found for core style");
+ // Sort the range data vector to dedupe ranges before returning.
+ ranges.Sort();
clayborg wrote:
This is where we should go over the ranges and break them up by permissions.
Also if we wanted to support the user specifying large ranges that contain many
regions, then we would break them up here as well.
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -101,6 +103,18 @@ bool SaveCoreOptions::ShouldThreadBeSaved(lldb::tid_t tid)
const {
return m_threads_to_save.count(tid) > 0;
}
+bool SaveCoreOptions::HasSpecifiedThreads() const {
+ return !m_threads_to_save.empty();
+}
+
+void SaveCoreOptions::AddMemoryRegionToSave(const
lldb_private::MemoryRegionInfo ®ion) {
+ m_regions_to_save.Insert(region.GetRange(), /*combine=*/true);
clayborg wrote:
Does this keep things sorted and merge ranges? Or do we post process these
ranges somewhere? At some point we will need to iterate over the ranges to save
and break them up according to permissions.
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -80,6 +80,17 @@ class LLDB_API SBSaveCoreOptions {
/// \return True if the thread was removed, false if it was not in the list.
bool RemoveThread(lldb::SBThread thread);
+ /// Add a memory region to save in the core file.
+ ///
+ /// \param region The memory region to save.
+ /// \returns An empty SBError upon success, or an error if the region is
+ /// invalid.
+ /// \note Ranges that overlapped with be unioned into a single region this
clayborg wrote:
"Ranges that overlap will be unioned into a single region, this also supercedes
stack minification."
Some other things we could do with this patch:
- if a region crosses a permission boundary, then break it up so we can safe
off memory with the right permissions. So if we have [0x1000-0x2000) with "rw"
permissions and [0x2000-0x3000) with "r" permissions, and the user asks for
[0x1000-0x3000) to be saved, we should probably break it up and save them
separately.
- Allow the user to ask for a huge range and break it up into any regions that
fit, like ask for `[0x1-0x)` and we would save all
regions in that range, separated out by permission boundaries
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -6544,7 +6545,8 @@ static void AddRegion(const MemoryRegionInfo ®ion, bool try_dirty_pages, return; if (try_dirty_pages && AddDirtyPages(region, ranges)) return; - ranges.push_back(CreateCoreFileMemoryRange(region)); + + ranges.Append(region.GetRange().GetRangeBase(), region.GetRange().GetByteSize(), CreateCoreFileMemoryRange(region)); clayborg wrote: format, line too long? https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -101,6 +103,18 @@ bool SaveCoreOptions::ShouldThreadBeSaved(lldb::tid_t tid)
const {
return m_threads_to_save.count(tid) > 0;
}
+bool SaveCoreOptions::HasSpecifiedThreads() const {
+ return !m_threads_to_save.empty();
+}
+
+void SaveCoreOptions::AddMemoryRegionToSave(const
lldb_private::MemoryRegionInfo ®ion) {
+ m_regions_to_save.Insert(region.GetRange(), /*combine=*/true);
+}
+
+const MemoryRanges &SaveCoreOptions::GetCoreFileMemoryRanges() const {
clayborg wrote:
Do we want a `SaveCoreOptions::FinalizeMemoryRanges()` method to break the
ranges up by permission boundaries?
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
https://github.com/Da-Viper updated
https://github.com/llvm/llvm-project/pull/104711
>From 2cda519a06d46bd6a5ae02e8be8daacb39a49b3e Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Thu, 22 Aug 2024 01:42:17 +0100
Subject: [PATCH 1/2] Rebase and add check dap path on config change
---
.../lldb-dap/src-ts/debug-adapter-factory.ts | 42 ++
lldb/tools/lldb-dap/src-ts/extension.ts | 43 ++-
2 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
index 01c671f41ff782..8a8f441581b29e 100644
--- a/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
+++ b/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts
@@ -14,10 +14,52 @@ export class LLDBDapDescriptorFactory
this.lldbDapOptions = lldbDapOptions;
}
+ public static async validateDebugAdapterPath(pathUri: vscode.Uri) {
+try {
+ const fileStats = await vscode.workspace.fs.stat(pathUri);
+ if (!(fileStats.type & vscode.FileType.File)) {
+this.showErrorMessage(pathUri.path);
+ }
+} catch (err) {
+ this.showErrorMessage(pathUri.path);
+}
+ }
+
async createDebugAdapterDescriptor(
session: vscode.DebugSession,
executable: vscode.DebugAdapterExecutable | undefined,
): Promise {
+const config = vscode.workspace.getConfiguration(
+ "lldb-dap",
+ session.workspaceFolder,
+);
+const customPath = config.get("executable-path");
+const path: string = customPath ? customPath : executable!!.command;
+
+await LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(path),
+);
return this.lldbDapOptions.createDapExecutableCommand(session, executable);
}
+
+ /**
+ * Shows a message box when the debug adapter's path is not found
+ */
+ private static showErrorMessage(path: string) {
+const openSettingsAction = "Open Settings";
+vscode.window
+ .showErrorMessage(
+`Debug adapter path: ${path} is not a valid file`,
+{ modal: false },
+openSettingsAction,
+ )
+ .then((callBackValue) => {
+if (openSettingsAction === callBackValue) {
+ vscode.commands.executeCommand(
+"workbench.action.openSettings",
+"lldb-dap.executable-path",
+ );
+}
+ });
+ }
}
diff --git a/lldb/tools/lldb-dap/src-ts/extension.ts
b/lldb/tools/lldb-dap/src-ts/extension.ts
index 7df09f7a29dad7..12565a8fbe9a0a 100644
--- a/lldb/tools/lldb-dap/src-ts/extension.ts
+++ b/lldb/tools/lldb-dap/src-ts/extension.ts
@@ -14,26 +14,32 @@ function createDefaultLLDBDapOptions(): LLDBDapOptions {
session: vscode.DebugSession,
packageJSONExecutable: vscode.DebugAdapterExecutable | undefined,
): Promise {
- const config = vscode.workspace
-.getConfiguration("lldb-dap", session.workspaceFolder);
+ const config = vscode.workspace.getConfiguration(
+"lldb-dap",
+session.workspaceFolder,
+ );
const path = config.get("executable-path");
const log_path = config.get("log-path");
- let env : { [key: string]: string } = {};
+ let env: { [key: string]: string } = {};
if (log_path) {
env["LLDBDAP_LOG"] = log_path;
}
if (path) {
-return new vscode.DebugAdapterExecutable(path, [], {env});
+return new vscode.DebugAdapterExecutable(path, [], { env });
} else if (packageJSONExecutable) {
-return new
vscode.DebugAdapterExecutable(packageJSONExecutable.command,
packageJSONExecutable.args, {
- ...packageJSONExecutable.options,
- env: {
-...packageJSONExecutable.options?.env,
-...env
- }
-});
+return new vscode.DebugAdapterExecutable(
+ packageJSONExecutable.command,
+ packageJSONExecutable.args,
+ {
+...packageJSONExecutable.options,
+env: {
+ ...packageJSONExecutable.options?.env,
+ ...env,
+},
+ },
+);
} else {
return undefined;
}
@@ -58,6 +64,21 @@ export class LLDBDapExtension extends DisposableContext {
new LLDBDapDescriptorFactory(this.lldbDapOptions),
),
);
+
+this.pushSubscription(
+ vscode.workspace.onDidChangeConfiguration((event) => {
+if (event.affectsConfiguration("lldb-dap.executable-path")) {
+ const dapPath = vscode.workspace
+.getConfiguration("lldb-dap")
+.get("executable-path");
+ if (dapPath) {
+LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(dapPath),
+);
+ }
+}
+ }),
+);
}
}
>From 443c71a4af2fa03eb911deb9b086a2e7e6f1daf1 Mon Sep 17 00:00:00 2001
From: Ezike Ebuka
Date: Thu, 22 Aug 2024 18:54:03 +0100
Subject: [PATCH 2/2] Resol
[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)
https://github.com/vogelsgesang updated
https://github.com/llvm/llvm-project/pull/105695
>From c7cc7e9eed1ef4b95cabec5f662ebe10607b178e Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang
Date: Thu, 22 Aug 2024 10:50:13 +
Subject: [PATCH] [lldb-dap] Add frame recognizers for libc++ `std::invoke`
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.
The regular expression passed into the `AddRecognizer` became
problematic, as it was evaluated on the demangled name. Those names also
included result types for C++ symbols. For `std::__invoke` the return
type is a huge `decltype(...)`, making the regular expresison really
hard to write.
Instead, I added support for `AddRecognizer` to match on the demangled
names without result type and argument types.
By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.
---
.../lldb/Target/StackFrameRecognizer.h| 9 +++-
lldb/source/Commands/Options.td | 2 +-
.../CPlusPlus/CPPLanguageRuntime.cpp | 48 ++-
lldb/source/Target/StackFrameRecognizer.cpp | 41 ++--
.../TestStdFunctionRecognizer.py | 21 +++-
.../lang/cpp/std-invoke-recognizer/Makefile | 5 ++
.../TestStdInvokeRecognizer.py| 31
.../lang/cpp/std-invoke-recognizer/main.cpp | 40
8 files changed, 176 insertions(+), 21 deletions(-)
create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/Makefile
create mode 100644
lldb/test/API/lang/cpp/std-invoke-recognizer/TestStdInvokeRecognizer.py
create mode 100644 lldb/test/API/lang/cpp/std-invoke-recognizer/main.cpp
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 8acebc12c4b1dc..585f0b0bb59009 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -107,12 +107,14 @@ class StackFrameRecognizerManager {
public:
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
ConstString module, llvm::ArrayRef symbols,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
lldb::RegularExpressionSP module,
lldb::RegularExpressionSP symbol,
- bool first_instruction_only = true);
+ bool first_instruction_only = true,
+ Mangled::NamePreference mangling_preference =
Mangled::ePreferDemangled);
void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
@@ -143,10 +145,13 @@ class StackFrameRecognizerManager {
std::vector symbols;
lldb::RegularExpressionSP symbol_regexp;
bool first_instruction_only;
+Mangled::NamePreference mangling_preference;
};
std::deque m_recognizers;
uint16_t m_generation;
+ std::unordered_set m_used_manglings;
+
};
/// \class ValueObjectRecognizerSynthesizedValue
diff --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index 9c4dbed6939ba9..df906e9d7c808f 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -1049,7 +1049,7 @@ let Command = "thread backtrace" in {
def thread_backtrace_extended : Option<"extended", "e">, Group<1>,
Arg<"Boolean">, Desc<"Show the extended backtrace, if available">;
def thread_backtrace_unfiltered : Option<"unfiltered", "u">, Group<1>,
- Desc<"Filter out frames according to installed frame recognizers">;
+ Desc<"Do not filter out frames according to installed frame recognizers">;
}
let Command = "thread step scope" in {
diff --git
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
index c60200ab186d09..3665e1a4c77e55 100644
--- a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
+++ b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
@@ -7,6 +7,7 @@
//===--===//
#include
+#include
#include
@@ -44,7 +45,7 @@ char CPPLanguageRuntime::ID = 0;
/// A frame recognizer that is installed to hide libc++ implementation
/// details from the backtrace.
class LibCXXFrameRecognizer : public StackFrameRecognizer {
- RegularExpression m_hidden_function_regex;
+ std::array m_hidden_regex;
RecognizedStackFrameSP m_hidden_frame;
struct LibCXXHiddenFrame : public RecognizedStackFrame {
@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public StackFram
[Lldb-commits] [lldb] e5140ae - Fix dap stacktrace perf issue (#104874)
Author: jeffreytan81
Date: 2024-08-22T11:30:34-07:00
New Revision: e5140aed275fe60b83188143f39011d5c0ee5bb0
URL:
https://github.com/llvm/llvm-project/commit/e5140aed275fe60b83188143f39011d5c0ee5bb0
DIFF:
https://github.com/llvm/llvm-project/commit/e5140aed275fe60b83188143f39011d5c0ee5bb0.diff
LOG: Fix dap stacktrace perf issue (#104874)
We have got several customer reporting of slow stepping over the past
year in VSCode.
Profiling shows the slow stepping is caused by `stackTrace` request
which can take around 1 second for certain targets. Since VSCode sends
`stackTrace` during each stop event, the slow `stackTrace` request would
slow down stepping in VSCode. Below is the hot path:
```
|--68.75%--lldb_dap::DAP::HandleObject(llvm::json::Object const&)
| |
| |--57.70%--(anonymous
namespace)::request_stackTrace(llvm::json::Object const&)
| | |
| |
|--54.43%--lldb::SBThread::GetCurrentExceptionBacktrace()
| | |
lldb_private::Thread::GetCurrentExceptionBacktrace()
| | |
lldb_private::Thread::GetCurrentException()
| | |
lldb_private::ItaniumABILanguageRuntime::GetExceptionObjectForThread(std::shared_ptr)
| | | |
| | |
|--53.43%--lldb_private::FunctionCaller::ExecuteFunction(lldb_private::ExecutionContext&,
unsigned long*, lldb_private::EvaluateExpressionOptions const&,
lldb_private::DiagnosticManager&, lldb_private::Value&)
| | | | |
| | | |
|--25.23%--lldb_private::FunctionCaller::InsertFunction(lldb_private::ExecutionContext&,
unsigned long&, lldb_private::DiagnosticManager&)
| | | | | |
| | | | |
|--24.56%--lldb_private::FunctionCaller::WriteFunctionWrapper(lldb_private::ExecutionContext&,
lldb_private::DiagnosticManager&)
| | | | | |
|
| | | | | |
|--19.73%--lldb_private::ExpressionParser::PrepareForExecution(unsigned long&,
unsigned long&, std::shared_ptr&,
lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
| | | | | |
| lldb_private::ClangExpressionParser::DoPrepareForExecution(unsigned
long&, unsigned long&, std::shared_ptr&,
lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
| | | | | |
|
lldb_private::IRExecutionUnit::GetRunnableInfo(lldb_private::Status&, unsigned
long&, unsigned long&)
| | | | | |
| |
```
The hot path is added by https://reviews.llvm.org/D156465 which should
at least be disabled for Linux. Note: I am seeing similar performance
hot path on Mac.
This PR hides the feature behind `enableDisplayExtendedBacktrace` option
which needs to be enabled on-demand.
-
Co-authored-by: jeffreytan81
Added:
Modified:
lldb/tools/lldb-dap/DAP.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/lldb-dap.cpp
Removed:
diff --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 1fd560f21904ab..57b93c28ce9301 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -36,6 +36,7 @@ DAP::DAP()
focus_tid(LLDB_INVALID_THREAD_ID), stop_at_entry(false),
is_attach(false),
enable_auto_variable_summaries(false),
enable_synthetic_child_debugging(false),
+ enable_display_extended_backtrace(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done_sent(false), waiting_for_run_in_terminal(false),
progress_event_reporter(
diff --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index 27ea6c7ff8423f..0fc77ac1e81683 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -181,6 +181,7 @@ struct DAP {
bool is_attach;
bool enable_auto_variable_summaries;
bool enable_synthetic_child_debugging;
+ bool enable_display_extended_backtrace;
// The process event thread normally responds to process exited events by
// shutting down the entire adapter. When we're restarting, we keep the id of
// the old process here so we can detect this case and keep running.
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp
b/lldb/tools/lldb-dap/lldb-dap.cpp
index 7b83767d1afeab..495ed0256120e8 100644
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
https://github.com/jeffreytan81 closed https://github.com/llvm/llvm-project/pull/104874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: [lldb]: add missing if for smaller linux version (PR #105715)
https://github.com/root-kidik created https://github.com/llvm/llvm-project/pull/105715 None >From 719a9c76f8852ed4e493e7376b9959bfef8b4b5f Mon Sep 17 00:00:00 2001 From: Nikita Date: Fri, 23 Aug 2024 01:37:57 +0700 Subject: [PATCH] fix: [lldb]: add missing if for smaller linux version --- lldb/source/Plugins/Process/Linux/Perf.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lldb/source/Plugins/Process/Linux/Perf.cpp b/lldb/source/Plugins/Process/Linux/Perf.cpp index 097c719b9c1d25..8135d092cfdd68 100644 --- a/lldb/source/Plugins/Process/Linux/Perf.cpp +++ b/lldb/source/Plugins/Process/Linux/Perf.cpp @@ -342,7 +342,9 @@ lldb_private::process_linux::CreateContextSwitchTracePerfEvent( attr.size = sizeof(attr); attr.sample_type = PERF_SAMPLE_TID | PERF_SAMPLE_TIME; attr.type = PERF_TYPE_SOFTWARE; +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 3, 0) attr.context_switch = 1; +#endif attr.exclude_kernel = 1; attr.sample_id_all = 1; attr.exclude_hv = 1; ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: [lldb]: add missing if for smaller linux version (PR #105715)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: [lldb]: add missing if for smaller linux version (PR #105715)
https://github.com/root-kidik edited https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: [lldb]: add missing if for smaller linux version (PR #105715)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Nikita (root-kidik) Changes Close: #105705 --- Full diff: https://github.com/llvm/llvm-project/pull/105715.diff 1 Files Affected: - (modified) lldb/source/Plugins/Process/Linux/Perf.cpp (+2) ``diff diff --git a/lldb/source/Plugins/Process/Linux/Perf.cpp b/lldb/source/Plugins/Process/Linux/Perf.cpp index 097c719b9c1d25..8135d092cfdd68 100644 --- a/lldb/source/Plugins/Process/Linux/Perf.cpp +++ b/lldb/source/Plugins/Process/Linux/Perf.cpp @@ -342,7 +342,9 @@ lldb_private::process_linux::CreateContextSwitchTracePerfEvent( attr.size = sizeof(attr); attr.sample_type = PERF_SAMPLE_TID | PERF_SAMPLE_TIME; attr.type = PERF_TYPE_SOFTWARE; +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 3, 0) attr.context_switch = 1; +#endif attr.exclude_kernel = 1; attr.sample_id_all = 1; attr.exclude_hv = 1; `` https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] fix: [lldb]: add missing if for smaller linux version (PR #105715)
https://github.com/JDevlieghere commented: The change itself looks fine, but can you please update the PR description with a meaningful message, preferably with a reference that shows that this was added in 4.3? https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Conditionalize context_switch attribute based on kernel version (PR #105715)
https://github.com/JDevlieghere edited https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4078,6 +4255,9 @@ void RegisterRequestCallbacks() {
g_dap.RegisterRequestCallback("threads", request_threads);
g_dap.RegisterRequestCallback("variables", request_variables);
g_dap.RegisterRequestCallback("disassemble", request_disassemble);
+ // Instruction breapoint request
walter-erquinigo wrote:
you could make something synthetic, and that could be very nice.
In the process event loop in lldb-dap, you could check if you stopped because
of a breakpoint, and then you check if the breakpoint is an instruction
breakpoint, and then you return that custom stop reason.
lldb-dap already does something like that in `CreateThreadStopped` for
exception breakpoints.
https://github.com/llvm/llvm-project/pull/105278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
https://github.com/walter-erquinigo edited https://github.com/llvm/llvm-project/pull/105278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
https://github.com/vogelsgesang approved this pull request. https://github.com/llvm/llvm-project/pull/104711 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
@@ -14,10 +14,49 @@ export class LLDBDapDescriptorFactory
this.lldbDapOptions = lldbDapOptions;
}
+ public static async validateDebugAdapterPath(pathUri: vscode.Uri) {
+try {
+ const fileStats = await vscode.workspace.fs.stat(pathUri);
+ if (!(fileStats.type & vscode.FileType.File)) {
+this.showLLDBDapNotFoundMessage(pathUri.path);
+ }
+} catch (err) {
+ this.showLLDBDapNotFoundMessage(pathUri.path);
+}
+ }
+
async createDebugAdapterDescriptor(
session: vscode.DebugSession,
executable: vscode.DebugAdapterExecutable | undefined,
): Promise {
+const config = vscode.workspace.getConfiguration(
+ "lldb-dap",
+ session.workspaceFolder,
+);
+const customPath = config.get("executable-path");
+const path: string = customPath ? customPath : executable!!.command;
walter-erquinigo wrote:
```suggestion
const path: string = customPath || executable!!.command;
```
https://github.com/llvm/llvm-project/pull/104711
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
@@ -14,10 +14,49 @@ export class LLDBDapDescriptorFactory
this.lldbDapOptions = lldbDapOptions;
}
+ public static async validateDebugAdapterPath(pathUri: vscode.Uri) {
+try {
+ const fileStats = await vscode.workspace.fs.stat(pathUri);
+ if (!(fileStats.type & vscode.FileType.File)) {
+this.showLLDBDapNotFoundMessage(pathUri.path);
+ }
+} catch (err) {
+ this.showLLDBDapNotFoundMessage(pathUri.path);
+}
+ }
+
async createDebugAdapterDescriptor(
session: vscode.DebugSession,
executable: vscode.DebugAdapterExecutable | undefined,
): Promise {
+const config = vscode.workspace.getConfiguration(
+ "lldb-dap",
+ session.workspaceFolder,
+);
+const customPath = config.get("executable-path");
+const path: string = customPath ? customPath : executable!!.command;
+
+await LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(path),
+);
return this.lldbDapOptions.createDapExecutableCommand(session, executable);
walter-erquinigo wrote:
What if `validateDebugAdapterPath` returns a boolean, and then, in the case of
success, you return `createDapExecutableCommand`, and otherwise you throw an
exception?
I have the impression that that would be managed better by the IDE, otherwise
you could be launching a session with a missing binary
https://github.com/llvm/llvm-project/pull/104711
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
@@ -58,6 +64,21 @@ export class LLDBDapExtension extends DisposableContext {
new LLDBDapDescriptorFactory(this.lldbDapOptions),
),
);
+
+this.pushSubscription(
+ vscode.workspace.onDidChangeConfiguration((event) => {
+if (event.affectsConfiguration("lldb-dap.executable-path")) {
+ const dapPath = vscode.workspace
+.getConfiguration("lldb-dap")
+.get("executable-path");
+ if (dapPath) {
+LLDBDapDescriptorFactory.validateDebugAdapterPath(
+ vscode.Uri.file(dapPath),
+);
+ }
+}
+ }),
+);
walter-erquinigo wrote:
I like this!
https://github.com/llvm/llvm-project/pull/104711
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] show dialog when executable is not found (PR #104711)
vogelsgesang wrote: Looks good to me! Thanks again for fixing this! https://github.com/llvm/llvm-project/pull/104711 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][test] Support remote run of Shell tests (PR #95986)
dzhidzhoev wrote: > That bug shows we're not able to create a test for a very simple thing (an > unaligned stack pointer) that works reliably for everyone. Honestly, based on https://github.com/llvm/llvm-project/issues/101710#issuecomment-2291180977, I'd say that the mentioned test has a problem of too many redundant dependencies, rather than that it shows the backside of tests universality. > In the end, that also reduces test coverage, because people will start to > (even proactively) add REQUIRES: my-system to their tests to avoid breaking > other people's CI. LLDB tests will still somehow depend on at least three targets in the foreseeable future (Linux/Windows/Darwin). If a test fails or is not supported on Linux target, it's unlikely that it will work on Linux target with remote debugging. So I don't see a perspective of having test coverage reduced because of `UNSUPPORTED: remote-` annotations if they appear. > This is important as it slows down the velocity of all developers (old and > new). I see a situation of a development velocity slowdown if a test the developer wrote is not supposed to work for remote debugging, but is missing a proper annotation for that. For other cases, remote debugging support is claimed as an LLDB feature. If tests are written/executed using the LLDB command line, remote execution shouldn't hinder their execution. BTW, most of the cases where tests should've been disabled for remote debugging were the cases where platform mismatch happened. Tests were already disabled for "system-windows", but they were attempted to be run against Linux target. Probably, "system-X" semantics should be redefined to indicate a target platform instead of a host platform, or a feature like "target-system-xxx" should be introduced to show that a test should be run on a Windows/Darwin target regardless of the host. I think this will eliminate the need for `UNSUPPORTED: remote-` annotations for most of the cases. Considering the complexity of setting up a remote debugging environment, public buildbots with it will be available https://discourse.llvm.org/t/rfc-lldb-support-remote-run-of-shell-tests/80072/4, https://lab.llvm.org/staging/#/builders/195. Also, the case when no new features are added, but existing ones are changed, shouldn't be neglected. In such cases, it is hard to justify disabling tests without finding out the reason. > For me, this just sends the wrong message/sets the wrong incentive. >From my point of view, the current incentive given is that remote debugging >compatibility may be ignored when new commits are made since it's something >rare enough/hard to test properly (because testing with it requires writing an >API test). The ability to run Shell tests remotely (and regular testing) may reduce the barrier for those who take remote debugging into account in their patches. https://github.com/llvm/llvm-project/pull/95986 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4078,6 +4255,9 @@ void RegisterRequestCallbacks() {
g_dap.RegisterRequestCallback("threads", request_threads);
g_dap.RegisterRequestCallback("variables", request_variables);
g_dap.RegisterRequestCallback("disassemble", request_disassemble);
+ // Instruction breapoint request
santhoshe447 wrote:
Thanks @walter-erquinigo
This will work
https://github.com/llvm/llvm-project/pull/105278
___
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 recognizers for libc++ `std::invoke` (PR #105695)
@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
public:
LibCXXFrameRecognizer()
- : m_hidden_function_regex(
-R"(^std::__1::(__function.*::operator\(\)|__invoke))"
-R"((\[.*\])?)"// ABI tag.
-R"(( const)?$)"), // const.
+ : m_hidden_regex{
+// internal implementation details of std::function
jasonmolenda wrote:
Love to see these example strings we're matching against
https://github.com/llvm/llvm-project/pull/105695
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Conditionalize context_switch attribute based on kernel version (PR #105715)
https://github.com/root-kidik edited https://github.com/llvm/llvm-project/pull/105715 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
https://github.com/clayborg commented: You didn't add the new launch config variable to the package.json. Please add with a new PR with descriptions. https://github.com/llvm/llvm-project/pull/104874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
clayborg wrote:
>From the DAP protocol for "StackTraceRequest", I see this in the response:
```
/**
* The total number of frames available in the stack. If omitted or if
* `totalFrames` is larger than the available frames, a client is expected
* to request frames until a request returns less frames than requested
* (which indicates the end of the stack). Returning monotonically
* increasing `totalFrames` values for subsequent requests can be used to
* enforce paging in the client.
*/
totalFrames?: number;
```
Right now we are making the requests to `thread.GetCurrentExceptionBacktrace()`
and `thread.GetExtendedBacktraceThread("libdispatch")` just to update the total
number of frames even though we may never access those items. Most stack frame
requests for threads that are not expanded in the GUI will ask for 1 frame:
frame zero.
Seeing the above statement from the spec: `Returning monotonically increasing
`totalFrames` values for subsequent requests can be used to enforce paging in
the client.`. We should be able to use this to just replace this:
```
auto totalFrames = thread.GetNumFrames();
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
lldb::SBThread queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
lldb::SBThread exception_backtrace_thread =
thread.GetCurrentExceptionBacktrace();
if (exception_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the exception thread.
totalFrames += exception_backtrace_thread.GetNumFrames() + 1;
}
```
with:
```
auto totalFrames = startFrame + levels + STACK_PAGE_SIZE;
```
So then we don't need to accurately calculate the number of stack frames. This
will make all of our code more performant as just calling
`thread.GetNumFrames();` is expensize. It will also keep us from calling
`thread.GetExtendedBacktraceThread("libdispatch");` or
`thread.GetCurrentExceptionBacktrace();` unless we need to. Since we can lazily
populate these items when we need to.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -6544,7 +6545,8 @@ static void AddRegion(const MemoryRegionInfo ®ion, bool try_dirty_pages, return; if (try_dirty_pages && AddDirtyPages(region, ranges)) return; - ranges.push_back(CreateCoreFileMemoryRange(region)); + + ranges.Append(region.GetRange().GetRangeBase(), region.GetRange().GetByteSize(), CreateCoreFileMemoryRange(region)); Jlalond wrote: Currently I'm having issues with my git-clang format. I'll sort before we go to commit. https://github.com/llvm/llvm-project/pull/105442 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -101,6 +103,18 @@ bool SaveCoreOptions::ShouldThreadBeSaved(lldb::tid_t tid)
const {
return m_threads_to_save.count(tid) > 0;
}
+bool SaveCoreOptions::HasSpecifiedThreads() const {
+ return !m_threads_to_save.empty();
+}
+
+void SaveCoreOptions::AddMemoryRegionToSave(const
lldb_private::MemoryRegionInfo ®ion) {
+ m_regions_to_save.Insert(region.GetRange(), /*combine=*/true);
Jlalond wrote:
Insert inserts into a sorted order. I think for the SaveCore frontend we
shouldn't worry about permissions and they should instead be split in the
process layer.
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (PR #105442)
@@ -1222,6 +1222,7 @@ enum SaveCoreStyle {
eSaveCoreFull = 1,
eSaveCoreDirtyOnly = 2,
eSaveCoreStackOnly = 3,
+ eSaveCoreCustom = 4,
Jlalond wrote:
I think `CustomOnly` sounds a bit clunky, but it does convey only custom fields
will be saved and fits with the current naming standard.
https://github.com/llvm/llvm-project/pull/105442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
@@ -3111,17 +3115,20 @@ void request_stackTrace(const llvm::json::Object
&request) {
// This will always return an invalid thread when
// libBacktraceRecording.dylib is not loaded or if there is no extended
// backtrace.
-lldb::SBThread queue_backtrace_thread =
-thread.GetExtendedBacktraceThread("libdispatch");
+lldb::SBThread queue_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ queue_backtrace_thread =
thread.GetExtendedBacktraceThread("libdispatch");
if (queue_backtrace_thread.IsValid()) {
// One extra frame as a label to mark the enqueued thread.
totalFrames += queue_backtrace_thread.GetNumFrames() + 1;
}
// This will always return an invalid thread when there is no exception in
// the current thread.
-lldb::SBThread exception_backtrace_thread =
-thread.GetCurrentExceptionBacktrace();
+lldb::SBThread exception_backtrace_thread;
+if (g_dap.enable_display_extended_backtrace)
+ exception_backtrace_thread = thread.GetCurrentExceptionBacktrace();
clayborg wrote:
Expression evaluation can also take longer than 1 second depending on the
amount of total debug info and if there are accelerator tables.
https://github.com/llvm/llvm-project/pull/104874
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix dap stacktrace perf issue (PR #104874)
ashgti wrote: I'll try to work that into my refactor of the call for `thread.GetCurrentExceptionBacktrace()` https://github.com/llvm/llvm-project/pull/104874 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -4082,6 +4084,260 @@ void request__testGetTargetBreakpoints(const
llvm::json::Object &request) {
g_dap.SendJSON(llvm::json::Value(std::move(response)));
}
+// "SetInstructionBreakpointsRequest" : {
+// "allOf" : [
+// {"$ref" : "#/definitions/Request"}, {
+// "type" : "object",
+// "description" :
+// "Replaces all existing instruction breakpoints. Typically, "
+// "instruction breakpoints would be set from a disassembly window. "
+// "\nTo clear all instruction breakpoints, specify an empty "
+// "array.\nWhen an instruction breakpoint is hit, a `stopped` event
"
+// "(with reason `instruction breakpoint`) is generated.\nClients "
+// "should only call this request if the corresponding capability "
+// "`supportsInstructionBreakpoints` is true.",
+// "properties" : {
+// "command" : {"type" : "string", "enum" :
+// ["setInstructionBreakpoints"]}, "arguments" :
+// {"$ref" : "#/definitions/SetInstructionBreakpointsArguments"}
+// },
+// "required" : [ "command", "arguments" ]
+// }
+// ]
+// },
+// "SetInstructionBreakpointsArguments"
+// : {
+// "type" : "object",
+// "description" : "Arguments for `setInstructionBreakpoints` request",
+// "properties" : {
+// "breakpoints" : {
+// "type" : "array",
+// "items" : {"$ref" : "#/definitions/InstructionBreakpoint"},
+// "description" : "The instruction references of the breakpoints"
+// }
+// },
+// "required" : ["breakpoints"]
+// },
+// "SetInstructionBreakpointsResponse"
+// : {
+// "allOf" : [
+// {"$ref" : "#/definitions/Response"}, {
+// "type" : "object",
+// "description" : "Response to `setInstructionBreakpoints` request",
+// "properties" : {
+// "body" : {
+// "type" : "object",
+// "properties" : {
+// "breakpoints" : {
+// "type" : "array",
+// "items" : {"$ref" : "#/definitions/Breakpoint"},
+// "description" :
+// "Information about the breakpoints. The array elements
+// " "correspond to the elements of the `breakpoints`
+// array."
+// }
+// },
+// "required" : ["breakpoints"]
+// }
+// },
+// "required" : ["body"]
+// }
+// ]
+// },
+// "InstructionBreakpoint" : {
+// "type" : "object",
+// "description" : "Properties of a breakpoint passed to the "
+// "`setInstructionBreakpoints` request",
+// "properties" : {
+// "instructionReference" : {
+// "type" : "string",
+// "description" :
+// "The instruction reference of the breakpoint.\nThis should be a "
+// "memory or instruction pointer reference from an
+// `EvaluateResponse`, "
+// "`Variable`, `StackFrame`, `GotoTarget`, or `Breakpoint`."
+// },
+// "offset" : {
+// "type" : "integer",
+// "description" : "The offset from the instruction reference in "
+// "bytes.\nThis can be negative."
+// },
+// "condition" : {
+// "type" : "string",
+// "description" : "An expression for conditional breakpoints.\nIt is
only
+// "
+// "honored by a debug adapter if the corresponding "
+// "capability `supportsConditionalBreakpoints` is true."
+// },
+// "hitCondition" : {
+// "type" : "string",
+// "description" : "An expression that controls how many hits of the "
+// "breakpoint are ignored.\nThe debug adapter is
expected
+// " "to interpret the expression as needed.\nThe
+// attribute " "is only honored by a debug adapter if the
+// corresponding " "capability
+// `supportsHitConditionalBreakpoints` is true."
+// },
+// "mode" : {
+// "type" : "string",
+// "description" : "The mode of this breakpoint. If defined, this must be
+// "
+// "one of the `breakpointModes` the debug adapter "
+// "advertised in its `Capabilities`."
+// }
+// },
+// "required" : ["instructionReference"]
+// },
+// "Breakpoint"
+// : {
+// "type" : "object",
+// "description" :
+// "Information about a breakpoint created in `setBreakpoints`, "
+// "`setFunctionBreakpoints`, `setInstructionBreakpoints`, or "
+// "`setDataBreakpoints` requests.",
+// "properties" : {
+// "id" : {
+// "type" : "integer",
+// "description" :
+// "The ident
[Lldb-commits] [lldb] [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (PR #105278)
@@ -766,6 +766,102 @@ llvm::json::Value CreateStackFrame(lldb::SBFrame &frame) {
return llvm::json::Value(std::move(object));
}
+// Response to `setInstructionBreakpoints` request.
+// "Breakpoint": {
+// "type": "object",
+// "description": "Response to `setInstructionBreakpoints` request.",
+// "properties": {
+// "id": {
+// "type": "number",
+// "description": "The identifier for the breakpoint. It is needed if
+// breakpoint events are used to update or remove breakpoints."
+// },
+// "verified": {
+// "type": "boolean",
+// "description": "If true, the breakpoint could be set (but not
+// necessarily at the desired location."
+// },
+// "message": {
+// "type": "string",
+// "description": "A message about the state of the breakpoint.
+// This is shown to the user and can be used to explain why a breakpoint
+// could not be verified."
+// },
+// "source": {
+// "type": "Source",
+// "description": "The source where the breakpoint is located."
+// },
+// "line": {
+// "type": "number",
+// "description": "The start line of the actual range covered by the
+// breakpoint."
+// },
+// "column": {
+// "type": "number",
+// "description": "The start column of the actual range covered by the
+// breakpoint."
+// },
+// "endLine": {
+// "type": "number",
+// "description": "The end line of the actual range covered by the
+// breakpoint."
+// },
+// "endColumn": {
+// "type": "number",
+// "description": "The end column of the actual range covered by the
+// breakpoint. If no end line is given, then the end column is assumed to
+// be in the start line."
+// },
+// "instructionReference": {
+// "type": "string",
+// "description": "A memory reference to where the breakpoint is set."
+// },
+// "offset": {
+// "type": "number",
+// "description": "The offset from the instruction reference.
+// This can be negative."
+// },
+// },
+// "required": [ "id", "verified", "line"]
+// }
+llvm::json::Value CreateInstructionBreakpoint(lldb::SBBreakpoint &bp) {
ZequanWu wrote:
There's a method `Breakpoint::CreateJsonObject` which basically does the same
thing as this function. Can you reuse that one?
https://github.com/llvm/llvm-project/pull/105278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB][Data Formatters] Calculate average and total time for summary providers within lldb (PR #102708)
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/102708
>From b451c1630a9799180a3a976a4ecd86c8d4ec35da Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Thu, 8 Aug 2024 08:58:52 -0700
Subject: [PATCH 01/16] Initial attempt at new classes Summary statistics in
SummaryStatistics.h/cpp.
---
lldb/include/lldb/Target/SummaryStatistics.h | 37
lldb/include/lldb/Target/Target.h| 5 +++
lldb/source/Core/ValueObject.cpp | 5 +++
lldb/source/Target/CMakeLists.txt| 1 +
lldb/source/Target/SummaryStatistics.cpp | 26 ++
lldb/source/Target/Target.cpp| 9 +
6 files changed, 83 insertions(+)
create mode 100644 lldb/include/lldb/Target/SummaryStatistics.h
create mode 100644 lldb/source/Target/SummaryStatistics.cpp
diff --git a/lldb/include/lldb/Target/SummaryStatistics.h
b/lldb/include/lldb/Target/SummaryStatistics.h
new file mode 100644
index 00..0198249ba0b170
--- /dev/null
+++ b/lldb/include/lldb/Target/SummaryStatistics.h
@@ -0,0 +1,37 @@
+//===-- SummaryStatistics.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_TARGET_SUMMARYSTATISTICS_H
+#define LLDB_TARGET_SUMMARYSTATISTICS_H
+
+
+#include "lldb/Target/Statistics.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace lldb_private {
+
+class SummaryStatistics {
+public:
+ SummaryStatistics(lldb_private::ConstString name) :
+m_total_time(), m_name(name), m_summary_count(0) {}
+
+ lldb_private::StatsDuration &GetDurationReference();
+
+ lldb_private::ConstString GetName() const;
+
+ uint64_t GetSummaryCount() const;
+
+private:
+ lldb_private::StatsDuration m_total_time;
+ lldb_private::ConstString m_name;
+ uint64_t m_summary_count;
+};
+
+} // namespace lldb_private
+
+#endif // LLDB_TARGET_SUMMARYSTATISTICS_H
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index 7f4d607f5427df..94ce505231e084 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -30,6 +30,7 @@
#include "lldb/Target/PathMappingList.h"
#include "lldb/Target/SectionLoadHistory.h"
#include "lldb/Target/Statistics.h"
+#include "lldb/Target/SummaryStatistics.h"
#include "lldb/Target/ThreadSpec.h"
#include "lldb/Utility/ArchSpec.h"
#include "lldb/Utility/Broadcaster.h"
@@ -261,6 +262,7 @@ class TargetProperties : public Properties {
bool GetDebugUtilityExpression() const;
+
private:
std::optional
GetExperimentalPropertyValue(size_t prop_idx,
@@ -1224,6 +1226,8 @@ class Target : public
std::enable_shared_from_this,
void ClearAllLoadedSections();
+ lldb_private::StatsDuration&
GetSummaryProviderDuration(lldb_private::ConstString summary_provider_name);
+
/// Set the \a Trace object containing processor trace information of this
/// target.
///
@@ -1557,6 +1561,7 @@ class Target : public
std::enable_shared_from_this,
std::string m_label;
ModuleList m_images; ///< The list of images for this process (shared
/// libraries and anything dynamically loaded).
+ std::map
m_summary_stats_map;
SectionLoadHistory m_section_load_history;
BreakpointList m_breakpoint_list;
BreakpointList m_internal_breakpoint_list;
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index 8f72efc2299b4f..bed4ab8d69cbda 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -615,6 +615,11 @@ bool ValueObject::GetSummaryAsCString(TypeSummaryImpl
*summary_ptr,
m_synthetic_value->UpdateValueIfNeeded(); // the summary might depend on
// the synthetic children being
// up-to-date (e.g. ${svar%#})
+StatsDuration &summary_duration = GetExecutionContextRef()
+.GetProcessSP()
+->GetTarget()
+
.GetSummaryProviderDuration(GetTypeName());
+ElapsedTime elapsed(summary_duration);
summary_ptr->FormatObject(this, destination, actual_options);
}
m_flags.m_is_getting_summary = false;
diff --git a/lldb/source/Target/CMakeLists.txt
b/lldb/source/Target/CMakeLists.txt
index a42c44b761dc56..e51da37cd84db3 100644
--- a/lldb/source/Target/CMakeLists.txt
+++ b/lldb/source/Target/CMakeLists.txt
@@ -46,6 +46,7 @@ add_lldb_library(lldbTarget
Statistics.cpp
StopInfo.cpp
StructuredDataPlugin.cpp
+ SummaryStatistics.cpp
SystemRuntime.cpp
Target.cpp
TargetList.cpp
diff --git a/lldb/source/Target/SummaryStatistics.cpp
b/lldb/so
[Lldb-commits] [lldb] [lldb] Add frame recognizers for libc++ `std::invoke` (PR #105695)
@@ -53,10 +54,32 @@ class LibCXXFrameRecognizer : public StackFrameRecognizer {
public:
LibCXXFrameRecognizer()
- : m_hidden_function_regex(
-R"(^std::__1::(__function.*::operator\(\)|__invoke))"
-R"((\[.*\])?)"// ABI tag.
-R"(( const)?$)"), // const.
+ : m_hidden_regex{
+// internal implementation details of std::function
+//std::__1::__function::__alloc_func, void ()>::operator()[abi:ne20]
+//std::__1::__function::__func, void ()>::operator()
+//std::__1::__function::__value_func::operator()[abi:ne20]() const
+RegularExpression{""
+ R"(^std::__[0-9]*::)" // Namespace.
+ R"(__function::.*::operator\(\))"
+ R"((\[.*\])?)"// ABI tag.
+ R"(( const)?$)"}, // const.
+// internal implementation details of std::invoke
+// std::__1::__invoke[abi:ne20]
+RegularExpression{
+ R"(^std::__[0-9]*::)" // Namespace.
+ R"(__invoke)"
vogelsgesang wrote:
I wonder if we should simply hide everything starting with
`^std::__[0-9]*::__.*`. Or are there any `__` functions in libc++ which are not
implementation details and should be shown in stacktraces by default?
https://github.com/llvm/llvm-project/pull/105695
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/105756
Instead of doing the coarse-grained initial matching of frame recognizers on
fully demangled names, it can be much more efficient and reliable to filter on
all functions of a particular language by discriminating on the mangled symbol
name. This way a recognizer can be registered that should run on all functions
of a particular language by matching on its mangling prefix(es).
>From c6f246a66b721df31003b7d2f8e32b5a2ca16a3f Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Thu, 22 Aug 2024 17:35:01 -0700
Subject: [PATCH] [lldb] Support frame recognizer regexp on mangled names.
Instead of doing the coarse-grained initial matching of frame
recognizers on fully demangled names, it can be much more efficient
and reliable to filter on all functions of a particular language by
discriminating on the mangled symbol name. This way a recognizer can
be registered that should run on all functions of a particular
language by matching on its mangling prefix(es).
---
.../lldb/Target/StackFrameRecognizer.h| 9 +++-
lldb/source/Commands/CommandObjectFrame.cpp | 54 ---
.../CPlusPlus/CPPLanguageRuntime.cpp | 1 +
lldb/source/Target/AssertFrameRecognizer.cpp | 1 +
lldb/source/Target/StackFrameRecognizer.cpp | 23
.../Target/VerboseTrapFrameRecognizer.cpp | 3 +-
.../frame/recognizer/TestFrameRecognizer.py | 6 +--
.../Target/StackFrameRecognizerTest.cpp | 3 +-
8 files changed, 66 insertions(+), 34 deletions(-)
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 8acebc12c4b1dc..a1757530870a02 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -109,15 +109,21 @@ class StackFrameRecognizerManager {
ConstString module, llvm::ArrayRef symbols,
bool first_instruction_only = true);
+ /// Add a new recognizer that triggers on a symbol regex.
+ ///
+ /// \param symbol_mangling controls whether the regex should apply
+ /// to the mangled or demangled name.
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
lldb::RegularExpressionSP module,
lldb::RegularExpressionSP symbol,
+ Mangled::NamePreference symbol_mangling,
bool first_instruction_only = true);
void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
std::string module, llvm::ArrayRef symbols,
-bool regexp)> const &callback);
+Mangled::NamePreference name_reference, bool regexp)> const
+ &callback);
bool RemoveRecognizerWithID(uint32_t recognizer_id);
@@ -142,6 +148,7 @@ class StackFrameRecognizerManager {
lldb::RegularExpressionSP module_regexp;
std::vector symbols;
lldb::RegularExpressionSP symbol_regexp;
+Mangled::NamePreference symbol_mangling;
bool first_instruction_only;
};
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp
b/lldb/source/Commands/CommandObjectFrame.cpp
index 46c75e3dd159c0..2a9605d2072dae 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -899,7 +899,8 @@ void CommandObjectFrameRecognizerAdd::DoExecute(Args
&command,
auto func =
RegularExpressionSP(new
RegularExpression(m_options.m_symbols.front()));
GetTarget().GetFrameRecognizerManager().AddRecognizer(
-recognizer_sp, module, func, m_options.m_first_instruction_only);
+recognizer_sp, module, func, Mangled::NamePreference::ePreferDemangled,
+m_options.m_first_instruction_only);
} else {
auto module = ConstString(m_options.m_module);
std::vector symbols(m_options.m_symbols.begin(),
@@ -927,6 +928,32 @@ class CommandObjectFrameRecognizerClear : public
CommandObjectParsed {
}
};
+static void
+PrintRecognizerDetails(Stream &strm, const std::string &module,
+ llvm::ArrayRef symbols,
+ Mangled::NamePreference preference, bool regexp) {
+ if (!module.empty())
+strm << ", module " << module;
+ for (auto &symbol : symbols) {
+strm << ", ";
+if (!regexp)
+ strm << "symbol";
+else
+ switch (preference) {
+ case Mangled::NamePreference ::ePreferMangled:
+strm << "mangled symbol regexp";
+break;
+ case Mangled::NamePreference ::ePreferDemangled:
+strm << "demangled symbol regexp";
+break;
+ case Mangled::NamePreference ::ePreferDemangledWithoutArguments:
+strm << "demangled (no args) symbol regexp";
+break;
+ }
+strm << " " << symbol;
+ }
+}
+
class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
public:
CommandObjectFram
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
Instead of doing the coarse-grained initial matching of frame recognizers on
fully demangled names, it can be much more efficient and reliable to filter on
all functions of a particular language by discriminating on the mangled symbol
name. This way a recognizer can be registered that should run on all functions
of a particular language by matching on its mangling prefix(es).
---
Full diff: https://github.com/llvm/llvm-project/pull/105756.diff
8 Files Affected:
- (modified) lldb/include/lldb/Target/StackFrameRecognizer.h (+8-1)
- (modified) lldb/source/Commands/CommandObjectFrame.cpp (+35-19)
- (modified)
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp (+1)
- (modified) lldb/source/Target/AssertFrameRecognizer.cpp (+1)
- (modified) lldb/source/Target/StackFrameRecognizer.cpp (+14-9)
- (modified) lldb/source/Target/VerboseTrapFrameRecognizer.cpp (+2-1)
- (modified) lldb/test/API/commands/frame/recognizer/TestFrameRecognizer.py
(+3-3)
- (modified) lldb/unittests/Target/StackFrameRecognizerTest.cpp (+2-1)
``diff
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 8acebc12c4b1dc..a1757530870a02 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -109,15 +109,21 @@ class StackFrameRecognizerManager {
ConstString module, llvm::ArrayRef symbols,
bool first_instruction_only = true);
+ /// Add a new recognizer that triggers on a symbol regex.
+ ///
+ /// \param symbol_mangling controls whether the regex should apply
+ /// to the mangled or demangled name.
void AddRecognizer(lldb::StackFrameRecognizerSP recognizer,
lldb::RegularExpressionSP module,
lldb::RegularExpressionSP symbol,
+ Mangled::NamePreference symbol_mangling,
bool first_instruction_only = true);
void ForEach(std::function<
void(uint32_t recognizer_id, std::string recognizer_name,
std::string module, llvm::ArrayRef symbols,
-bool regexp)> const &callback);
+Mangled::NamePreference name_reference, bool regexp)> const
+ &callback);
bool RemoveRecognizerWithID(uint32_t recognizer_id);
@@ -142,6 +148,7 @@ class StackFrameRecognizerManager {
lldb::RegularExpressionSP module_regexp;
std::vector symbols;
lldb::RegularExpressionSP symbol_regexp;
+Mangled::NamePreference symbol_mangling;
bool first_instruction_only;
};
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp
b/lldb/source/Commands/CommandObjectFrame.cpp
index 46c75e3dd159c0..2a9605d2072dae 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -899,7 +899,8 @@ void CommandObjectFrameRecognizerAdd::DoExecute(Args
&command,
auto func =
RegularExpressionSP(new
RegularExpression(m_options.m_symbols.front()));
GetTarget().GetFrameRecognizerManager().AddRecognizer(
-recognizer_sp, module, func, m_options.m_first_instruction_only);
+recognizer_sp, module, func, Mangled::NamePreference::ePreferDemangled,
+m_options.m_first_instruction_only);
} else {
auto module = ConstString(m_options.m_module);
std::vector symbols(m_options.m_symbols.begin(),
@@ -927,6 +928,32 @@ class CommandObjectFrameRecognizerClear : public
CommandObjectParsed {
}
};
+static void
+PrintRecognizerDetails(Stream &strm, const std::string &module,
+ llvm::ArrayRef symbols,
+ Mangled::NamePreference preference, bool regexp) {
+ if (!module.empty())
+strm << ", module " << module;
+ for (auto &symbol : symbols) {
+strm << ", ";
+if (!regexp)
+ strm << "symbol";
+else
+ switch (preference) {
+ case Mangled::NamePreference ::ePreferMangled:
+strm << "mangled symbol regexp";
+break;
+ case Mangled::NamePreference ::ePreferDemangled:
+strm << "demangled symbol regexp";
+break;
+ case Mangled::NamePreference ::ePreferDemangledWithoutArguments:
+strm << "demangled (no args) symbol regexp";
+break;
+ }
+strm << " " << symbol;
+ }
+}
+
class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
public:
CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
@@ -947,19 +974,13 @@ class CommandObjectFrameRecognizerDelete : public
CommandObjectParsed {
GetTarget().GetFrameRecognizerManager().ForEach(
[&request](uint32_t rid, std::string rname, std::string module,
llvm::ArrayRef symbols,
- bool regexp) {
+ Mangled::NamePreference preference, bool
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
https://github.com/danobi created
https://github.com/llvm/llvm-project/pull/105757
Previously python was initialized during static registration of the plugin.
This causes the python interpreter to run even if python support is explicitly
disabled thru:
SBDebugger::SetScriptLanguage(ScriptLanguage::eScriptLanguageNone)
This commit defers python initialization until a ScriptInterpreterPython
instance is created.
>From 049c89e9e8e92cb1564020335d6f69d89d8adf43 Mon Sep 17 00:00:00 2001
From: Daniel Xu
Date: Thu, 22 Aug 2024 17:32:22 -0700
Subject: [PATCH] [lldb][NFC] Defer python init until ScriptInterpreter is
created
Previously python was initialized during static registration of the
plugin. This causes the python interpreter to run even if python support
is explicitly disabled thru:
SBDebugger::SetScriptLanguage(ScriptLanguage::eScriptLanguageNone)
This commit defers python initialization until a ScriptInterpreterPython
instance is created.
---
.../ScriptInterpreter/Python/ScriptInterpreterPython.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 335c482f8495ad..bc4e7485067048 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -352,7 +352,6 @@ void ScriptInterpreterPython::Initialize() {
GetPluginDescriptionStatic(),
lldb::eScriptLanguagePython,
ScriptInterpreterPythonImpl::CreateInstance);
-ScriptInterpreterPythonImpl::Initialize();
});
}
@@ -429,6 +428,10 @@
ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(Debugger &debugger)
m_active_io_handler(eIOHandlerNone), m_session_is_active(false),
m_pty_secondary_is_open(false), m_valid_session(true), m_lock_count(0),
m_command_thread_state(nullptr) {
+ static llvm::once_flag g_once_flag;
+ llvm::call_once(g_once_flag, []() {
+ScriptInterpreterPythonImpl::Initialize();
+ });
m_dictionary_name.append("_dict");
StreamString run_string;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/105757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
@@ -92,11 +95,13 @@ void StackFrameRecognizerManager::ForEach(
symbol_name = entry.symbol_regexp->GetText().str();
callback(entry.recognizer_id, entry.recognizer->GetName(), module_name,
- llvm::ArrayRef(ConstString(symbol_name)), true);
+ llvm::ArrayRef(ConstString(symbol_name)), entry.symbol_mangling,
+ true);
} else {
callback(entry.recognizer_id, entry.recognizer->GetName(),
- entry.module.GetCString(), entry.symbols, false);
+ entry.module.GetCString(), entry.symbols, entry.symbol_mangling,
+ false);
}
}
}
vogelsgesang wrote:
afaict, this code is incomplete. The matching in `GetRecognizerForFrame` also
needs to be adjusted.
In https://github.com/llvm/llvm-project/pull/105695, you can find an
implementation of pretty much the same idea. However, I implemented only
`GetRecognizerForFrame` and skipped, e.g., `ForEach`
https://github.com/llvm/llvm-project/pull/105756
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
@@ -92,11 +95,13 @@ void StackFrameRecognizerManager::ForEach(
symbol_name = entry.symbol_regexp->GetText().str();
callback(entry.recognizer_id, entry.recognizer->GetName(), module_name,
- llvm::ArrayRef(ConstString(symbol_name)), true);
+ llvm::ArrayRef(ConstString(symbol_name)), entry.symbol_mangling,
+ true);
} else {
callback(entry.recognizer_id, entry.recognizer->GetName(),
- entry.module.GetCString(), entry.symbols, false);
+ entry.module.GetCString(), entry.symbols, entry.symbol_mangling,
+ false);
}
}
}
vogelsgesang wrote:
Feel free to copy-paste / adjust whichever code from #105695 which you might
find useful. I will rebase that commit later on, after your changes landed. (I
cannot land #105695 before #104523 gets re-applied, anyway)
https://github.com/llvm/llvm-project/pull/105756
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/105756 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
danobi wrote: Also see: https://github.com/bpftrace/bpftrace/pull/3359 https://github.com/llvm/llvm-project/pull/105757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
https://github.com/danobi ready_for_review https://github.com/llvm/llvm-project/pull/105757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Daniel Xu (danobi)
Changes
Previously python was initialized during static registration of the plugin.
This causes the python interpreter to run even if python support is explicitly
disabled thru:
SBDebugger::SetScriptLanguage(ScriptLanguage::eScriptLanguageNone)
This commit defers python initialization until a ScriptInterpreterPython
instance is created.
---
Full diff: https://github.com/llvm/llvm-project/pull/105757.diff
1 Files Affected:
- (modified)
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp (+4-1)
``diff
diff --git
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 335c482f8495ad..bc4e7485067048 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -352,7 +352,6 @@ void ScriptInterpreterPython::Initialize() {
GetPluginDescriptionStatic(),
lldb::eScriptLanguagePython,
ScriptInterpreterPythonImpl::CreateInstance);
-ScriptInterpreterPythonImpl::Initialize();
});
}
@@ -429,6 +428,10 @@
ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(Debugger &debugger)
m_active_io_handler(eIOHandlerNone), m_session_is_active(false),
m_pty_secondary_is_open(false), m_valid_session(true), m_lock_count(0),
m_command_thread_state(nullptr) {
+ static llvm::once_flag g_once_flag;
+ llvm::call_once(g_once_flag, []() {
+ScriptInterpreterPythonImpl::Initialize();
+ });
m_dictionary_name.append("_dict");
StreamString run_string;
``
https://github.com/llvm/llvm-project/pull/105757
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [mlir] [Support] Validate number of arguments passed to formatv() (PR #105745)
@@ -74,16 +75,31 @@ class formatv_object_base {
static std::pair
splitLiteralAndReplacement(StringRef Fmt);
- formatv_object_base(StringRef Fmt,
+ formatv_object_base(StringRef Fmt, bool ValidateNumArgs,
ArrayRef Adapters)
- : Fmt(Fmt), Adapters(Adapters) {}
+ : Fmt(Fmt), ValidateNumArgs(ValidateNumArgs), Adapters(Adapters) {}
formatv_object_base(formatv_object_base const &rhs) = delete;
formatv_object_base(formatv_object_base &&rhs) = default;
public:
void format(raw_ostream &S) const {
-for (auto &R : parseFormatString(Fmt)) {
+const auto [Replacements, NumExpectedParams] = parseFormatString(Fmt);
+// Fail formatv() call if the number of replacement parameters provided
+// does not match the expected number after parsing the format string.
+// Assert in debug builds.
+if (ValidateNumArgs && NumExpectedParams != Adapters.size()) {
+ errs() << "Invalid format() in formatv: " << Fmt << "\n";
+ assert(0 &&
+ "Mismatch between replacement parameters expected and provided");
+
+ S << "formatv() error: " << NumExpectedParams
+<< " replacement parameters expected, but " << Adapters.size()
+<< " provided";
zwuis wrote:
Do we need to add a `\n` here?
https://github.com/llvm/llvm-project/pull/105745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove limit on max memory read size (PR #105765)
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/105765
`memory read` will return an error if you try to read more than 1k bytes in a
single command, instructing you to set
`target.max-memory-read-size` or use `--force` if you intended to read more
than that. This is a safeguard for a command where people are being explicit
about how much memory they would like lldb to read (either to display, or save
to a file) and is an annoyance every time you need to read more than a small
amount. If someone confuses the --count argument with the start address, lldb
may begin dumping gigabytes of data but I'd rather that behavior than requiring
everyone to special-case their way around a common use case.
I don't want to remove the setting because many people have added (much larger)
default max read sizes to their ~/.lldbinit files after hitting this behavior.
Another option would be to stop reading/using the value in Target.cpp, but I
see no harm in leaving the setting if someone really does prefer to have a
small cap on their memory read size.
>From 6a27ad3be748a6072014a805a5a94dede9321432 Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 22 Aug 2024 18:29:55 -0700
Subject: [PATCH] [lldb] Remove limit on max memory read size
`memory read` will return an error if you try to read more than 1k
bytes in a single command, instructing you to set
`target.max-memory-read-size` or use `--force` if you intended to
read more than that. This is a safeguard for a command where people
are being explicit about how much memory they would like lldb to
read (either to display, or save to a file) and is an annoyance
every time you need to read more than a small amount. If someone
confuses the --count argument with the start address, lldb may begin
dumping gigabytes of data but I'd rather that behavior than requiring
everyone to special-case their way around a common use case.
---
lldb/source/Target/TargetProperties.td | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index 7bb5bd53688b14..f553d92f7c64f6 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -102,7 +102,7 @@ let Definition = "target" in {
DefaultUnsignedValue<1024>,
Desc<"Maximum number of characters to show when using %s in summary
strings.">;
def MaxMemReadSize: Property<"max-memory-read-size", "UInt64">,
-DefaultUnsignedValue<1024>,
+DefaultUnsignedValue<4294967295>,
Desc<"Maximum number of bytes that 'memory read' will fetch before --force
must be specified.">;
def BreakpointUseAvoidList: Property<"breakpoints-use-platform-avoid-list",
"Boolean">,
DefaultTrue,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove limit on max memory read size (PR #105765)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jason Molenda (jasonmolenda)
Changes
`memory read` will return an error if you try to read more than 1k bytes in a
single command, instructing you to set
`target.max-memory-read-size` or use `--force` if you intended to read more
than that. This is a safeguard for a command where people are being explicit
about how much memory they would like lldb to read (either to display, or save
to a file) and is an annoyance every time you need to read more than a small
amount. If someone confuses the --count argument with the start address, lldb
may begin dumping gigabytes of data but I'd rather that behavior than requiring
everyone to special-case their way around a common use case.
I don't want to remove the setting because many people have added (much larger)
default max read sizes to their ~/.lldbinit files after hitting this behavior.
Another option would be to stop reading/using the value in Target.cpp, but I
see no harm in leaving the setting if someone really does prefer to have a
small cap on their memory read size.
---
Full diff: https://github.com/llvm/llvm-project/pull/105765.diff
1 Files Affected:
- (modified) lldb/source/Target/TargetProperties.td (+1-1)
``diff
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index 7bb5bd53688b14..f553d92f7c64f6 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -102,7 +102,7 @@ let Definition = "target" in {
DefaultUnsignedValue<1024>,
Desc<"Maximum number of characters to show when using %s in summary
strings.">;
def MaxMemReadSize: Property<"max-memory-read-size", "UInt64">,
-DefaultUnsignedValue<1024>,
+DefaultUnsignedValue<4294967295>,
Desc<"Maximum number of bytes that 'memory read' will fetch before --force
must be specified.">;
def BreakpointUseAvoidList: Property<"breakpoints-use-platform-avoid-list",
"Boolean">,
DefaultTrue,
``
https://github.com/llvm/llvm-project/pull/105765
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove limit on max memory read size (PR #105765)
jasonmolenda wrote: (the setting is a UInt64, but Target.cpp reads it and returns a uint32_t, so I only did UINT32_MAX value) https://github.com/llvm/llvm-project/pull/105765 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Support frame recognizer regexp on mangled names. (PR #105756)
https://github.com/vogelsgesang edited https://github.com/llvm/llvm-project/pull/105756 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove limit on max memory read size (PR #105765)
jasonmolenda wrote: lol my hubris is on display, the PR testing hit a test failure in ... TestMemoryReadMaximumSize.py which I wrote & merged earlier today, and assumes there is a limit of 1024. ;) https://github.com/llvm/llvm-project/pull/105765 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [mlir] [Support] Validate number of arguments passed to formatv() (PR #105745)
@@ -74,16 +75,31 @@ class formatv_object_base {
static std::pair
splitLiteralAndReplacement(StringRef Fmt);
- formatv_object_base(StringRef Fmt,
+ formatv_object_base(StringRef Fmt, bool ValidateNumArgs,
ArrayRef Adapters)
- : Fmt(Fmt), Adapters(Adapters) {}
+ : Fmt(Fmt), ValidateNumArgs(ValidateNumArgs), Adapters(Adapters) {}
formatv_object_base(formatv_object_base const &rhs) = delete;
formatv_object_base(formatv_object_base &&rhs) = default;
public:
void format(raw_ostream &S) const {
-for (auto &R : parseFormatString(Fmt)) {
+const auto [Replacements, NumExpectedParams] = parseFormatString(Fmt);
+// Fail formatv() call if the number of replacement parameters provided
+// does not match the expected number after parsing the format string.
+// Assert in debug builds.
+if (ValidateNumArgs && NumExpectedParams != Adapters.size()) {
+ errs() << "Invalid format() in formatv: " << Fmt << "\n";
+ assert(0 &&
+ "Mismatch between replacement parameters expected and provided");
+
+ S << "formatv() error: " << NumExpectedParams
+<< " replacement parameters expected, but " << Adapters.size()
+<< " provided";
jurahul wrote:
Thanks. This is not ready for review yet. I wanted to run CI locally as I
suspect I need to fix more issues before it runs clean. But yes, we can tweak
what gets dumped into the stream in error case for release builds.
https://github.com/llvm/llvm-project/pull/105745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [mlir] [Support] Validate number of arguments passed to formatv() (PR #105745)
https://github.com/jurahul edited https://github.com/llvm/llvm-project/pull/105745 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Defer python init until ScriptInterpreter is created (PR #105757)
danobi wrote: Test failure looks unrelated. I see it in other PRs as well. https://github.com/llvm/llvm-project/pull/105757 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove limit on max memory read size (PR #105765)
@@ -102,7 +102,7 @@ let Definition = "target" in {
DefaultUnsignedValue<1024>,
Desc<"Maximum number of characters to show when using %s in summary
strings.">;
def MaxMemReadSize: Property<"max-memory-read-size", "UInt64">,
-DefaultUnsignedValue<1024>,
+DefaultUnsignedValue<4294967295>,
medismailben wrote:
suggestion: Either make it hex, or instead of providing a default value here,
initialize the CommandOption to UINT32_MAX
https://github.com/llvm/llvm-project/pull/105765
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
