[Lldb-commits] [lldb] 1e58e3e - [lldb][trace] Fix some minor bugs in the call tree

2022-10-19 Thread Walter Erquinigo via lldb-commits 

Author: Walter Erquinigo
Date: 2022-10-19T00:44:48-07:00
New Revision: 1e58e3e1e96096f2d8db759555cf5132c5860519

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

LOG: [lldb][trace] Fix some minor bugs in the call tree

- We weren't truncating the output files
- We weren't considering the case in which we couldn't disassembly an
instruction.

Added: 


Modified: 
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Target/TraceDumper.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index 414acfb23ef9d..bfe85043f3703 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -2199,7 +2199,8 @@ class CommandObjectTraceDumpFunctionCalls : public 
CommandObjectParsed {
 llvm::Optional out_file;
 if (m_options.m_output_file) {
   out_file.emplace(m_options.m_output_file->GetPath().c_str(),
-   File::eOpenOptionWriteOnly | 
File::eOpenOptionCanCreate);
+   File::eOpenOptionWriteOnly | File::eOpenOptionCanCreate 
|
+   File::eOpenOptionTruncate);
 }
 
 m_options.m_dumper_options.forwards = true;
@@ -2395,7 +2396,8 @@ class CommandObjectTraceDumpInstructions : public 
CommandObjectParsed {
 llvm::Optional out_file;
 if (m_options.m_output_file) {
   out_file.emplace(m_options.m_output_file->GetPath().c_str(),
-   File::eOpenOptionWriteOnly | 
File::eOpenOptionCanCreate);
+   File::eOpenOptionWriteOnly | File::eOpenOptionCanCreate 
|
+   File::eOpenOptionTruncate);
 }
 
 if (m_options.m_continue && !m_last_id) {

diff  --git a/lldb/source/Target/TraceDumper.cpp 
b/lldb/source/Target/TraceDumper.cpp
index 7a5214d7cff0f..268dc039365f7 100644
--- a/lldb/source/Target/TraceDumper.cpp
+++ b/lldb/source/Target/TraceDumper.cpp
@@ -799,9 +799,14 @@ static TraceDumper::FunctionCall 
&AppendInstructionToFunctionCallForest(
   }
   // Now we are in a 
diff erent symbol. Let's see if this is a return or a
   // call
-  switch (last_function_call->GetLastTracedSegment()
-  .GetLastInstructionSymbolInfo()
-  .instruction->GetControlFlowKind(&exe_ctx)) {
+  const InstructionSP &insn = last_function_call->GetLastTracedSegment()
+  .GetLastInstructionSymbolInfo()
+  .instruction;
+  InstructionControlFlowKind insn_kind =
+  insn ? insn->GetControlFlowKind(&exe_ctx)
+   : eInstructionControlFlowKindOther;
+
+  switch (insn_kind) {
   case lldb::eInstructionControlFlowKindCall:
   case lldb::eInstructionControlFlowKindFarCall: {
 // This is a regular call



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

[Lldb-commits] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

2022-10-19 Thread David Blaikie via Phabricator via lldb-commits 
dblaikie added a comment.

In D136011#3862150 , @labath wrote:

> In D136011#3860637 , @dblaikie 
> wrote:
>
>> I think the place where this will go wrong is in terms of how lldb renders 
>> `char` values on non-default-char-signedness programs (it'll render them as 
>> the default-char-signedness, which might be confusing to a user - since 
>> they'll be looking at literals, etc, that are the other signedness) and how 
>> lldb will interpret char literals (though that'll already be wrong - since 
>> the literals are already being parsed with the default-char-signedness, I 
>> think).
>
> Yes, I'm pretty sure that will happen. OTOH, I don't think there's any value 
> to fix this in a completely satisfactory way. Like, if the whole program was 
> consistently with the non-default signedness, we could try to detect it and 
> then configure the internal AST defaults accordingly. But that's hard to 
> detect, and I'd be surprised if most programs are completely homogeneous like 
> this.
>
> So, overall, I quite like this fix.

Yeah, this line of reasoning (non-homogenaeity) is one I'm on board with, 
thanks for the framing. Basically I/we can think of the debugger's expression 
context as some code that's compiled with the default char signedness always. 
Since char signedness isn't part of the ABI, bits of the program can be built 
with one and bits with the other - and the debugger is just a bit that's built 
with the default.

Works for me. (though lldb's sufficiently out of my wheelhouse I'll leave it to 
others to approve)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136011/new/

https://reviews.llvm.org/D136011

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

[Lldb-commits] [PATCH] D136114: [lldb] Allow SymbolFileDWARFDebugMap to register multiple compile units

2022-10-19 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

LGTM, with two tiny new suggestions.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h:179
+/// The compile units that an object file contains.
+llvm::SmallVector compile_units_sps;
+/// A map from the compile unit ID to its index in the vector.

IIUC, the common case is 1 unit (clang), 2 units (swift), n units (lto). Should 
we reserve `2` instead of one to cover the majority of use-cases?



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h:181
+/// A map from the compile unit ID to its index in the vector.
+llvm::SmallDenseMap id_to_index_map;
 uint32_t first_symbol_index = UINT32_MAX;

nit: I think we should use the same size as above 
`llvm::SmallDenseMap`, just to keep them in sync?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136114/new/

https://reviews.llvm.org/D136114

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

[Lldb-commits] [lldb] d765664 - [lldb] Add matching based on Python callbacks for data formatters.

2022-10-19 Thread Jorge Gorbe Moya via lldb-commits 

Author: Jorge Gorbe Moya
Date: 2022-10-19T12:53:38-07:00
New Revision: d76566417e592cfac9c710f82575473b1b4a9285

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

LOG: [lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The new method
allows users to specify the name of a Python callback function that
takes a `SBType` object and decides whether the type is a match or not.

Here is an overview of the changes performed:

- Add a new `eFormatterMatchCallback` matching type, and logic to handle
  it in `TypeMatcher` and `SBTypeNameSpecifier`.

- Extend `FormattersMatchCandidate` instances with a pointer to the
  current `ScriptInterpreter` and the `TypeImpl` corresponding to the
  candidate type, so we can run registered callbacks and pass the type
  to them. All matcher search functions now receive a
  `FormattersMatchCandidate` instead of a type name.

- Add some glue code to ScriptInterpreterPython and the SWIG bindings to
  allow calling a formatter matching callback. Most of this code is
  modeled after the equivalent code for watchpoint callback functions.

- Add an API test for the new callback-based matching feature.

For more context, please check the RFC thread where this feature was
originally discussed:
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11

Differential Revision: https://reviews.llvm.org/D135648

Added: 
lldb/test/API/functionalities/data-formatter/callback-matching/Makefile

lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py

lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
lldb/test/API/functionalities/data-formatter/callback-matching/main.cpp

Modified: 
lldb/bindings/python/python-swigsafecast.swig
lldb/bindings/python/python-wrapper.swig
lldb/include/lldb/API/SBType.h
lldb/include/lldb/DataFormatters/DataVisualization.h
lldb/include/lldb/DataFormatters/FormatClasses.h
lldb/include/lldb/DataFormatters/FormatManager.h
lldb/include/lldb/DataFormatters/FormattersContainer.h
lldb/include/lldb/DataFormatters/TypeCategory.h
lldb/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/include/lldb/Target/Language.h
lldb/include/lldb/lldb-enumerations.h
lldb/source/API/SBTypeNameSpecifier.cpp
lldb/source/Commands/CommandObjectType.cpp
lldb/source/DataFormatters/DataVisualization.cpp
lldb/source/DataFormatters/FormatManager.cpp
lldb/source/DataFormatters/TypeCategory.cpp
lldb/source/DataFormatters/TypeCategoryMap.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
lldb/source/Target/Language.cpp
lldb/unittests/DataFormatter/FormattersContainerTest.cpp
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Removed: 




diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
b/lldb/bindings/python/python-swigsafecast.swig
index eb684133abef..aa5e8e50a2d9 100644
--- a/lldb/bindings/python/python-swigsafecast.swig
+++ b/lldb/bindings/python/python-swigsafecast.swig
@@ -97,6 +97,10 @@ PythonObject ToSWIGWrapper(lldb::ExecutionContextRefSP 
ctx_sp) {
   SWIGTYPE_p_lldb__SBExecutionContext);
 }
 
+PythonObject ToSWIGWrapper(lldb::TypeImplSP type_impl_sp) {
+  return ToSWIGHelper(new lldb::SBType(type_impl_sp), SWIGTYPE_p_lldb__SBType);
+}
+
 PythonObject ToSWIGWrapper(const TypeSummaryOptions &summary_options) {
   return ToSWIGHelper(new lldb::SBTypeSummaryOptions(summary_options),
   SWIGTYPE_p_lldb__SBTypeSummaryOptions);

diff  --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index 626fc47bebb9..adac8a405ab9 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -90,6 +90,32 @@ bool lldb_private::LLDBSwigPythonWatchpointCallbackFunction(
   return stop_at_watchpoint;
 }
 
+// This function is called by
+// ScriptInterpreterPython::FormatterMatchingCallbackFunction and it's used 
when
+// a data formatter provides the name of a callback to inspect a candidate type
+// before considering a match.
+bool lldb_private::LLDBSwigPythonFormatterCallbackFunction(
+const char *python_function_name, const char *session_dictionary_name,
+lldb:

[Lldb-commits] [PATCH] D135648: [lldb] Add matching based on Python callbacks for data formatters.

2022-10-19 Thread Jorge Gorbe Moya via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
jgorbe marked 2 inline comments as done.
Closed by commit rGd76566417e59: [lldb] Add matching based on Python callbacks 
for data formatters. (authored by jgorbe).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135648/new/

https://reviews.llvm.org/D135648

Files:
  lldb/bindings/python/python-swigsafecast.swig
  lldb/bindings/python/python-wrapper.swig
  lldb/include/lldb/API/SBType.h
  lldb/include/lldb/DataFormatters/DataVisualization.h
  lldb/include/lldb/DataFormatters/FormatClasses.h
  lldb/include/lldb/DataFormatters/FormatManager.h
  lldb/include/lldb/DataFormatters/FormattersContainer.h
  lldb/include/lldb/DataFormatters/TypeCategory.h
  lldb/include/lldb/DataFormatters/TypeCategoryMap.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/include/lldb/Target/Language.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/source/API/SBTypeNameSpecifier.cpp
  lldb/source/Commands/CommandObjectType.cpp
  lldb/source/DataFormatters/DataVisualization.cpp
  lldb/source/DataFormatters/FormatManager.cpp
  lldb/source/DataFormatters/TypeCategory.cpp
  lldb/source/DataFormatters/TypeCategoryMap.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  lldb/source/Target/Language.cpp
  lldb/test/API/functionalities/data-formatter/callback-matching/Makefile
  
lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
  
lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
  lldb/test/API/functionalities/data-formatter/callback-matching/main.cpp
  lldb/unittests/DataFormatter/FormattersContainerTest.cpp
  lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Index: lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
===
--- lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -67,6 +67,12 @@
   return false;
 }
 
+bool lldb_private::LLDBSwigPythonFormatterCallbackFunction(
+const char *python_function_name, const char *session_dictionary_name,
+lldb::TypeImplSP type_impl_sp) {
+  return false;
+}
+
 bool lldb_private::LLDBSwigPythonCallTypeScript(
 const char *python_function_name, const void *session_dictionary,
 const lldb::ValueObjectSP &valobj_sp, void **pyfunct_wrapper,
Index: lldb/unittests/DataFormatter/FormattersContainerTest.cpp
===
--- lldb/unittests/DataFormatter/FormattersContainerTest.cpp
+++ lldb/unittests/DataFormatter/FormattersContainerTest.cpp
@@ -7,12 +7,20 @@
 //===--===//
 
 #include "lldb/DataFormatters/FormattersContainer.h"
+#include "lldb/DataFormatters/FormatClasses.h"
 
 #include "gtest/gtest.h"
 
 using namespace lldb;
 using namespace lldb_private;
 
+// Creates a dummy candidate with just a type name in order to test the string
+// matching (exact name match and regex match) paths.
+FormattersMatchCandidate CandidateFromTypeName(const char *type_name) {
+  return FormattersMatchCandidate(ConstString(type_name), nullptr, TypeImpl(),
+  FormattersMatchCandidate::Flags());
+}
+
 // All the prefixes that the exact name matching will strip from the type.
 static const std::vector exact_name_prefixes = {
 "", // no prefix.
@@ -25,63 +33,63 @@
 SCOPED_TRACE("Prefix: " + prefix);
 
 TypeMatcher matcher(ConstString(prefix + "Name"));
-EXPECT_TRUE(matcher.Matches(ConstString("class Name")));
-EXPECT_TRUE(matcher.Matches(ConstString("struct Name")));
-EXPECT_TRUE(matcher.Matches(ConstString("union Name")));
-EXPECT_TRUE(matcher.Matches(ConstString("enum Name")));
-EXPECT_TRUE(matcher.Matches(ConstString("Name")));
-
-EXPECT_FALSE(matcher.Matches(ConstString("Name ")));
-EXPECT_FALSE(matcher.Matches(ConstString("ame")));
-EXPECT_FALSE(matcher.Matches(ConstString("Nam")));
-EXPECT_FALSE(matcher.Matches(ConstString("am")));
-EXPECT_FALSE(matcher.Matches(ConstString("a")));
-EXPECT_FALSE(matcher.Matches(ConstString(" ")));
-EXPECT_FALSE(matcher.Matches(ConstString("class N")));
-EXPECT_FALSE(matcher.Matches(ConstString("class ")));
-EXPECT_FALSE(matcher.Matches(ConstString("class")));
+EXPECT_TRUE(matcher.Matches(CandidateFromTypeName("class Name")));
+EXPECT_TRUE(matcher.Matches(CandidateFromTypeName("struct Name")));
+EXPECT_TRUE(matcher.Matches(CandidateFromTypeName("union Name")));
+EXPECT_TRUE(matcher.Matches(Candidate

[Lldb-commits] [PATCH] D135983: [lldb] Fix a -Wdeprecated-declarations warning

2022-10-19 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135983/new/

https://reviews.llvm.org/D135983

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

[Lldb-commits] [PATCH] D136114: [lldb] Allow SymbolFileDWARFDebugMap to register multiple compile units

2022-10-19 Thread Augusto Noronha via Phabricator via lldb-commits 
augusto2112 updated this revision to Diff 469032.
augusto2112 added a comment.

Updated default stack size of the cu containers


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136114/new/

https://reviews.llvm.org/D136114

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  lldb/test/API/lang/c/full_lto_stepping/Makefile
  lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
  lldb/test/API/lang/c/full_lto_stepping/foo.c
  lldb/test/API/lang/c/full_lto_stepping/foo.h
  lldb/test/API/lang/c/full_lto_stepping/main.c

Index: lldb/test/API/lang/c/full_lto_stepping/main.c
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/main.c
@@ -0,0 +1,6 @@
+#include "foo.h"
+
+int main(void) {
+  int i = f();
+  return 0;
+}
Index: lldb/test/API/lang/c/full_lto_stepping/foo.h
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/foo.h
@@ -0,0 +1 @@
+int f(void);
Index: lldb/test/API/lang/c/full_lto_stepping/foo.c
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/foo.c
@@ -0,0 +1,3 @@
+int f() {
+  return 42;
+}
Index: lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
@@ -0,0 +1,29 @@
+"""Test that stepping in object files with multiple compile units works."""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbutil as lldbutil
+
+
+class TestFullLtoStepping(TestBase):
+
+@skipIf(compiler=no_match("clang"))
+@skipUnlessDarwin
+def test(self):
+self.build()
+target = self.createTestTarget()
+
+breakpoint = target.BreakpointCreateByName("main")
+self.assertTrue(
+breakpoint and breakpoint.IsValid(),
+"Breakpoint is valid")
+
+_, _, thread, _ = lldbutil.run_to_breakpoint_do_run(self, target, breakpoint)
+name = thread.frames[0].GetFunctionName()
+# Check that we start out in main.
+self.assertEqual(name, 'main')
+thread.StepInto()
+name = thread.frames[0].GetFunctionName()
+# Check that we stepped into f.
+self.assertEqual(name, 'f')
Index: lldb/test/API/lang/c/full_lto_stepping/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c foo.c
+CFLAGS_EXTRAS = -flto=full -Wl,-object_path_lto -Wl,$(BUILDDIR)/lto.o
+
+include Makefile.rules
\ No newline at end of file
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
@@ -19,6 +19,7 @@
 #include "UniqueDWARFASTType.h"
 
 class SymbolFileDWARF;
+class DWARFCompileUnit;
 class DWARFDebugAranges;
 class DWARFDeclContext;
 
@@ -174,7 +175,10 @@
 llvm::sys::TimePoint<> oso_mod_time;
 lldb_private::Status oso_load_error;
 OSOInfoSP oso_sp;
-lldb::CompUnitSP compile_unit_sp;
+/// The compile units that an object file contains.
+llvm::SmallVector compile_units_sps;
+/// A map from the compile unit ID to its index in the vector.
+llvm::SmallDenseMap id_to_index_map;
 uint32_t first_symbol_index = UINT32_MAX;
 uint32_t last_symbol_index = UINT32_MAX;
 uint32_t first_symbol_id = UINT32_MAX;
@@ -182,10 +186,7 @@
 FileRangeMap file_range_map;
 bool file_range_map_valid = false;
 
-CompileUnitInfo()
-: so_file(), oso_path(), oso_mod_time(), oso_sp(), compile_unit_sp(),
-
-  file_range_map() {}
+CompileUnitInfo() = default;
 
 const FileRangeMap &GetFileRangeMap(SymbolFileDWARFDebugMap *exe_symfile);
   };
@@ -193,7 +194,17 @@
   // Protected Member Functions
   void InitOSO();
 
+  /// This function actually returns the number of object files, which may be
+  /// less than the actual number of compile units, since an object file may
+  /// contain more than one compile unit. SymbolFileDWARFDebugMap looks up the
+  /// number of compile units by reading the nlist symbol table, which
+  /// currently, on macOS, only reports one compile unit per object file, and
+  /// there's no efficient way to calculate the actual number of compile units
+  /// upfront.
   uint32_t CalculateNumCompileUnits() override;
+
+  /// This function actually returns the f

[Lldb-commits] [lldb] 6f2423c - [lldb] Allow SymbolFileDWARFDebugMap to register multiple compile units

2022-10-19 Thread Augusto Noronha via lldb-commits 

Author: Augusto Noronha
Date: 2022-10-19T13:49:40-07:00
New Revision: 6f2423c6fe97bec77da66d87a7a997917f6b489e

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

LOG: [lldb] Allow SymbolFileDWARFDebugMap to register multiple compile units

Currently, SymbolFileDWARFDebugMap works on the assumption that there is
only one compile unit per object file. This patch documents this
limitation (when using the general SymbolFile API), and allows users of
the concrete SymbolFileDWARFDebugMap class to find out about these extra
compile units.

Differential Revision: https://reviews.llvm.org/D136114

Added: 
lldb/test/API/lang/c/full_lto_stepping/Makefile
lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
lldb/test/API/lang/c/full_lto_stepping/foo.c
lldb/test/API/lang/c/full_lto_stepping/foo.h
lldb/test/API/lang/c/full_lto_stepping/main.c

Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
index 9ca160b474fc9..ced03752aadc2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
@@ -53,28 +53,21 @@ void DWARFCompileUnit::BuildAddressRangeTable(
   }
 
   if (debug_aranges->GetNumRanges() == num_debug_aranges) {
-// We got nothing from the debug info, maybe we have a line tables only
-// situation. Check the line tables and build the arange table from this.
+// We got nothing from the debug info, try to build the arange table from
+// the debug map OSO aranges.
 SymbolContext sc;
 sc.comp_unit = m_dwarf.GetCompUnitForDWARFCompUnit(*this);
 if (sc.comp_unit) {
   SymbolFileDWARFDebugMap *debug_map_sym_file =
   m_dwarf.GetDebugMapSymfile();
-  if (debug_map_sym_file == nullptr) {
-if (LineTable *line_table = sc.comp_unit->GetLineTable()) {
-  LineTable::FileAddressRanges file_ranges;
-  const bool append = true;
-  const size_t num_ranges =
-  line_table->GetContiguousFileAddressRanges(file_ranges, append);
-  for (uint32_t idx = 0; idx < num_ranges; ++idx) {
-const LineTable::FileAddressRanges::Entry &range =
-file_ranges.GetEntryRef(idx);
-debug_aranges->AppendRange(cu_offset, range.GetRangeBase(),
-   range.GetRangeEnd());
-  }
-}
-  } else
-debug_map_sym_file->AddOSOARanges(&m_dwarf, debug_aranges);
+  if (debug_map_sym_file) {
+auto *cu_info =
+debug_map_sym_file->GetCompileUnitInfo(&GetSymbolFileDWARF());
+// If there are extra compile units the OSO entries aren't a reliable
+// source of information.
+if (cu_info->compile_units_sps.empty())
+  debug_map_sym_file->AddOSOARanges(&m_dwarf, debug_aranges);
+  }
 }
   }
 

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index d029e4da86175..42a0302351dd6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -702,9 +702,9 @@ lldb::CompUnitSP 
SymbolFileDWARF::ParseCompileUnit(DWARFCompileUnit &dwarf_cu) {
 // We already parsed this compile unit, had out a shared pointer to it
 cu_sp = comp_unit->shared_from_this();
   } else {
-if (dwarf_cu.GetOffset() == 0 && GetDebugMapSymfile()) {
+if (GetDebugMapSymfile()) {
   // Let the debug map create the compile unit
-  cu_sp = m_debug_map_symfile->GetCompileUnit(this);
+  cu_sp = m_debug_map_symfile->GetCompileUnit(this, dwarf_cu);
   dwarf_cu.SetUserData(cu_sp.get());
 } else {
   ModuleSP module_sp(m_objfile_sp->GetModule());

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
index 97140704ad33e..015633727f18d 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -7,7 +7,9 @@
 
//===--===//
 
 #include "SymbolFileDWARFDebugMap.h"
+#include "DWARFCompileUnit.h"
 #include "DWARFDebugAranges.h"
+#include "DWARFDebugInfo.h"
 
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleList.h"
@@ -17,6 +19,7 @@
 #include "lld

[Lldb-commits] [PATCH] D136114: [lldb] Allow SymbolFileDWARFDebugMap to register multiple compile units

2022-10-19 Thread Augusto Noronha via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6f2423c6fe97: [lldb] Allow SymbolFileDWARFDebugMap to 
register multiple compile units (authored by augusto2112).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136114/new/

https://reviews.llvm.org/D136114

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  lldb/test/API/lang/c/full_lto_stepping/Makefile
  lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
  lldb/test/API/lang/c/full_lto_stepping/foo.c
  lldb/test/API/lang/c/full_lto_stepping/foo.h
  lldb/test/API/lang/c/full_lto_stepping/main.c

Index: lldb/test/API/lang/c/full_lto_stepping/main.c
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/main.c
@@ -0,0 +1,6 @@
+#include "foo.h"
+
+int main(void) {
+  int i = f();
+  return 0;
+}
Index: lldb/test/API/lang/c/full_lto_stepping/foo.h
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/foo.h
@@ -0,0 +1 @@
+int f(void);
Index: lldb/test/API/lang/c/full_lto_stepping/foo.c
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/foo.c
@@ -0,0 +1,3 @@
+int f() {
+  return 42;
+}
Index: lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py
@@ -0,0 +1,29 @@
+"""Test that stepping in object files with multiple compile units works."""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbutil as lldbutil
+
+
+class TestFullLtoStepping(TestBase):
+
+@skipIf(compiler=no_match("clang"))
+@skipUnlessDarwin
+def test(self):
+self.build()
+target = self.createTestTarget()
+
+breakpoint = target.BreakpointCreateByName("main")
+self.assertTrue(
+breakpoint and breakpoint.IsValid(),
+"Breakpoint is valid")
+
+_, _, thread, _ = lldbutil.run_to_breakpoint_do_run(self, target, breakpoint)
+name = thread.frames[0].GetFunctionName()
+# Check that we start out in main.
+self.assertEqual(name, 'main')
+thread.StepInto()
+name = thread.frames[0].GetFunctionName()
+# Check that we stepped into f.
+self.assertEqual(name, 'f')
Index: lldb/test/API/lang/c/full_lto_stepping/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/c/full_lto_stepping/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c foo.c
+CFLAGS_EXTRAS = -flto=full -Wl,-object_path_lto -Wl,$(BUILDDIR)/lto.o
+
+include Makefile.rules
\ No newline at end of file
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
@@ -19,6 +19,7 @@
 #include "UniqueDWARFASTType.h"
 
 class SymbolFileDWARF;
+class DWARFCompileUnit;
 class DWARFDebugAranges;
 class DWARFDeclContext;
 
@@ -174,7 +175,10 @@
 llvm::sys::TimePoint<> oso_mod_time;
 lldb_private::Status oso_load_error;
 OSOInfoSP oso_sp;
-lldb::CompUnitSP compile_unit_sp;
+/// The compile units that an object file contains.
+llvm::SmallVector compile_units_sps;
+/// A map from the compile unit ID to its index in the vector.
+llvm::SmallDenseMap id_to_index_map;
 uint32_t first_symbol_index = UINT32_MAX;
 uint32_t last_symbol_index = UINT32_MAX;
 uint32_t first_symbol_id = UINT32_MAX;
@@ -182,10 +186,7 @@
 FileRangeMap file_range_map;
 bool file_range_map_valid = false;
 
-CompileUnitInfo()
-: so_file(), oso_path(), oso_mod_time(), oso_sp(), compile_unit_sp(),
-
-  file_range_map() {}
+CompileUnitInfo() = default;
 
 const FileRangeMap &GetFileRangeMap(SymbolFileDWARFDebugMap *exe_symfile);
   };
@@ -193,7 +194,17 @@
   // Protected Member Functions
   void InitOSO();
 
+  /// This function actually returns the number of object files, which may be
+  /// less than the actual number of compile units, since an object file may
+  /// contain more than one compile unit. SymbolFileDWARFDebugMap looks up the
+  /// number of compile units by reading the nlist symbol table, which
+  /// currently, on macOS, only reports one compile unit per object file, and
+  /// there's no efficient way to calculate the actual number of compile units
+  /// upfront.
   uint32_t Calc

Re: [Lldb-commits] [lldb] d765664 - [lldb] Add matching based on Python callbacks for data formatters.

2022-10-19 Thread Jim Ingham via lldb-commits 
Jorge,

It's great to see you worked your way through this change!

Something in our mail pipeline is dropping all my lldb-commits and review 
comment notifications.  Still haven't figured out who is doing that, so I 
didn't get a chance to look over the final version.

The code looks fine, but nobody will know how to use this if they don't read 
lldb source code fairly carefully, or browse our tests.

To finish off the feature, there should be an example to put in the examples 
directory, and there should be a paragraph showing how to use it in 
lldb/doc/use/formatting.rst.

It would also be good to add something an option to "type summary add" and 
"type synthetic add" to indicate that the name passed is neither a type name 
nor a regex but a recognizer function instead.  Maybe -R/--recognizer-function?

Is it too horrible of me to ask you to do these as a follow-up?  Otherwise I 
fear you will be the only one to use this feature...

Jim


> On Oct 19, 2022, at 12:54 PM, Jorge Gorbe Moya via lldb-commits 
>  wrote:
> 
> 
> Author: Jorge Gorbe Moya
> Date: 2022-10-19T12:53:38-07:00
> New Revision: d76566417e592cfac9c710f82575473b1b4a9285
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285
> DIFF: 
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285.diff
> 
> LOG: [lldb] Add matching based on Python callbacks for data formatters.
> 
> This patch adds a new matching method for data formatters, in addition
> to the existing exact typename and regex-based matching. The new method
> allows users to specify the name of a Python callback function that
> takes a `SBType` object and decides whether the type is a match or not.
> 
> Here is an overview of the changes performed:
> 
> - Add a new `eFormatterMatchCallback` matching type, and logic to handle
>  it in `TypeMatcher` and `SBTypeNameSpecifier`.
> 
> - Extend `FormattersMatchCandidate` instances with a pointer to the
>  current `ScriptInterpreter` and the `TypeImpl` corresponding to the
>  candidate type, so we can run registered callbacks and pass the type
>  to them. All matcher search functions now receive a
>  `FormattersMatchCandidate` instead of a type name.
> 
> - Add some glue code to ScriptInterpreterPython and the SWIG bindings to
>  allow calling a formatter matching callback. Most of this code is
>  modeled after the equivalent code for watchpoint callback functions.
> 
> - Add an API test for the new callback-based matching feature.
> 
> For more context, please check the RFC thread where this feature was
> originally discussed:
> https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11
> 
> Differential Revision: https://reviews.llvm.org/D135648
> 
> Added: 
>lldb/test/API/functionalities/data-formatter/callback-matching/Makefile
>
> lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
>
> lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
>lldb/test/API/functionalities/data-formatter/callback-matching/main.cpp
> 
> Modified: 
>lldb/bindings/python/python-swigsafecast.swig
>lldb/bindings/python/python-wrapper.swig
>lldb/include/lldb/API/SBType.h
>lldb/include/lldb/DataFormatters/DataVisualization.h
>lldb/include/lldb/DataFormatters/FormatClasses.h
>lldb/include/lldb/DataFormatters/FormatManager.h
>lldb/include/lldb/DataFormatters/FormattersContainer.h
>lldb/include/lldb/DataFormatters/TypeCategory.h
>lldb/include/lldb/DataFormatters/TypeCategoryMap.h
>lldb/include/lldb/Interpreter/ScriptInterpreter.h
>lldb/include/lldb/Target/Language.h
>lldb/include/lldb/lldb-enumerations.h
>lldb/source/API/SBTypeNameSpecifier.cpp
>lldb/source/Commands/CommandObjectType.cpp
>lldb/source/DataFormatters/DataVisualization.cpp
>lldb/source/DataFormatters/FormatManager.cpp
>lldb/source/DataFormatters/TypeCategory.cpp
>lldb/source/DataFormatters/TypeCategoryMap.cpp
>lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
>lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
>lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
>lldb/source/Target/Language.cpp
>lldb/unittests/DataFormatter/FormattersContainerTest.cpp
>lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
> b/lldb/bindings/python/python-swigsafecast.swig
> index eb684133abef..aa5e8e50a2d9 100644
> --- a/lldb/bindings/python/python-swigsafecast.swig
> +++ b/lldb/bindings/python/python-swigsafecast.swig
> @@ -97,6 +97,10 @@ PythonObject ToSWIGWrapper(lldb::Executio

Re: [Lldb-commits] [lldb] d765664 - [lldb] Add matching based on Python callbacks for data formatters.

2022-10-19 Thread Jorge Gorbe Moya via lldb-commits 
Hi Jim,

Thanks for the encouragement! It's unfortunate that you missed the
notifications and couldn't contribute to the code reviews, but I'm glad you
think the code looks fine.

Of course I don't mind adding these as a follow-up, it would be a shame if
I didn't expose the new feature for CLI users after doing all the work
to get to this point. In fact, I was planning to ask about it after landing
the change, so thank you for the details about how to proceed next :)

On Wed, Oct 19, 2022 at 2:00 PM Jim Ingham  wrote:

> Jorge,
>
> It's great to see you worked your way through this change!
>
> Something in our mail pipeline is dropping all my lldb-commits and review
> comment notifications.  Still haven't figured out who is doing that, so I
> didn't get a chance to look over the final version.
>
> The code looks fine, but nobody will know how to use this if they don't
> read lldb source code fairly carefully, or browse our tests.
>
> To finish off the feature, there should be an example to put in the
> examples directory, and there should be a paragraph showing how to use it
> in lldb/doc/use/formatting.rst.
>
> It would also be good to add something an option to "type summary add" and
> "type synthetic add" to indicate that the name passed is neither a type
> name nor a regex but a recognizer function instead.  Maybe
> -R/--recognizer-function?
>
> Is it too horrible of me to ask you to do these as a follow-up?  Otherwise
> I fear you will be the only one to use this feature...
>
> Jim
>
>
> > On Oct 19, 2022, at 12:54 PM, Jorge Gorbe Moya via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> >
> > Author: Jorge Gorbe Moya
> > Date: 2022-10-19T12:53:38-07:00
> > New Revision: d76566417e592cfac9c710f82575473b1b4a9285
> >
> > URL:
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285
> > DIFF:
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285.diff
> >
> > LOG: [lldb] Add matching based on Python callbacks for data formatters.
> >
> > This patch adds a new matching method for data formatters, in addition
> > to the existing exact typename and regex-based matching. The new method
> > allows users to specify the name of a Python callback function that
> > takes a `SBType` object and decides whether the type is a match or not.
> >
> > Here is an overview of the changes performed:
> >
> > - Add a new `eFormatterMatchCallback` matching type, and logic to handle
> >  it in `TypeMatcher` and `SBTypeNameSpecifier`.
> >
> > - Extend `FormattersMatchCandidate` instances with a pointer to the
> >  current `ScriptInterpreter` and the `TypeImpl` corresponding to the
> >  candidate type, so we can run registered callbacks and pass the type
> >  to them. All matcher search functions now receive a
> >  `FormattersMatchCandidate` instead of a type name.
> >
> > - Add some glue code to ScriptInterpreterPython and the SWIG bindings to
> >  allow calling a formatter matching callback. Most of this code is
> >  modeled after the equivalent code for watchpoint callback functions.
> >
> > - Add an API test for the new callback-based matching feature.
> >
> > For more context, please check the RFC thread where this feature was
> > originally discussed:
> >
> https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11
> >
> > Differential Revision: https://reviews.llvm.org/D135648
> >
> > Added:
> >
> lldb/test/API/functionalities/data-formatter/callback-matching/Makefile
> >
> lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
> >
> lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
> >
> lldb/test/API/functionalities/data-formatter/callback-matching/main.cpp
> >
> > Modified:
> >lldb/bindings/python/python-swigsafecast.swig
> >lldb/bindings/python/python-wrapper.swig
> >lldb/include/lldb/API/SBType.h
> >lldb/include/lldb/DataFormatters/DataVisualization.h
> >lldb/include/lldb/DataFormatters/FormatClasses.h
> >lldb/include/lldb/DataFormatters/FormatManager.h
> >lldb/include/lldb/DataFormatters/FormattersContainer.h
> >lldb/include/lldb/DataFormatters/TypeCategory.h
> >lldb/include/lldb/DataFormatters/TypeCategoryMap.h
> >lldb/include/lldb/Interpreter/ScriptInterpreter.h
> >lldb/include/lldb/Target/Language.h
> >lldb/include/lldb/lldb-enumerations.h
> >lldb/source/API/SBTypeNameSpecifier.cpp
> >lldb/source/Commands/CommandObjectType.cpp
> >lldb/source/DataFormatters/DataVisualization.cpp
> >lldb/source/DataFormatters/FormatManager.cpp
> >lldb/source/DataFormatters/TypeCategory.cpp
> >lldb/source/DataFormatters/TypeCategoryMap.cpp
> >lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
> >lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
> >lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
> >
> lldb/source/Plugins/ScriptInterpreter/Python/Scri

[Lldb-commits] [PATCH] D136295: Fix exception description in lldb-vscode

2022-10-19 Thread jeffrey tan via Phabricator via lldb-commits 
yinghuitan created this revision.
yinghuitan added reviewers: clayborg, labath, jingham, jdoerfert, JDevlieghere, 
aadsm, kusmour, fixathon.
Herald added a project: All.
yinghuitan requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

There is a bug in lldb-vscode that only shows stop reason ("exception") in 
stopped event without showing the stop description of thrown exception. This
causes VSCode UI to only show "Paused on Exception" general message in
callstack window UI.

This patch fixes the bug so that VSCode callstack will show the detailed
exceptioni description, like "signal SIGABRT" or "EXC_BAD_ACCESS..." which
aligns with command line lldb experience.

I use C++ exception in testcase because the hardware exception description is 
platform dependent and hard to verify.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136295

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  lldb/test/API/tools/lldb-vscode/exception/Makefile
  lldb/test/API/tools/lldb-vscode/exception/TestVSCode_exception.py
  lldb/test/API/tools/lldb-vscode/exception/main.cpp
  lldb/tools/lldb-vscode/JSONUtils.cpp


Index: lldb/tools/lldb-vscode/JSONUtils.cpp
===
--- lldb/tools/lldb-vscode/JSONUtils.cpp
+++ lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -930,7 +930,7 @@
   // If no description has been set, then set it to the default thread stopped
   // description. If we have breakpoints that get hit and shouldn't be reported
   // as breakpoints, then they will set the description above.
-  if (ObjectContainsKey(body, "description")) {
+  if (!ObjectContainsKey(body, "description")) {
 char description[1024];
 if (thread.GetStopDescription(description, sizeof(description))) {
   EmplaceSafeString(body, "description", std::string(description));
Index: lldb/test/API/tools/lldb-vscode/exception/main.cpp
===
--- /dev/null
+++ lldb/test/API/tools/lldb-vscode/exception/main.cpp
@@ -0,0 +1,6 @@
+#include 
+
+int main() {
+  throw std::runtime_error("runtime error message");
+  return 0;
+}
Index: lldb/test/API/tools/lldb-vscode/exception/TestVSCode_exception.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-vscode/exception/TestVSCode_exception.py
@@ -0,0 +1,23 @@
+"""
+Test stop hooks
+"""
+
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+import lldbvscode_testcase
+
+
+class TestVSCode_exception(lldbvscode_testcase.VSCodeTestCaseBase):
+
+@skipIfRemote
+def test_stopped_description(self):
+'''
+TODO
+'''
+program = self.getBuildArtifact("a.out")
+print("test_stopped_description called", flush=True)
+self.build_and_launch(program)
+
+self.vscode.request_continue()
+self.assertTrue(self.verify_stop_exception_info("signal SIGABRT"))
Index: lldb/test/API/tools/lldb-vscode/exception/Makefile
===
--- /dev/null
+++ lldb/test/API/tools/lldb-vscode/exception/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
Index: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
===
--- lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
+++ lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
@@ -93,10 +93,10 @@
 return
 self.assertTrue(False, "breakpoint not hit")
 
-def verify_exception_breakpoint_hit(self, filter_label):
+def verify_stop_exception_info(self, expected_description):
 '''Wait for the process we are debugging to stop, and verify the stop
reason is 'exception' and that the description matches
-   'filter_label'
+   'expected_description'
 '''
 stopped_events = self.vscode.wait_for_stopped()
 for stopped_event in stopped_events:
@@ -109,7 +109,7 @@
 if 'description' not in body:
 continue
 description = body['description']
-if filter_label == description:
+if expected_description == description:
 return True
 return False
 
@@ -236,7 +236,7 @@
 
 def continue_to_exception_breakpoint(self, filter_label):
 self.vscode.request_continue()
-self.assertTrue(self.verify_exception_breakpoint_hit(filter_label),
+self.assertTrue(self.verify_stop_exception_info(filter_label),
 'verify we got "%s"' % (filter_label))
 
 def continue_to_exit(self, exitCode=0):


Index: lldb/tools/lldb-vscode/JSONUtils.cpp

[Lldb-commits] [PATCH] D134378: [lldb] Support simplified template names

2022-10-19 Thread Reid Kleckner via Phabricator via lldb-commits 
rnk added a comment.

@Michael137, are you comfortable approving this, or can you reroute to a 
reviewer who can help us with this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134378/new/

https://reviews.llvm.org/D134378

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

[Lldb-commits] [PATCH] D134378: [lldb] Support simplified template names

2022-10-19 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 added subscribers: jingham, labath, aprantl.
Michael137 added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2500
+const llvm::StringRef nameRef = name.GetStringRef();
+auto it = nameRef.find('<');
+if (it != llvm::StringRef::npos) {

Is there some other way to determine whether the debug-info was generated from 
`-gsimple-template-names`? Then we wouldn't have to check the existence of a 
`<` in the name in multiple places and wouldn't have to do this lookup 
speculatively. With this change, if we fail to find a template type in the 
index, we would do the lookup all over again, only to not find it again. Could 
that get expensive? Just trying to figure out if we can avoid doing this 
`GetTypes` call twice.

There have been [talks](https://github.com/llvm/llvm-project/issues/58362) 
about doing a base-name search by default followed by fuzzy matching on 
template parameters (though in the context of function names). The 
`simple-template-names` came up as a good motivator/facilitator for doing so. 
But for that idea to work here we'd have to be able to retrieve from the index 
by basename, so perhaps out of the scope of what we're trying to do here

tagging people involved in that discussion: @dblaikie @aprantl @jingham @labath

Other than this, generally LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134378/new/

https://reviews.llvm.org/D134378

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

[Lldb-commits] [PATCH] D136306: [WIP][lldb][CPlusPlus] Add abi_tag support to the CPlusPlusNameParser

2022-10-19 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 created this revision.
Michael137 added reviewers: aprantl, labath, jingham.
Herald added a project: All.
Michael137 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This patch teaches the `CPlusPlusNameParser` to parse the
demangled/prettified [[gnu::abi_tag(...)]] attribute. The demangled format
isn't standardized and the additions to the parser were mainly driven
using Clang (and the limited information on this from the official
Clang docs).

This change is motivated by multiple failures around step-in
behaviour for libcxx APIs (many of which have ABI tags as of recently).
LLDB determines whether the `step-avoid-regexp` matches the current
frame by parsing the scope-qualified name out of the demangled
function symbol. On failure, the `CPlusPlusNameParser` will simply
return the fully demangled name (which can include the return type)
to the caller, which in `FrameMatchesAvoidCriteria` means we will
not correctly decide whether we should stop at a frame or not if
the function has an abi_tag.

Ideally we wouldn't want to rely on the non-standard format
of demangled attributes. Alternatives would be:

1. Use the mangle tree API to do the parsing for us
2. Reconstruct the scope-qualified name from DWARF instead of parsing the 
demangled name

(1) isn't feasible without a significant refactor of `lldb_private::Mangled`,
if we want to do this efficiently.

(2) could be feasible in cases where debug-info for a frame is
available

**Testing**

- Un-XFAILed step-in API test
- Added parser unit-tests


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136306

Files:
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.h
  lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
  lldb/test/API/functionalities/step-avoids-regexp/main.cpp
  lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp

Index: lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
===
--- lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
+++ lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
@@ -120,7 +120,35 @@
"test_return_auto", "()", "const", "std::test_return_auto"},
   {"decltype(auto) std::test_return_auto(int) const", "std",
"test_return_auto", "(int)", "const",
-   "std::test_return_auto"}};
+   "std::test_return_auto"},
+  
+  // abi_tag on class
+  {"v1::v2::Dummy[abi:c1][abi:c2]> "
+   "v1::v2::Dummy[abi:c1][abi:c2]>"
+   "::method2>>(int, v1::v2::Dummy) const &&",
+   // Context
+   "v1::v2::Dummy[abi:c1][abi:c2]>",
+   // Basename
+   "method2>>", 
+   // Args, qualifiers
+   "(int, v1::v2::Dummy)", "const &&",
+   // Full scope-qualified name without args
+   "v1::v2::Dummy[abi:c1][abi:c2]>"
+   "::method2>>"},
+
+  // abi_tag on free function and template argument
+  {"v1::v2::Dummy[abi:c1][abi:c2]> "
+   "v1::v2::with_tag_in_ns[abi:f1][abi:f2]>>(int, v1::v2::Dummy) const &&",
+   // Context
+   "v1::v2",
+   // Basename
+   "with_tag_in_ns[abi:f1][abi:f2]>>",
+   // Args, qualifiers
+   "(int, v1::v2::Dummy)", "const &&",
+   // Full scope-qualified name without args
+   "v1::v2::with_tag_in_ns[abi:f1][abi:f2]>>"}
+  };
 
   for (const auto &test : test_cases) {
 CPlusPlusLanguage::MethodName method(ConstString(test.input));
Index: lldb/test/API/functionalities/step-avoids-regexp/main.cpp
===
--- lldb/test/API/functionalities/step-avoids-regexp/main.cpp
+++ lldb/test/API/functionalities/step-avoids-regexp/main.cpp
@@ -1,4 +1,6 @@
 namespace ignore {
+struct Dummy {};
+
 template  auto auto_ret(T x) { return 0; }
 [[gnu::abi_tag("test")]] int with_tag() { return 0; }
 template  [[gnu::abi_tag("test")]] int with_tag_template() {
@@ -8,9 +10,15 @@
 template  decltype(auto) decltype_auto_ret(T x) { return 0; }
 } // namespace ignore
 
+template 
+[[gnu::abi_tag("test")]] ignore::Dummy with_tag_template_returns_ignore(T x) {
+  return {};
+}
+
 int main() {
   auto v1 = ignore::auto_ret(5);
   auto v2 = ignore::with_tag();
   auto v3 = ignore::decltype_auto_ret(5);
   auto v4 = ignore::with_tag_template();
+  auto v5 = with_tag_template_returns_ignore(5);
 }
Index: lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
===
--- lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
+++ lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
@@ -37,13 +37,10 @@
 self.thread.StepInto()
 self.hit_correct_function("main")
 
-@skipIfWindows
-@expectedFailureAll(bugnumber="rdar://100645742")
-def test_step_avoid_regex_abi_tagged_template(self)

[Lldb-commits] [PATCH] D136306: [WIP][lldb][CPlusPlus] Add abi_tag support to the CPlusPlusNameParser

2022-10-19 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 added a comment.
Herald added a subscriber: JDevlieghere.

Would really be nice not to have to do this. Especially because it looks like 
only the LLVM demangler prints out the ABI tags (though other vendors may start 
doing the same at some point)

This is partly educational to see what we'd have to do to support demangled 
names with abi-tags


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136306/new/

https://reviews.llvm.org/D136306

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

[Lldb-commits] [PATCH] D134878: Update developer policy on potentially breaking changes

2022-10-19 Thread Mehdi AMINI via Phabricator via lldb-commits 
mehdi_amini added a comment.

From what I saw when you posted the discourse thread initially, I understand 
you're targeting user-visible features, and mostly from the "toolchain" side of 
the project.
However I find the language here to be potentially confusing for the API 
surface of the libraries: that is how much of this applies to the LLVM C++ 
libraries API surface?
If this is out-of-scope, can this be called out more explicitly?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134878/new/

https://reviews.llvm.org/D134878

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