[Lldb-commits] [PATCH] D126668: LLDB: Fix resolving nested template parameters
teemperor added a comment.
> I don't really have the full context here, but I am wondering if we shouldn't
> somehow take the DW_AT_declaration attribute into account here. It seems like
> that should give a more definitive answer as to whether we can expect to see
> a full set of template parameters or not.
I think that is actually a good approach. I think the current patch rejects
forward declarations (which is fine as we don't have the required information
in DWARF) and empty parameter packs (which is the edge case the original patch
fixed).
Example: this is currently rejected even though we have all the required
information:
template
struct X {};
int main() {
X x;
}
->
0x0059: DW_TAG_structure_type
DW_AT_calling_convention(DW_CC_pass_by_value)
DW_AT_name ("X")
DW_AT_byte_size (0x01)
DW_AT_decl_file
("/home/teemperor/test/someoneshouldreallypaymeforthis.cpp")
DW_AT_decl_line (2)
0x0062: DW_TAG_GNU_template_parameter_pack
DW_AT_name("T")
0x0067: DW_TAG_template_type_parameter
DW_AT_type (0x0052 "int")
0x006c: NULL
0x006d: NULL
0x006e: NULL
I think having a fake class with a weird identifiers that contains template
arguments is better than the missing arguments, so this looks in general good
to me.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126668/new/
https://reviews.llvm.org/D126668
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127667: [PATCH] [lldb] [llgs] Implement the vKill packet
mgorny created this revision.
mgorny added reviewers: labath, emaste, krytarowski, jingham.
Herald added a subscriber: arichardson.
Herald added a project: All.
mgorny requested review of this revision.
Implement the support for the vKill packet. This is the modern packet
used by the GDB Remote Serial Protocol to kill one of the debugged
processes. Unlike the `k` packet, it has well-defined semantics.
The `vKill` packet takes the PID of the process to kill, and always
replies with an `OK` reply (rather than the exit status, as LLGS does
for `k` packets at the moment). Additionally, unlike the `k` packet
it does not cause the connection to be terminated once the last process
is killed — the client needs to close it explicitly.
Sponsored by: The FreeBSD Foundation
https://reviews.llvm.org/D127667
Files:
lldb/include/lldb/Utility/StringExtractorGDBRemote.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/source/Utility/StringExtractorGDBRemote.cpp
lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
Index: lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
@@ -297,3 +297,61 @@
ret = self.expect_gdbremote_sequence()
self.assertEqual(set([ret["pid1"], ret["pid2"]]),
set([parent_pid, child_pid]))
+
+def vkill_test(self, kill_parent=False, kill_child=False):
+assert kill_parent or kill_child
+self.build()
+self.prep_debug_monitor_and_inferior(inferior_args=["fork"])
+self.add_qSupported_packets(["multiprocess+",
+ "fork-events+"])
+ret = self.expect_gdbremote_sequence()
+self.assertIn("fork-events+", ret["qSupported_response"])
+self.reset_test_sequence()
+
+# continue and expect fork
+self.test_sequence.add_log_lines([
+"read packet: $c#00",
+{"direction": "send", "regex": self.fork_regex.format("fork"),
+ "capture": self.fork_capture},
+], True)
+ret = self.expect_gdbremote_sequence()
+parent_pid = ret["parent_pid"]
+parent_tid = ret["parent_tid"]
+child_pid = ret["child_pid"]
+child_tid = ret["child_tid"]
+self.reset_test_sequence()
+
+exit_regex = "[$]X09;process:([0-9a-f]+)#.*"
+if kill_parent:
+self.test_sequence.add_log_lines([
+# kill the process
+"read packet: $vKill;{}#00".format(parent_pid),
+"send packet: $OK#00",
+], True)
+if kill_child:
+self.test_sequence.add_log_lines([
+# kill the process
+"read packet: $vKill;{}#00".format(child_pid),
+"send packet: $OK#00",
+], True)
+self.test_sequence.add_log_lines([
+# check child PID/TID
+"read packet: $Hgp{}.{}#00".format(child_pid, child_tid),
+"send packet: ${}#00".format("Eff" if kill_child else "OK"),
+# check parent PID/TID
+"read packet: $Hgp{}.{}#00".format(parent_pid, parent_tid),
+"send packet: ${}#00".format("Eff" if kill_parent else "OK"),
+], True)
+self.expect_gdbremote_sequence()
+
+@add_test_categories(["fork"])
+def test_vkill_child(self):
+self.vkill_test(kill_child=True)
+
+@add_test_categories(["fork"])
+def test_vkill_parent(self):
+self.vkill_test(kill_parent=True)
+
+@add_test_categories(["fork"])
+def test_vkill_both(self):
+self.vkill_test(kill_parent=True, kill_child=True)
Index: lldb/source/Utility/StringExtractorGDBRemote.cpp
===
--- lldb/source/Utility/StringExtractorGDBRemote.cpp
+++ lldb/source/Utility/StringExtractorGDBRemote.cpp
@@ -367,6 +367,8 @@
return eServerPacketType_vCont;
if (PACKET_MATCHES("vCont?"))
return eServerPacketType_vCont_actions;
+ if (PACKET_STARTS_WITH("vKill;"))
+return eServerPacketType_vKill;
if (PACKET_STARTS_WITH("vRun;"))
return eServerPacketType_vRun;
}
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#include "lldb/Core/Communication.h"
#include "lldb/Host/MainLoop.h"
@@ -96,6 +97,7 @@
std::unordered_map>
m_debugged_processes;
std::unique_ptr m_last_exited_process;
+ std::unordered_set m_vkilled_proce
[Lldb-commits] [PATCH] D127667: [PATCH] [lldb] [llgs] Implement the vKill packet
mgorny updated this revision to Diff 436441.
mgorny added a comment.
Remove leftover `exit_regex` from test.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127667/new/
https://reviews.llvm.org/D127667
Files:
lldb/include/lldb/Utility/StringExtractorGDBRemote.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/source/Utility/StringExtractorGDBRemote.cpp
lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
Index: lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemoteFork.py
@@ -297,3 +297,60 @@
ret = self.expect_gdbremote_sequence()
self.assertEqual(set([ret["pid1"], ret["pid2"]]),
set([parent_pid, child_pid]))
+
+def vkill_test(self, kill_parent=False, kill_child=False):
+assert kill_parent or kill_child
+self.build()
+self.prep_debug_monitor_and_inferior(inferior_args=["fork"])
+self.add_qSupported_packets(["multiprocess+",
+ "fork-events+"])
+ret = self.expect_gdbremote_sequence()
+self.assertIn("fork-events+", ret["qSupported_response"])
+self.reset_test_sequence()
+
+# continue and expect fork
+self.test_sequence.add_log_lines([
+"read packet: $c#00",
+{"direction": "send", "regex": self.fork_regex.format("fork"),
+ "capture": self.fork_capture},
+], True)
+ret = self.expect_gdbremote_sequence()
+parent_pid = ret["parent_pid"]
+parent_tid = ret["parent_tid"]
+child_pid = ret["child_pid"]
+child_tid = ret["child_tid"]
+self.reset_test_sequence()
+
+if kill_parent:
+self.test_sequence.add_log_lines([
+# kill the process
+"read packet: $vKill;{}#00".format(parent_pid),
+"send packet: $OK#00",
+], True)
+if kill_child:
+self.test_sequence.add_log_lines([
+# kill the process
+"read packet: $vKill;{}#00".format(child_pid),
+"send packet: $OK#00",
+], True)
+self.test_sequence.add_log_lines([
+# check child PID/TID
+"read packet: $Hgp{}.{}#00".format(child_pid, child_tid),
+"send packet: ${}#00".format("Eff" if kill_child else "OK"),
+# check parent PID/TID
+"read packet: $Hgp{}.{}#00".format(parent_pid, parent_tid),
+"send packet: ${}#00".format("Eff" if kill_parent else "OK"),
+], True)
+self.expect_gdbremote_sequence()
+
+@add_test_categories(["fork"])
+def test_vkill_child(self):
+self.vkill_test(kill_child=True)
+
+@add_test_categories(["fork"])
+def test_vkill_parent(self):
+self.vkill_test(kill_parent=True)
+
+@add_test_categories(["fork"])
+def test_vkill_both(self):
+self.vkill_test(kill_parent=True, kill_child=True)
Index: lldb/source/Utility/StringExtractorGDBRemote.cpp
===
--- lldb/source/Utility/StringExtractorGDBRemote.cpp
+++ lldb/source/Utility/StringExtractorGDBRemote.cpp
@@ -367,6 +367,8 @@
return eServerPacketType_vCont;
if (PACKET_MATCHES("vCont?"))
return eServerPacketType_vCont_actions;
+ if (PACKET_STARTS_WITH("vKill;"))
+return eServerPacketType_vKill;
if (PACKET_STARTS_WITH("vRun;"))
return eServerPacketType_vRun;
}
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#include "lldb/Core/Communication.h"
#include "lldb/Host/MainLoop.h"
@@ -96,6 +97,7 @@
std::unordered_map>
m_debugged_processes;
std::unique_ptr m_last_exited_process;
+ std::unordered_set m_vkilled_processes;
Communication m_stdio_communication;
MainLoop::ReadHandleUP m_stdio_handle_up;
@@ -123,6 +125,8 @@
PacketResult Handle_k(StringExtractorGDBRemote &packet);
+ PacketResult Handle_vKill(StringExtractorGDBRemote &packet);
+
PacketResult Handle_qProcessInfo(StringExtractorGDBRemote &packet);
PacketResult Handle_qC(StringExtractorGDBRemote &packet);
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRe
[Lldb-commits] [PATCH] D116136: [lldb] Add missing UTF-8 char basic type entries
This revision was automatically updated to reflect the committed changes. Closed by commit rG6d5b86f851a1: [lldb] Add missing UTF-8 char basic type entries (authored by ljmf00). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116136/new/ https://reviews.llvm.org/D116136 Files: lldb/bindings/python/python-extensions.swig lldb/docs/python_api_enums.rst Index: lldb/docs/python_api_enums.rst === --- lldb/docs/python_api_enums.rst +++ lldb/docs/python_api_enums.rst @@ -1017,9 +1017,9 @@ .. py:data:: eBasicTypeWChar .. py:data:: eBasicTypeSignedWChar .. py:data:: eBasicTypeUnsignedWChar -.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeChar16 .. py:data:: eBasicTypeChar32 +.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeShort .. py:data:: eBasicTypeUnsignedShort .. py:data:: eBasicTypeInt Index: lldb/bindings/python/python-extensions.swig === --- lldb/bindings/python/python-extensions.swig +++ lldb/bindings/python/python-extensions.swig @@ -565,6 +565,7 @@ if basic_type == eBasicTypeUnsignedWChar: return (True,False) if basic_type == eBasicTypeChar16: return (True,False) if basic_type == eBasicTypeChar32: return (True,False) +if basic_type == eBasicTypeChar8: return (True,False) if basic_type == eBasicTypeShort: return (True,True) if basic_type == eBasicTypeUnsignedShort: return (True,False) if basic_type == eBasicTypeInt: return (True,True) Index: lldb/docs/python_api_enums.rst === --- lldb/docs/python_api_enums.rst +++ lldb/docs/python_api_enums.rst @@ -1017,9 +1017,9 @@ .. py:data:: eBasicTypeWChar .. py:data:: eBasicTypeSignedWChar .. py:data:: eBasicTypeUnsignedWChar -.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeChar16 .. py:data:: eBasicTypeChar32 +.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeShort .. py:data:: eBasicTypeUnsignedShort .. py:data:: eBasicTypeInt Index: lldb/bindings/python/python-extensions.swig === --- lldb/bindings/python/python-extensions.swig +++ lldb/bindings/python/python-extensions.swig @@ -565,6 +565,7 @@ if basic_type == eBasicTypeUnsignedWChar: return (True,False) if basic_type == eBasicTypeChar16: return (True,False) if basic_type == eBasicTypeChar32: return (True,False) +if basic_type == eBasicTypeChar8: return (True,False) if basic_type == eBasicTypeShort: return (True,True) if basic_type == eBasicTypeUnsignedShort: return (True,False) if basic_type == eBasicTypeInt: return (True,True) ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6d5b86f - [lldb] Add missing UTF-8 char basic type entries
Author: Luís Ferreira Date: 2022-06-13T17:33:46Z New Revision: 6d5b86f851a1ee6475c767b8f94e3598cdd5a9fe URL: https://github.com/llvm/llvm-project/commit/6d5b86f851a1ee6475c767b8f94e3598cdd5a9fe DIFF: https://github.com/llvm/llvm-project/commit/6d5b86f851a1ee6475c767b8f94e3598cdd5a9fe.diff LOG: [lldb] Add missing UTF-8 char basic type entries D120690 introduced `eBasicTypeChar8` but missed proper documentation order. This also introduces the missing bindings data on Swig, which should correspond with the documented information. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D116136 Added: Modified: lldb/bindings/python/python-extensions.swig lldb/docs/python_api_enums.rst Removed: diff --git a/lldb/bindings/python/python-extensions.swig b/lldb/bindings/python/python-extensions.swig index b98b0d458f0c6..cb841af070ad6 100644 --- a/lldb/bindings/python/python-extensions.swig +++ b/lldb/bindings/python/python-extensions.swig @@ -565,6 +565,7 @@ def is_numeric_type(basic_type): if basic_type == eBasicTypeUnsignedWChar: return (True,False) if basic_type == eBasicTypeChar16: return (True,False) if basic_type == eBasicTypeChar32: return (True,False) +if basic_type == eBasicTypeChar8: return (True,False) if basic_type == eBasicTypeShort: return (True,True) if basic_type == eBasicTypeUnsignedShort: return (True,False) if basic_type == eBasicTypeInt: return (True,True) diff --git a/lldb/docs/python_api_enums.rst b/lldb/docs/python_api_enums.rst index 1c363381a11b2..6ae73df68c8ab 100644 --- a/lldb/docs/python_api_enums.rst +++ b/lldb/docs/python_api_enums.rst @@ -1017,9 +1017,9 @@ BasicType .. py:data:: eBasicTypeWChar .. py:data:: eBasicTypeSignedWChar .. py:data:: eBasicTypeUnsignedWChar -.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeChar16 .. py:data:: eBasicTypeChar32 +.. py:data:: eBasicTypeChar8 .. py:data:: eBasicTypeShort .. py:data:: eBasicTypeUnsignedShort .. py:data:: eBasicTypeInt ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 3222f95 - [LLDB][NativePDB] Convert backslash to slash when creating CU and filter out CU with no function in ResolveSymbolContext.
Author: Zequan Wu
Date: 2022-06-13T12:04:25-07:00
New Revision: 3222f95ea8c4de153f908c138cdec178e22acaf4
URL:
https://github.com/llvm/llvm-project/commit/3222f95ea8c4de153f908c138cdec178e22acaf4
DIFF:
https://github.com/llvm/llvm-project/commit/3222f95ea8c4de153f908c138cdec178e22acaf4.diff
LOG: [LLDB][NativePDB] Convert backslash to slash when creating CU and filter
out CU with no function in ResolveSymbolContext.
On Windows, when compile with -fdebug-compilation-dir which contains slash, the
source file path in PDB will look like "../tmp\file.cc" because the path
separator used is determined by target machine. Converting backslash to slash
helps lldb to find the CU in ResolveSymbolContext.
We want to filter out CU with no function in ResolveSymbolContext as a cpp file
will have two debug info modules in PDB if built with thinlto and one of them
is a skeleton with no function debug info.
Added:
Modified:
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 18fd7efb93e82..5c98ac38de6f7 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -449,7 +449,8 @@ SymbolFileNativePDB::CreateCompileUnit(const
CompilandIndexItem &cci) {
llvm::SmallString<64> source_file_name =
m_index->compilands().GetMainSourceFile(cci);
- FileSpec fs(source_file_name);
+ FileSpec fs(llvm::sys::path::convert_to_slash(
+ source_file_name, llvm::sys::path::Style::windows_backslash));
CompUnitSP cu_sp =
std::make_shared(m_objfile_sp->GetModule(), nullptr, fs,
@@ -1051,7 +1052,7 @@ uint32_t SymbolFileNativePDB::ResolveSymbolContext(
for (uint32_t cu_idx = 0, num_cus = GetNumCompileUnits(); cu_idx < num_cus;
++cu_idx) {
CompileUnit *cu = ParseCompileUnitAtIndex(cu_idx).get();
- if (!cu)
+ if (!cu && cu->GetNumFunctions() != 0)
continue;
bool file_spec_matches_cu_file_spec = FileSpec::Match(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] ae60869 - Minor fix to 3222f95ea8c4de153f908c138cdec178e22acaf4
Author: Zequan Wu
Date: 2022-06-13T12:06:07-07:00
New Revision: ae60869908db6e8f45b51bc35d983706e8a296ae
URL:
https://github.com/llvm/llvm-project/commit/ae60869908db6e8f45b51bc35d983706e8a296ae
DIFF:
https://github.com/llvm/llvm-project/commit/ae60869908db6e8f45b51bc35d983706e8a296ae.diff
LOG: Minor fix to 3222f95ea8c4de153f908c138cdec178e22acaf4
Added:
Modified:
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 5c98ac38de6f..84e535f2e0bc 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1052,7 +1052,7 @@ uint32_t SymbolFileNativePDB::ResolveSymbolContext(
for (uint32_t cu_idx = 0, num_cus = GetNumCompileUnits(); cu_idx < num_cus;
++cu_idx) {
CompileUnit *cu = ParseCompileUnitAtIndex(cu_idx).get();
- if (!cu && cu->GetNumFunctions() != 0)
+ if (!cu && cu->GetNumFunctions() == 0)
continue;
bool file_spec_matches_cu_file_spec = FileSpec::Match(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 98c2a85 - Minor fix to ae60869908db6e8f45b51bc35d983706e8a296ae
Author: Zequan Wu
Date: 2022-06-13T12:08:26-07:00
New Revision: 98c2a853eb5e8b0e855f6da935889309544f6d9b
URL:
https://github.com/llvm/llvm-project/commit/98c2a853eb5e8b0e855f6da935889309544f6d9b
DIFF:
https://github.com/llvm/llvm-project/commit/98c2a853eb5e8b0e855f6da935889309544f6d9b.diff
LOG: Minor fix to ae60869908db6e8f45b51bc35d983706e8a296ae
Added:
Modified:
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 84e535f2e0bc..1b6083c4869b 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1052,7 +1052,7 @@ uint32_t SymbolFileNativePDB::ResolveSymbolContext(
for (uint32_t cu_idx = 0, num_cus = GetNumCompileUnits(); cu_idx < num_cus;
++cu_idx) {
CompileUnit *cu = ParseCompileUnitAtIndex(cu_idx).get();
- if (!cu && cu->GetNumFunctions() == 0)
+ if (!cu || cu->GetNumFunctions() == 0)
continue;
bool file_spec_matches_cu_file_spec = FileSpec::Match(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127481: [LLDB][formatters] Add formatter for libc++'s std::span
This revision was automatically updated to reflect the committed changes.
Closed by commit rGea9ff9fac3a6: [LLDB][formatters] Add formatter for
libc++'s std::span (authored by aprantl).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127481/new/
https://reviews.llvm.org/D127481
Files:
lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/Makefile
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/main.cpp
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/main.cpp
@@ -0,0 +1,56 @@
+#include
+#include
+#include
+#include
+#include
+
+template
+void by_ref_and_ptr(std::span &ref, std::span *ptr) {
+ printf("Stop here to check by ref");
+ return;
+}
+
+int main() {
+ std::array numbers = {1, 12, 123, 1234, 12345};
+
+ using dynamic_string_span = std::span;
+
+ // Test span of ints
+
+ // Full view of numbers with static extent
+ std::span numbers_span = numbers;
+
+ printf("break here");
+
+ by_ref_and_ptr(numbers_span, &numbers_span);
+
+ // Test spans of strings
+ std::vector strings{"goofy", "is", "smart", "!!!"};
+ strings.reserve(strings.size() + 1);
+
+ // Partial view of strings with dynamic extent
+ dynamic_string_span strings_span{std::span{strings}.subspan(2)};
+
+ auto strings_span_it = strings_span.begin();
+
+ printf("break here");
+
+ // Vector size doesn't increase, span should
+ // print unchanged and the strings_span_it
+ // remains valid
+ strings.emplace_back("???");
+
+ printf("break here");
+
+ // Now some empty spans
+ std::span static_zero_span;
+ std::span dynamic_zero_span;
+
+ // Multiple spans
+ std::array span_arr{strings_span, strings_span};
+ std::span, 2> nested = span_arr;
+
+ printf("break here");
+
+ return 0; // break here
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
@@ -0,0 +1,153 @@
+"""
+Test lldb data formatter subsystem for std::span
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class LibcxxSpanDataFormatterTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def findVariable(self, name):
+var = self.frame().FindVariable(name)
+self.assertTrue(var.IsValid())
+return var
+
+def check_size(self, var_name, size):
+var = self.findVariable(var_name)
+self.assertEqual(var.GetNumChildren(), size)
+
+def check_numbers(self, var_name):
+"""Helper to check that data formatter sees contents of std::span correctly"""
+
+expectedSize = 5
+self.check_size(var_name, expectedSize)
+
+self.expect_expr(
+var_name, result_type=f'std::span',
+result_summary=f'size={expectedSize}',
+result_children=[
+ValueCheck(name='[0]', value='1'),
+ValueCheck(name='[1]', value='12'),
+ValueCheck(name='[2]', value='123'),
+ValueCheck(name='[3]', value='1234'),
+ValueCheck(name='[4]', value='12345')
+])
+
+# check access-by-index
+self.expect_var_path(f'{var_name}[0]', type='int', value='1')
+self.expect_var_path(f'{var_name}[1]', type='int', value='12')
+self.expect_var_path(f'{var_name}[2]', type='int', value='123')
+self.expect_var_path(f'{var_name}[3]', type='int', value='1234')
+self.expect_var_path(f'{var_name}[4]', type='int', value='12345')
+
+@add_test_categories(['libc++'])
+@skipIf(compiler='clang', compiler_version=['<', '11.0'])
+def test_with_run_command(self):
+"""Test that std::span variables are formatted correctly when printed."""
+self.build()
+(self.target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, 'break here', lldb.SBFileSpec('main.cpp', False))
+
+lldbutil.continue_to_breakpoint(process, bkpt)
+
+# std::span of std::array with extents known at compile-time
+self.check_numbers('numbers_span')
+
+# check access to synthetic children for static spans
+
[Lldb-commits] [lldb] ea9ff9f - [LLDB][formatters] Add formatter for libc++'s std::span
Author: Adrian Prantl
Date: 2022-06-13T12:59:38-07:00
New Revision: ea9ff9fac3a6ea77b488081dd9faabc8fe334b46
URL:
https://github.com/llvm/llvm-project/commit/ea9ff9fac3a6ea77b488081dd9faabc8fe334b46
DIFF:
https://github.com/llvm/llvm-project/commit/ea9ff9fac3a6ea77b488081dd9faabc8fe334b46.diff
LOG: [LLDB][formatters] Add formatter for libc++'s std::span
This patch adds a libcxx formatter for std::span. The
implementation is based on the libcxx formatter for
std::vector. The main difference is the fact that
std::span conditionally has a __size member based
on whether it has a static or dynamic extent.
Example output of formatted span:
(std::span) $0 = size=6 {
[0] = 0
[1] = 1
[2] = 2
[3] = 3
[4] = 4
[5] = 5
}
The second template parameter here is actually std::dynamic_extent,
but the type declaration we get back from the TypeSystemClang is the
actual value (which in this case is (size_t)-1). This is consistent
with diagnostics from clang, which doesn't desugar this value either.
E.g.,:
span.cpp:30:31: error: implicit instantiation of undefined template
'Undefined>'
Testing:
Added API-tests
Confirmed manually using LLDB cli that printing spans works in various scenarios
Patch by Michael Buch!
Differential Revision: https://reviews.llvm.org/D127481
Added:
lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/Makefile
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/main.cpp
Modified:
lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
Removed:
diff --git a/lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
b/lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
index 125c12cfe4a5..80135daf4cfd 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
+++ b/lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
@@ -11,6 +11,7 @@ add_lldb_library(lldbPluginCPlusPlusLanguage PLUGIN
LibCxxList.cpp
LibCxxMap.cpp
LibCxxQueue.cpp
+ LibCxxSpan.cpp
LibCxxTuple.cpp
LibCxxUnorderedMap.cpp
LibCxxVariant.cpp
diff --git a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
index 08b6d89e55f7..82f825871593 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -756,6 +756,12 @@ static void LoadLibCxxFormatters(lldb::TypeCategoryImplSP
cpp_category_sp) {
lldb_private::formatters::LibcxxAtomicSyntheticFrontEndCreator,
"libc++ std::atomic synthetic children",
ConstString("^std::__[[:alnum:]]+::atomic<.+>$"), stl_synth_flags, true);
+ AddCXXSynthetic(
+ cpp_category_sp,
+ lldb_private::formatters::LibcxxStdSpanSyntheticFrontEndCreator,
+ "libc++ std::span synthetic children",
+ ConstString("^std::__[[:alnum:]]+::span<.+>(( )?&)?$"), stl_deref_flags,
+ true);
cpp_category_sp->GetRegexTypeSyntheticsContainer()->Add(
RegularExpression("^(std::__[[:alnum:]]+::)deque<.+>(( )?&)?$"),
@@ -869,6 +875,11 @@ static void LoadLibCxxFormatters(lldb::TypeCategoryImplSP
cpp_category_sp) {
"libc++ std::variant summary provider",
ConstString("^std::__[[:alnum:]]+::variant<.+>(( )?&)?$"),
stl_summary_flags, true);
+ AddCXXSummary(cpp_category_sp,
+lldb_private::formatters::LibcxxContainerSummaryProvider,
+"libc++ std::span summary provider",
+ConstString("^std::__[[:alnum:]]+::span<.+>(( )?&)?$"),
+stl_summary_flags, true);
stl_summary_flags.SetSkipPointers(true);
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
index 0f166ae24912..b4e789e65b51 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
@@ -74,6 +74,10 @@
LibcxxVectorBoolSyntheticFrontEndCreator(CXXSyntheticChildren *,
bool LibcxxContainerSummaryProvider(ValueObject &valobj, Stream &stream,
const TypeSummaryOptions &options);
+/// Formatter for libc++ std::span<>.
+bool LibcxxSpanSummaryProvider(ValueObject &valobj, Stream &stream,
+ const TypeSummaryOptions &options);
+
class LibCxxMapIteratorSyntheticFrontEnd : public SyntheticChildrenFrontEnd {
public:
LibCxxMapIteratorSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp);
@@ -193,6 +197,10 @@ SyntheticChildrenFrontEnd *
LibcxxVariantFrontEndCreator(CXXSyntheticChildren *,
[Lldb-commits] [lldb] 602a951 - Partially revert 3222f95ea8c4de153f908c138cdec178e22acaf4
Author: Zequan Wu
Date: 2022-06-13T13:29:32-07:00
New Revision: 602a951bfe3401f81e2759089b14a549c39dc394
URL:
https://github.com/llvm/llvm-project/commit/602a951bfe3401f81e2759089b14a549c39dc394
DIFF:
https://github.com/llvm/llvm-project/commit/602a951bfe3401f81e2759089b14a549c39dc394.diff
LOG: Partially revert 3222f95ea8c4de153f908c138cdec178e22acaf4
Added:
Modified:
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 1b6083c4869b5..891ee15af9477 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1052,7 +1052,7 @@ uint32_t SymbolFileNativePDB::ResolveSymbolContext(
for (uint32_t cu_idx = 0, num_cus = GetNumCompileUnits(); cu_idx < num_cus;
++cu_idx) {
CompileUnit *cu = ParseCompileUnitAtIndex(cu_idx).get();
- if (!cu || cu->GetNumFunctions() == 0)
+ if (!cu)
continue;
bool file_spec_matches_cu_file_spec = FileSpec::Match(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127702: Support logpoints in lldb-vscode
yinghuitan created this revision.
yinghuitan added reviewers: clayborg, labath, jingham, jdoerfert, JDevlieghere,
aadsm, kusmour.
Herald added a project: All.
yinghuitan requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
This patch implements VSCode DAP logpoints feature (also called tracepoint
in other VS debugger).
This will provide a convenient way for user to do printf style logging
debugging without pausing debuggee.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D127702
Files:
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_logpoints.py
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
lldb/test/API/tools/lldb-vscode/breakpoint/main.cpp
lldb/tools/lldb-vscode/BreakpointBase.cpp
lldb/tools/lldb-vscode/BreakpointBase.h
lldb/tools/lldb-vscode/FunctionBreakpoint.cpp
lldb/tools/lldb-vscode/SourceBreakpoint.cpp
lldb/tools/lldb-vscode/lldb-vscode.cpp
Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1532,6 +1532,8 @@
body.try_emplace("supportsLoadedSourcesRequest", false);
// The debug adapter supports sending progress reporting events.
body.try_emplace("supportsProgressReporting", true);
+ // The debug adapter supports 'logMessage' in breakpoint.
+ body.try_emplace("supportsLogPoints", true);
response.try_emplace("body", std::move(body));
g_vsc.SendJSON(llvm::json::Value(std::move(response)));
@@ -2079,9 +2081,10 @@
}
}
// At this point the breakpoint is new
-src_bp.SetBreakpoint(path.data());
-AppendBreakpoint(src_bp.bp, response_breakpoints, path, src_bp.line);
-g_vsc.source_breakpoints[path][src_bp.line] = std::move(src_bp);
+g_vsc.source_breakpoints[path][src_bp.line] = src_bp;
+SourceBreakpoint &new_bp = g_vsc.source_breakpoints[path][src_bp.line];
+new_bp.SetBreakpoint(path.data());
+AppendBreakpoint(new_bp.bp, response_breakpoints, path, new_bp.line);
}
}
}
@@ -2304,10 +2307,11 @@
// Any breakpoints that are left in "request_bps" are breakpoints that
// need to be set.
for (auto &pair : request_bps) {
-pair.second.SetBreakpoint();
// Add this breakpoint info to the response
-AppendBreakpoint(pair.second.bp, response_breakpoints);
g_vsc.function_breakpoints[pair.first()] = std::move(pair.second);
+FunctionBreakpoint &new_bp = g_vsc.function_breakpoints[pair.first()];
+new_bp.SetBreakpoint();
+AppendBreakpoint(new_bp.bp, response_breakpoints);
}
llvm::json::Object body;
Index: lldb/tools/lldb-vscode/SourceBreakpoint.cpp
===
--- lldb/tools/lldb-vscode/SourceBreakpoint.cpp
+++ lldb/tools/lldb-vscode/SourceBreakpoint.cpp
@@ -24,6 +24,8 @@
SetCondition();
if (!hitCondition.empty())
SetHitCondition();
+ if (!logMessage.empty())
+SetLogMessage();
}
} // namespace lldb_vscode
Index: lldb/tools/lldb-vscode/FunctionBreakpoint.cpp
===
--- lldb/tools/lldb-vscode/FunctionBreakpoint.cpp
+++ lldb/tools/lldb-vscode/FunctionBreakpoint.cpp
@@ -25,6 +25,8 @@
SetCondition();
if (!hitCondition.empty())
SetHitCondition();
+ if (!logMessage.empty())
+SetLogMessage();
}
} // namespace lldb_vscode
Index: lldb/tools/lldb-vscode/BreakpointBase.h
===
--- lldb/tools/lldb-vscode/BreakpointBase.h
+++ lldb/tools/lldb-vscode/BreakpointBase.h
@@ -13,6 +13,7 @@
#include "lldb/API/SBBreakpoint.h"
#include "llvm/Support/JSON.h"
#include
+#include
namespace lldb_vscode {
@@ -27,6 +28,8 @@
// (stop) but log the message instead. Expressions within {} are
// interpolated.
std::string logMessage;
+ std::vector rawTextMessages;
+ std::vector evalExpressions;
// The LLDB breakpoint associated wit this source breakpoint
lldb::SBBreakpoint bp;
@@ -35,8 +38,12 @@
void SetCondition();
void SetHitCondition();
+ void SetLogMessage();
void UpdateBreakpoint(const BreakpointBase &request_bp);
static const char *GetBreakpointLabel();
+ static bool BreakpointHitCallback(void *baton, lldb::SBProcess &process,
+lldb::SBThread &thread,
+lldb::SBBreakpointLocation &location);
};
} // namespace lldb_vscode
Index: lldb/tools/lldb-vscode/BreakpointBase.cpp
===
--- lldb/tools/lldb-vscode/BreakpointBase.cpp
+++ lldb/tools/lldb-vscode/BreakpointBase.cpp
@@ -7,6 +7,7 @@
//==
[Lldb-commits] [PATCH] D127702: Support logpoints in lldb-vscode
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.
Comment at:
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_logpoints.py:60
+[loop_line, after_loop_line],
+[{'logMessage': logMessage}, {}]
+)
Any reason we have an empty dictionary at the end here?
Comment at:
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_logpoints.py:120
+[loop_line, after_loop_line],
+[{'logMessage': logMessage}, {}]
+)
Any reason we have an empty dictionary at the end here?
Comment at: lldb/tools/lldb-vscode/BreakpointBase.cpp:46
+ // ascending order without any overlap between them.
+ std::vector> matched_curly_braces_ranges;
+
Might be easier to use a std::map here instead of a vector of pairs?
Comment at: lldb/tools/lldb-vscode/BreakpointBase.cpp:91
+assert(curly_braces_range.first >= last_raw_text_start);
+size_t raw_text_len = curly_braces_range.first - last_raw_text_start;
+rawTextMessages.emplace_back(llvm::StringRef(
If the is a '{' at the start of the string, this code seems like it pushes an
empty string. this must be needed because we have two vectors (rawTextMessages
and evalExpressions)?
Comment at: lldb/tools/lldb-vscode/BreakpointBase.cpp:124
+
+ for (size_t i = 0; i < bp->evalExpressions.size(); ++i) {
+const llvm::StringRef &expr = bp->evalExpressions[i];
If we use a single vector of LogMessagePart objects, this code becomes simpler:
```
for (const LogMessagePart &part: bp->logMessageParts) {
if (part.is_expr) {
lldb::SBValue value = frame.EvaluateExpression(part.text.str().c_str());
const char *expr_result = value.GetValue();
if (expr_result)
output += expr_result;
} else {
output += part.text.str();
}
}
Comment at: lldb/tools/lldb-vscode/BreakpointBase.cpp:128
+lldb::SBValue value = frame.EvaluateExpression(expr.str().c_str());
+output += value.GetValue();
+output += bp->rawTextMessages[i + 1];
This will crash if "value.GetValue()" returns NULL.
Comment at: lldb/tools/lldb-vscode/BreakpointBase.h:31-32
std::string logMessage;
+ std::vector rawTextMessages;
+ std::vector evalExpressions;
// The LLDB breakpoint associated wit this source breakpoint
How do we know what order to emit things with here between "rawTextMessages"
and "evalExpressions" in the breakpoint hit callback?
Comment at: lldb/tools/lldb-vscode/BreakpointBase.h:31-32
std::string logMessage;
+ std::vector rawTextMessages;
+ std::vector evalExpressions;
// The LLDB breakpoint associated wit this source breakpoint
clayborg wrote:
> How do we know what order to emit things with here between "rawTextMessages"
> and "evalExpressions" in the breakpoint hit callback?
Seems like it would be easier to understand the code if we used:
```
struct LogMessagePart {
llvm::StringRef text;
bool is_expr;
};
std::vector logMessageParts;
```
Right now you have two arrays and it isn't clear that each of these arrays must
be the same size, or which one would be emitted first.
Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:2084-2087
+g_vsc.source_breakpoints[path][src_bp.line] = src_bp;
+SourceBreakpoint &new_bp = g_vsc.source_breakpoints[path][src_bp.line];
+new_bp.SetBreakpoint(path.data());
+AppendBreakpoint(new_bp.bp, response_breakpoints, path, new_bp.line);
Why was this changed? I seemed clearer before this change and I can't see
anything that is different here?
Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:2312-2314
+FunctionBreakpoint &new_bp = g_vsc.function_breakpoints[pair.first()];
+new_bp.SetBreakpoint();
+AppendBreakpoint(new_bp.bp, response_breakpoints);
Why was this changed? Revert?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127702/new/
https://reviews.llvm.org/D127702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127702: Support logpoints in lldb-vscode
clayborg added inline comments. Comment at: lldb/tools/lldb-vscode/BreakpointBase.cpp:126 +const llvm::StringRef &expr = bp->evalExpressions[i]; +// TODO: try local variables first. +lldb::SBValue value = frame.EvaluateExpression(expr.str().c_str()); I would definitely try an local variable paths first via: ``` lldb::SBValue value = frame.GetValueForVariablePath(part.text.str().c_str(), lldb::eDynamicDontRunTarget); ``` before doing the evaluate expression due to performance which will be important in this case. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127702/new/ https://reviews.llvm.org/D127702 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127605: [lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath
aprantl accepted this revision. aprantl added a comment. This revision is now accepted and ready to land. This is good, but it also illustrates how the strings "->" and ".'" should actually come from the typesystem and not be hardcoded. We're just lucky that all languages have a "." operator. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127605/new/ https://reviews.llvm.org/D127605 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127605: [lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath
aprantl added a comment. More elegant would be to just add an API to TypeSystem to get the operator to access ivars. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127605/new/ https://reviews.llvm.org/D127605 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D127605: [lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath
kastiglione added a comment. > This is good, but it also illustrates how the strings "->" and ".'" should > actually come from the typesystem and not be hardcoded. We're just lucky that > all languages have a "." operator. > > More elegant would be to just add an API to TypeSystem to get the operator to > access ivars. Initially I was thinking along these lines. But I became less sure. The "variable expression path" syntax is C-like but independent of the source language. For example, in Swift, there is no `->`. So my rhetorical question is, should the `Language` or `TypeSystem`, etc, know about "variable expression path" syntax, as you suggest? Or should we rely on there being a shared subset between source language and variable expression path syntax, and allow the two subsystems to speak think they're speaking the same language even though we know they're each actually speaking a different but somewhat compatible language (source vs variable expression path). I decided to keep the `->`/`.` choice inside `GetValueForVariableExpressionPath` because I feel that kind of logic belongs closer to other variable expression path code. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127605/new/ https://reviews.llvm.org/D127605 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 926a7ec - [lldb] Fix TCPSocket::Connect when getaddrinfo returns multiple addrs
Author: Pavel Labath
Date: 2022-06-14T08:49:02+02:00
New Revision: 926a7ecdc8b21f01b06a1db78bdd81f1dacaad61
URL:
https://github.com/llvm/llvm-project/commit/926a7ecdc8b21f01b06a1db78bdd81f1dacaad61
DIFF:
https://github.com/llvm/llvm-project/commit/926a7ecdc8b21f01b06a1db78bdd81f1dacaad61.diff
LOG: [lldb] Fix TCPSocket::Connect when getaddrinfo returns multiple addrs
TCPSocket::Connect() calls SocketAddress::GetAddressInfo() and tries to
connect any of them (in a for loop).
This used to work before commit 4f6d3a376c9f("[LLDB] Fix setting of
success in Socket::Close()") https://reviews.llvm.org/D116768.
As a side effect of that commit, TCPSocket can only connect to the first
address returned by SocketAddress::GetAddressInfo().
1. If the attempt to connect to the first address fails,
TCPSocket::Connect(), calls CLOSE_SOCKET(GetNativeSocket()), which
closes the fd, but DOES NOT set m_socket to kInvalidSocketValue.
2. On the second attempt, TCPSocket::CreateSocket() calls
Socket::Close().
3. Socket::Close() proceeds, because IsValid() is true (m_socket was not
reset on step 1).
4. Socket::Close() calls ::close(m_socket), which fails
5. Since commit 4f6d3a376c9f("[LLDB] Fix setting of success in
Socket::Close()"), this is error is detected. Socket::Close() returns
an error.
6. TCPSocket::CreateSocket() therefore returns an error.
7. TCPSocket::Connect() detects the error and continues, skipping the
second (and the third, fourth...) address.
This commit fixes the problem by changing step 1: by calling
Socket::Close, instead of directly calling close(m_socket), m_socket is
also se to kInvalidSocketValue. On step 3, Socket::Close() is going to
return immediately and, on step 6, TCPSocket::CreateSocket() does not
fail.
How to reproduce this problem:
On my system, getaddrinfo() resolves "localhost" to "::1" (first) and to
"127.0.0.1" (second).
Start a gdbserver that only listens on 127.0.0.1:
```
gdbserver 127.0.0.1:2159 /bin/cat
Process /bin/cat created; pid = 2146709
Listening on port 2159
```
Start lldb and make it connect to "localhost:2159"
```
./bin/lldb
(lldb) gdb-remote localhost:2159
```
Before 4f6d3a376c9f("[LLDB] Fix setting of success in Socket::Close()"),
this used to work. After that commit, it stopped working. This commit
fixes the problem.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D126702
Added:
Modified:
lldb/source/Host/common/TCPSocket.cpp
Removed:
diff --git a/lldb/source/Host/common/TCPSocket.cpp
b/lldb/source/Host/common/TCPSocket.cpp
index 46d97ad470e4f..eabc9fef8a661 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -170,7 +170,7 @@ Status TCPSocket::Connect(llvm::StringRef name) {
if (-1 == llvm::sys::RetryAfterSignal(-1, ::connect, GetNativeSocket(),
&address.sockaddr(),
address.GetLength())) {
- CLOSE_SOCKET(GetNativeSocket());
+ Close();
continue;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D126702: [lldb] Fix TCPSocket::Connect when getaddrinfo returns multiple addrs
This revision was automatically updated to reflect the committed changes.
Closed by commit rG926a7ecdc8b2: [lldb] Fix TCPSocket::Connect when getaddrinfo
returns multiple addrs (authored by labath).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126702/new/
https://reviews.llvm.org/D126702
Files:
lldb/source/Host/common/TCPSocket.cpp
Index: lldb/source/Host/common/TCPSocket.cpp
===
--- lldb/source/Host/common/TCPSocket.cpp
+++ lldb/source/Host/common/TCPSocket.cpp
@@ -170,7 +170,7 @@
if (-1 == llvm::sys::RetryAfterSignal(-1, ::connect, GetNativeSocket(),
&address.sockaddr(),
address.GetLength())) {
- CLOSE_SOCKET(GetNativeSocket());
+ Close();
continue;
}
Index: lldb/source/Host/common/TCPSocket.cpp
===
--- lldb/source/Host/common/TCPSocket.cpp
+++ lldb/source/Host/common/TCPSocket.cpp
@@ -170,7 +170,7 @@
if (-1 == llvm::sys::RetryAfterSignal(-1, ::connect, GetNativeSocket(),
&address.sockaddr(),
address.GetLength())) {
- CLOSE_SOCKET(GetNativeSocket());
+ Close();
continue;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D126702: [lldb] Fix TCPSocket::Connect when getaddrinfo returns multiple addrs
labath added a comment. Committed now, thanks for the patch. I'm not sure if there will be another 14.x release, but you can file a bug to track this, if there happens to be one. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126702/new/ https://reviews.llvm.org/D126702 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
