[Lldb-commits] [PATCH] D126694: [C++20][Modules] Implementation of GMF decl elision.

[Chuanqi Xu via Phabricator via lldb-commits]

ChuanqiXu added a comment.

I haven't looked into the details. But I feel the feature worth a sentence in 
ReleaseNotes. (Maybe in the potential-breaking-change section). Also I think 
it'll be better to have an option 
`-fenable-discarding-unreachable-decls-in-gmf` to control the behavior. It'll 
be helpful for debugging if we missed some point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126694

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

[Lldb-commits] [lldb] b2a5dd1 - [LLDB] Fix the build for ppc64le linux

[Martin Storsjö via lldb-commits]

Author: Martin Storsjö
Date: 2022-10-18T11:54:19+03:00
New Revision: b2a5dd12a47a784f09628f1c10ab369c3b2c3c88

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

LOG: [LLDB] Fix the build for ppc64le linux

812ad2167bd2e27f5d0dee07bb03a5910616e0b6 changed the signature of
RegisterValue::SetFromMemoryData.

Added: 


Modified: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp
index e96a41fe86d01..cb6f81b28f7cc 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.cpp
@@ -184,7 +184,7 @@ Status NativeRegisterContextLinux_ppc64le::ReadRegister(
 uint32_t fpr_offset = CalculateFprOffset(reg_info);
 assert(fpr_offset < sizeof m_fpr_ppc64le);
 uint8_t *src = (uint8_t *)&m_fpr_ppc64le + fpr_offset;
-reg_value.SetFromMemoryData(reg_info, src, reg_info->byte_size,
+reg_value.SetFromMemoryData(*reg_info, src, reg_info->byte_size,
 eByteOrderLittle, error);
   } else if (IsVSX(reg)) {
 uint32_t vsx_offset = CalculateVsxOffset(reg_info);
@@ -207,7 +207,7 @@ Status NativeRegisterContextLinux_ppc64le::ReadRegister(
   dst += 8;
   src = (uint8_t *)&m_fpr_ppc64le + vsx_offset / 2;
   ::memcpy(dst, src, 8);
-  reg_value.SetFromMemoryData(reg_info, &value, reg_info->byte_size,
+  reg_value.SetFromMemoryData(*reg_info, &value, reg_info->byte_size,
   eByteOrderLittle, error);
 } else {
   error = ReadVMX();
@@ -217,7 +217,7 @@ Status NativeRegisterContextLinux_ppc64le::ReadRegister(
   // Get pointer to m_vmx_ppc64le variable and set the data from it.
   uint32_t vmx_offset = vsx_offset - sizeof(m_vsx_ppc64le) / 2;
   uint8_t *src = (uint8_t *)&m_vmx_ppc64le + vmx_offset;
-  reg_value.SetFromMemoryData(reg_info, src, reg_info->byte_size,
+  reg_value.SetFromMemoryData(*reg_info, src, reg_info->byte_size,
   eByteOrderLittle, error);
 }
   } else if (IsVMX(reg)) {
@@ -229,7 +229,7 @@ Status NativeRegisterContextLinux_ppc64le::ReadRegister(
 uint32_t vmx_offset = CalculateVmxOffset(reg_info);
 assert(vmx_offset < sizeof m_vmx_ppc64le);
 uint8_t *src = (uint8_t *)&m_vmx_ppc64le + vmx_offset;
-reg_value.SetFromMemoryData(reg_info, src, reg_info->byte_size,
+reg_value.SetFromMemoryData(*reg_info, src, reg_info->byte_size,
 eByteOrderLittle, error);
   } else if (IsGPR(reg)) {
 error = ReadGPR();
@@ -237,7 +237,7 @@ Status NativeRegisterContextLinux_ppc64le::ReadRegister(
   return error;
 
 uint8_t *src = (uint8_t *) &m_gpr_ppc64le + reg_info->byte_offset;
-reg_value.SetFromMemoryData(reg_info, src, reg_info->byte_size,
+reg_value.SetFromMemoryData(*reg_info, src, reg_info->byte_size,
 eByteOrderLittle, error);
   } else {
 return Status("failed - register wasn't recognized to be a GPR, FPR, VSX "



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

[Lldb-commits] [PATCH] D136144: [lldb] Fix m_hwp_regs size for ppc64le

[Nikita Popov via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6f59f302e435: [lldb] Fix m_hwp_regs size for ppc64le 
(PR54520) (authored by nikic).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136144

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
@@ -122,7 +122,7 @@
 int mode;   // Defines if watchpoint is read/write/access.
   };
 
-  std::array m_hwp_regs;
+  std::array m_hwp_regs;
 
   // 16 is just a maximum value, query hardware for actual watchpoint count
   uint32_t m_max_hwp_supported = 16;


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
@@ -122,7 +122,7 @@
 int mode;   // Defines if watchpoint is read/write/access.
   };
 
-  std::array m_hwp_regs;
+  std::array m_hwp_regs;
 
   // 16 is just a maximum value, query hardware for actual watchpoint count
   uint32_t m_max_hwp_supported = 16;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 6f59f30 - [lldb] Fix m_hwp_regs size for ppc64le (PR54520)

[Nikita Popov via lldb-commits]

Author: Nikita Popov
Date: 2022-10-18T15:11:21+02:00
New Revision: 6f59f302e4358b4dc869bc298c2b9c06aa716b60

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

LOG: [lldb] Fix m_hwp_regs size for ppc64le (PR54520)

The size of the m_hwp_regs array should match the default value of
m_max_hwp_supported. This ensures that no out-of-bounds accesses
occur, even if the array is accessed prior to a call to
ReadHardwareDebugInfo().

Fixes https://github.com/llvm/llvm-project/issues/54520, see also
there for additional background.

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

Added: 


Modified: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h 
b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
index fac395807796c..942c65fcd241d 100644
--- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
+++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_ppc64le.h
@@ -122,7 +122,7 @@ class NativeRegisterContextLinux_ppc64le : public 
NativeRegisterContextLinux {
 int mode;   // Defines if watchpoint is read/write/access.
   };
 
-  std::array m_hwp_regs;
+  std::array m_hwp_regs;
 
   // 16 is just a maximum value, query hardware for actual watchpoint count
   uint32_t m_max_hwp_supported = 16;



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

[Lldb-commits] [PATCH] D136165: [lldb-tests] Add libcxx version check for regex tests

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve created this revision.
fdeazeve added a reviewer: aprantl.
Herald added a project: All.
fdeazeve requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Regex requires the c++20 flag, which was not introduced available prior
to Clang 11.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136165

Files:
  lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py


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
@@ -20,6 +20,7 @@
 "settings set target.process.thread.step-avoid-regexp 
^ignore::")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 def test_step_avoid_regex(self):
 """Tests stepping into a function which matches the avoid regex"""
 self.build()
@@ -38,6 +39,7 @@
 self.hit_correct_function("main")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 @expectedFailureAll(bugnumber="rdar://100645742")
 def test_step_avoid_regex_abi_tagged_template(self):
 """Tests stepping into an ABI tagged function that matches the avoid 
regex"""


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
@@ -20,6 +20,7 @@
 "settings set target.process.thread.step-avoid-regexp ^ignore::")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 def test_step_avoid_regex(self):
 """Tests stepping into a function which matches the avoid regex"""
 self.build()
@@ -38,6 +39,7 @@
 self.hit_correct_function("main")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 @expectedFailureAll(bugnumber="rdar://100645742")
 def test_step_avoid_regex_abi_tagged_template(self):
 """Tests stepping into an ABI tagged function that matches the avoid regex"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136171: [lldb-tests] Remove dubious standard library flag

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve created this revision.
fdeazeve added a reviewer: aprantl.
Herald added a project: All.
fdeazeve requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

The test currently sets `USE_LIBSTDCPP = 0`, which is curious given the
behavior of `and` and `or` in Makefiles (the contents of the variables
are not important). In particular, this causes the tests to not use the
standard libraries appropriately.

To capture the actual intent of the test, we're changing this to
`USE_LIBCXX=1`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136171

Files:
  
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile


Index: 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
===
--- 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
-USE_LIBSTDCPP := 0
-
-
+USE_LIBCPP := 1
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules


Index: lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
-USE_LIBSTDCPP := 0
-
-
+USE_LIBCPP := 1
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136178: [lldb-tests] Add compiler version check in TestFunctionStarts

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve created this revision.
fdeazeve added reviewers: aprantl, Michael137.
Herald added a project: All.
fdeazeve requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This test requires compiling its input program without debug
information. To do so, it uses certain Makefile variables that are never
populated with custom libcxx paths (if present). Doing so would not
necessarily be correct, since we cannot guaranteed that said standard
library has debug symbols or not.

As such, we keep using the system libraries but to disable the tests in
clang versions that are too old to work with more modern system
libraries, as in the case of the lldb-matrix bot.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136178

Files:
  lldb/test/API/macosx/function-starts/TestFunctionStarts.py


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136178: [lldb-tests] Add compiler version check in TestFunctionStarts

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve updated this revision to Diff 468551.
fdeazeve added a comment.

Fixed typos in commit message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136178

Files:
  lldb/test/API/macosx/function-starts/TestFunctionStarts.py


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136171: [lldb-tests] Remove dubious standard library flag

[Adrian Prantl via Phabricator via lldb-commits]

aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

This looks obviously correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136171

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

[Lldb-commits] [PATCH] D135798: Add runToBinaryEntry option for lldb-vscode

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan updated this revision to Diff 468591.
yinghuitan added a comment.

Use async model.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135798

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/launch/TestVSCode_launch.py
  lldb/tools/lldb-vscode/VSCode.cpp
  lldb/tools/lldb-vscode/VSCode.h
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  lldb/tools/lldb-vscode/package.json

Index: lldb/tools/lldb-vscode/package.json
===
--- lldb/tools/lldb-vscode/package.json
+++ lldb/tools/lldb-vscode/package.json
@@ -157,6 +157,11 @@
 "description": "Automatically stop after launch.",
 "default": false
 			},
+			"runToBinaryEntry": {
+"type": "boolean",
+"description": "run to program entry one-shot breakpoint during launch to ensure dependency modules are loaded.",
+"default": false
+			},
 			"disableASLR": {
 "type": "boolean",
 "description": "Enable or disable Address space layout randomization if the debugger supports it.",
Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1610,6 +1610,68 @@
  error.GetCString());
 }
 
+lldb::SBError RunToBinaryEntry() {
+  lldb::SBError error;
+  if (!g_vsc.run_to_binary_entry)
+return error;
+
+  if (g_vsc.stop_at_entry) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry is ignored due to StopOnEntry\n");
+return error;
+  }
+
+  lldb::SBTarget target = g_vsc.debugger.GetSelectedTarget();
+  if (!target.IsValid())
+return error;
+  lldb::SBFileSpec exe_file = target.GetExecutable();
+  if (!exe_file.IsValid())
+return error;
+  lldb::SBModule exe_module = target.FindModule(exe_file);
+  if (!exe_module.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: invalid executable module\n");
+return error;
+  }
+
+  lldb::SBAddress entry_point = exe_module.GetObjectFileEntryPointAddress();
+  if (!entry_point.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't find entry point\n");
+return error;
+  }
+  lldb::SBBreakpoint entry_breakpoint =
+  target.BreakpointCreateBySBAddress(entry_point);
+  if (!entry_breakpoint.IsValid() || entry_breakpoint.GetNumLocations() == 0) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't place the breakpoint\n");
+return error;
+  }
+
+  uint32_t old_stop_id = target.GetProcess().GetStopID();
+  entry_breakpoint.SetOneShot(true);
+  error = target.GetProcess().Continue();
+  if (error.Fail())
+return error;
+
+  const uint64_t timeout_seconds = 600;
+  error = g_vsc.WaitForProcessToStop(timeout_seconds, old_stop_id);
+  if (error.Fail())
+return error;
+
+  // Successfully got a process stop; we still need to check if the stop is what
+  // we expected.
+  if (entry_breakpoint.GetHitCount() == 0)
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry failed: process stopped not at the "
+ "binary's entry point\n");
+  else
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry success: Process stopped successfully "
+ "at the binary's entry point\n");
+  return error;
+}
+
 // "LaunchRequest": {
 //   "allOf": [ { "$ref": "#/definitions/Request" }, {
 // "type": "object",
@@ -1659,6 +1721,7 @@
   std::vector postRunCommands =
   GetStrings(arguments, "postRunCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  g_vsc.run_to_binary_entry = GetBoolean(arguments, "runToBinaryEntry", false);
   const llvm::StringRef debuggerRoot = GetString(arguments, "debuggerRoot");
   const uint64_t timeout_seconds = GetUnsigned(arguments, "timeout", 30);
 
@@ -1741,6 +1804,9 @@
 error = g_vsc.WaitForProcessToStop(timeout_seconds);
   }
 
+  if (error.Success())
+error = RunToBinaryEntry();
+
   if (error.Fail()) {
 response["success"] = llvm::json::Value(false);
 EmplaceSafeString(response, "message", std::string(error.GetCString()));
Index: lldb/tools/lldb-vscode/VSCode.h
===
--- lldb/tools/lldb-vscode/VSCode.h
+++ lldb/tools/lldb-vscode/VSCode.h
@@ -144,6 +144,7 @@
   lldb::tid_t focus_tid;
   bool sent_terminated_event;
   bool stop_at_entry;
+  bool run_to_binary_entry = false;
   bool is_attach;
   bool configuration_done_sent;
   uint32_t reverse_request_seq;
@@ -261,9 +262,14 @@
   ///

[Lldb-commits] [PATCH] D135798: Add runToBinaryEntry option for lldb-vscode

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan updated this revision to Diff 468592.
yinghuitan added a comment.

Update message per feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135798

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/launch/TestVSCode_launch.py
  lldb/tools/lldb-vscode/VSCode.cpp
  lldb/tools/lldb-vscode/VSCode.h
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  lldb/tools/lldb-vscode/package.json

Index: lldb/tools/lldb-vscode/package.json
===
--- lldb/tools/lldb-vscode/package.json
+++ lldb/tools/lldb-vscode/package.json
@@ -157,6 +157,11 @@
 "description": "Automatically stop after launch.",
 "default": false
 			},
+			"runToBinaryEntry": {
+"type": "boolean",
+"description": "run to program entry one-shot breakpoint during launch to ensure dependency modules are loaded.",
+"default": false
+			},
 			"disableASLR": {
 "type": "boolean",
 "description": "Enable or disable Address space layout randomization if the debugger supports it.",
Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1610,6 +1610,68 @@
  error.GetCString());
 }
 
+lldb::SBError RunToBinaryEntry() {
+  lldb::SBError error;
+  if (!g_vsc.run_to_binary_entry)
+return error;
+
+  if (g_vsc.stop_at_entry) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry is ignored due to StopOnEntry\n");
+return error;
+  }
+
+  lldb::SBTarget target = g_vsc.debugger.GetSelectedTarget();
+  if (!target.IsValid())
+return error;
+  lldb::SBFileSpec exe_file = target.GetExecutable();
+  if (!exe_file.IsValid())
+return error;
+  lldb::SBModule exe_module = target.FindModule(exe_file);
+  if (!exe_module.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: invalid executable module\n");
+return error;
+  }
+
+  lldb::SBAddress entry_point = exe_module.GetObjectFileEntryPointAddress();
+  if (!entry_point.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't find entry point\n");
+return error;
+  }
+  lldb::SBBreakpoint entry_breakpoint =
+  target.BreakpointCreateBySBAddress(entry_point);
+  if (!entry_breakpoint.IsValid() || entry_breakpoint.GetNumLocations() == 0) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't resolve the entry point breakpoint\n");
+return error;
+  }
+
+  uint32_t old_stop_id = target.GetProcess().GetStopID();
+  entry_breakpoint.SetOneShot(true);
+  error = target.GetProcess().Continue();
+  if (error.Fail())
+return error;
+
+  const uint64_t timeout_seconds = 600;
+  error = g_vsc.WaitForProcessToStop(timeout_seconds, old_stop_id);
+  if (error.Fail())
+return error;
+
+  // Successfully got a process stop; we still need to check if the stop is what
+  // we expected.
+  if (entry_breakpoint.GetHitCount() == 0)
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry failed: process stopped not at the "
+ "binary's entry point\n");
+  else
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry success: Process stopped successfully "
+ "at the binary's entry point\n");
+  return error;
+}
+
 // "LaunchRequest": {
 //   "allOf": [ { "$ref": "#/definitions/Request" }, {
 // "type": "object",
@@ -1659,6 +1721,7 @@
   std::vector postRunCommands =
   GetStrings(arguments, "postRunCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  g_vsc.run_to_binary_entry = GetBoolean(arguments, "runToBinaryEntry", false);
   const llvm::StringRef debuggerRoot = GetString(arguments, "debuggerRoot");
   const uint64_t timeout_seconds = GetUnsigned(arguments, "timeout", 30);
 
@@ -1741,6 +1804,9 @@
 error = g_vsc.WaitForProcessToStop(timeout_seconds);
   }
 
+  if (error.Success())
+error = RunToBinaryEntry();
+
   if (error.Fail()) {
 response["success"] = llvm::json::Value(false);
 EmplaceSafeString(response, "message", std::string(error.GetCString()));
Index: lldb/tools/lldb-vscode/VSCode.h
===
--- lldb/tools/lldb-vscode/VSCode.h
+++ lldb/tools/lldb-vscode/VSCode.h
@@ -144,6 +144,7 @@
   lldb::tid_t focus_tid;
   bool sent_terminated_event;
   bool stop_at_entry;
+  bool run_to_binary_entry = false;
   bool is_attach;
   bool configuration_done_sent;
   uint32_t reverse_request_seq;
@@ 

[Lldb-commits] [PATCH] D135798: Add runToBinaryEntry option for lldb-vscode

[jeffrey tan via Phabricator via lldb-commits]

yinghuitan updated this revision to Diff 468593.
yinghuitan added a comment.

format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135798

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/launch/TestVSCode_launch.py
  lldb/tools/lldb-vscode/VSCode.cpp
  lldb/tools/lldb-vscode/VSCode.h
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  lldb/tools/lldb-vscode/package.json

Index: lldb/tools/lldb-vscode/package.json
===
--- lldb/tools/lldb-vscode/package.json
+++ lldb/tools/lldb-vscode/package.json
@@ -157,6 +157,11 @@
 "description": "Automatically stop after launch.",
 "default": false
 			},
+			"runToBinaryEntry": {
+"type": "boolean",
+"description": "run to program entry one-shot breakpoint during launch to ensure dependency modules are loaded.",
+"default": false
+			},
 			"disableASLR": {
 "type": "boolean",
 "description": "Enable or disable Address space layout randomization if the debugger supports it.",
Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1610,6 +1610,68 @@
  error.GetCString());
 }
 
+lldb::SBError RunToBinaryEntry() {
+  lldb::SBError error;
+  if (!g_vsc.run_to_binary_entry)
+return error;
+
+  if (g_vsc.stop_at_entry) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry is ignored due to StopOnEntry\n");
+return error;
+  }
+
+  lldb::SBTarget target = g_vsc.debugger.GetSelectedTarget();
+  if (!target.IsValid())
+return error;
+  lldb::SBFileSpec exe_file = target.GetExecutable();
+  if (!exe_file.IsValid())
+return error;
+  lldb::SBModule exe_module = target.FindModule(exe_file);
+  if (!exe_module.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: invalid executable module\n");
+return error;
+  }
+
+  lldb::SBAddress entry_point = exe_module.GetObjectFileEntryPointAddress();
+  if (!entry_point.IsValid()) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't find entry point\n");
+return error;
+  }
+  lldb::SBBreakpoint entry_breakpoint =
+  target.BreakpointCreateBySBAddress(entry_point);
+  if (!entry_breakpoint.IsValid() || entry_breakpoint.GetNumLocations() == 0) {
+g_vsc.SendOutput(OutputType::Console,
+ "RunToBinaryEntry failed: can't resolve the entry point breakpoint\n");
+return error;
+  }
+
+  uint32_t old_stop_id = target.GetProcess().GetStopID();
+  entry_breakpoint.SetOneShot(true);
+  error = target.GetProcess().Continue();
+  if (error.Fail())
+return error;
+
+  const uint64_t timeout_seconds = 600;
+  error = g_vsc.WaitForProcessToStop(timeout_seconds, old_stop_id);
+  if (error.Fail())
+return error;
+
+  // Successfully got a process stop; we still need to check if the stop is what
+  // we expected.
+  if (entry_breakpoint.GetHitCount() == 0)
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry failed: process stopped not at the "
+ "binary's entry point\n");
+  else
+g_vsc.SendOutput(OutputType::Telemetry,
+ "RunToBinaryEntry success: Process stopped successfully "
+ "at the binary's entry point\n");
+  return error;
+}
+
 // "LaunchRequest": {
 //   "allOf": [ { "$ref": "#/definitions/Request" }, {
 // "type": "object",
@@ -1659,6 +1721,7 @@
   std::vector postRunCommands =
   GetStrings(arguments, "postRunCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  g_vsc.run_to_binary_entry = GetBoolean(arguments, "runToBinaryEntry", false);
   const llvm::StringRef debuggerRoot = GetString(arguments, "debuggerRoot");
   const uint64_t timeout_seconds = GetUnsigned(arguments, "timeout", 30);
 
@@ -1741,6 +1804,9 @@
 error = g_vsc.WaitForProcessToStop(timeout_seconds);
   }
 
+  if (error.Success())
+error = RunToBinaryEntry();
+
   if (error.Fail()) {
 response["success"] = llvm::json::Value(false);
 EmplaceSafeString(response, "message", std::string(error.GetCString()));
Index: lldb/tools/lldb-vscode/VSCode.h
===
--- lldb/tools/lldb-vscode/VSCode.h
+++ lldb/tools/lldb-vscode/VSCode.h
@@ -144,6 +144,7 @@
   lldb::tid_t focus_tid;
   bool sent_terminated_event;
   bool stop_at_entry;
+  bool run_to_binary_entry = false;
   bool is_attach;
   bool configuration_done_sent;
   uint32_t reverse_request_seq;
@@ -261,9 +262,14 @@
   

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

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added a comment.

Could we add a test for this that either uses full-LTO in an API test or some 
assembler code and and lldb-test test?




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:55
 
-  if (debug_aranges->GetNumRanges() == num_debug_aranges) {
+  if (debug_aranges->GetNumRanges() == num_debug_aranges && cu_offset == 0) {
 // We got nothing from the debug info, maybe we have a line tables only

labath wrote:
> This isn't a valid requirement for general code. It essentially means that 
> this code will only run for the first compile unit in an elf file (or, if 
> type units are in use, it may not run at all).
Maybe it's better to filter out skeleton units specifically instead? (If that's 
what the condition is for)



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp:644
+   if (&comp_unit == extra.get())
+ return &m_compile_unit_infos[i];
   }

is std::find() shorter here?



Comment at: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp:1276
 
-return m_compile_unit_infos[cu_idx].compile_unit_sp;
+for (auto &cu : m_compile_unit_infos[cu_idx].extra_compile_units_sps)
+  if (cu->GetID() == dwarf_cu.GetID())

is std::find() shorter / more readable?



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h:180
 lldb::CompUnitSP compile_unit_sp;
+// The rest of the compile units that an object file contains.
+llvm::SmallVector extra_compile_units_sps;

nit: convert these to `///`



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h:181
+// The rest of the compile units that an object file contains.
+llvm::SmallVector extra_compile_units_sps;
 uint32_t first_symbol_index = UINT32_MAX;

Why not only store a llvm::SmallVector and use the first 
element to store compile_unit_sp?


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] [PATCH] D136006: [LLDB][NativePDB] Improve ParseDeclsForContext time.

[Zequan Wu via Phabricator via lldb-commits]

zequanwu added a comment.

In D136006#3864144 , @labath wrote:

> Is this purely a performance optimization, or does it have some impact on 
> operation (its correctness) as well? E.g. does it prevent duplicate 
> construction of some types or something like that?

It's purely a performance optimization. Avoid doing some unnecessary work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136006

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

[Lldb-commits] [lldb] 3c1d8e0 - [lldb-tests] Add compiler version check in TestFunctionStarts

[Felipe de Azevedo Piovezan via lldb-commits]

Author: Felipe de Azevedo Piovezan
Date: 2022-10-18T13:48:26-04:00
New Revision: 3c1d8e06d4a995f8d421ede3cf9240bbddc43441

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

LOG: [lldb-tests] Add compiler version check in TestFunctionStarts

This test requires compiling its input program without debug
information. To do so, it uses certain Makefile variables that are never
populated with custom libcxx paths (if present). Doing so would not
necessarily be correct: we cannot guarantee that said standard library
has no debug symbols.

As such, we keep using the system libraries but disable the tests in
clang versions that are too old to work with more modern system
libraries, as in the case of the lldb-matrix bot.

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

Added: 


Modified: 
lldb/test/API/macosx/function-starts/TestFunctionStarts.py

Removed: 




diff  --git a/lldb/test/API/macosx/function-starts/TestFunctionStarts.py 
b/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
index 9b8ef06ac7eb0..f829c761bbd78 100644
--- a/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ b/lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@ class FunctionStartsTestCase(TestBase):
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
@@ -24,6 +25,7 @@ def test_function_starts_binary(self):
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.



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

[Lldb-commits] [PATCH] D136178: [lldb-tests] Add compiler version check in TestFunctionStarts

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3c1d8e06d4a9: [lldb-tests] Add compiler version check in 
TestFunctionStarts (authored by fdeazeve).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136178

Files:
  lldb/test/API/macosx/function-starts/TestFunctionStarts.py


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped 
later.


Index: lldb/test/API/macosx/function-starts/TestFunctionStarts.py
===
--- lldb/test/API/macosx/function-starts/TestFunctionStarts.py
+++ lldb/test/API/macosx/function-starts/TestFunctionStarts.py
@@ -17,6 +17,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_binary(self):
 """Test that we make synthetic symbols when we have the binary."""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
@@ -24,6 +25,7 @@
 
 @skipIfRemote
 @skipUnlessDarwin
+@skipIf(compiler="clang", compiler_version=['<', '13.0'])
 def test_function_starts_no_binary(self):
 """Test that we make synthetic symbols when we don't have the binary"""
 self.build(dictionary={'CODESIGN': ''}) # Binary is getting stripped later.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 58a25eb - [lldb-tests] Add libcxx version check for regex tests

[Felipe de Azevedo Piovezan via lldb-commits]

Author: Felipe de Azevedo Piovezan
Date: 2022-10-18T13:49:19-04:00
New Revision: 58a25ebb8622ee27034f0c103a9067acda7f6300

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

LOG: [lldb-tests] Add libcxx version check for regex tests

Regex requires the c++20 flag, which was not introduced available prior
to Clang 11.

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

Added: 


Modified: 
lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py 
b/lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
index 781928ab5a440..ffca513886f05 100644
--- a/lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
+++ b/lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py
@@ -20,6 +20,7 @@ def setUp(self):
 "settings set target.process.thread.step-avoid-regexp 
^ignore::")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 def test_step_avoid_regex(self):
 """Tests stepping into a function which matches the avoid regex"""
 self.build()
@@ -38,6 +39,7 @@ def test_step_avoid_regex(self):
 self.hit_correct_function("main")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 @expectedFailureAll(bugnumber="rdar://100645742")
 def test_step_avoid_regex_abi_tagged_template(self):
 """Tests stepping into an ABI tagged function that matches the avoid 
regex"""



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

[Lldb-commits] [PATCH] D136165: [lldb-tests] Add libcxx version check for regex tests

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG58a25ebb8622: [lldb-tests] Add libcxx version check for 
regex tests (authored by fdeazeve).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136165

Files:
  lldb/test/API/functionalities/step-avoids-regexp/TestStepAvoidsRegexp.py


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
@@ -20,6 +20,7 @@
 "settings set target.process.thread.step-avoid-regexp 
^ignore::")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 def test_step_avoid_regex(self):
 """Tests stepping into a function which matches the avoid regex"""
 self.build()
@@ -38,6 +39,7 @@
 self.hit_correct_function("main")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 @expectedFailureAll(bugnumber="rdar://100645742")
 def test_step_avoid_regex_abi_tagged_template(self):
 """Tests stepping into an ABI tagged function that matches the avoid 
regex"""


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
@@ -20,6 +20,7 @@
 "settings set target.process.thread.step-avoid-regexp ^ignore::")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 def test_step_avoid_regex(self):
 """Tests stepping into a function which matches the avoid regex"""
 self.build()
@@ -38,6 +39,7 @@
 self.hit_correct_function("main")
 
 @skipIfWindows
+@skipIf(compiler="clang", compiler_version=['<', '11.0'])
 @expectedFailureAll(bugnumber="rdar://100645742")
 def test_step_avoid_regex_abi_tagged_template(self):
 """Tests stepping into an ABI tagged function that matches the avoid regex"""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f477412 - [lldb-tests] Remove dubious standard library flag

[Felipe de Azevedo Piovezan via lldb-commits]

Author: Felipe de Azevedo Piovezan
Date: 2022-10-18T13:50:31-04:00
New Revision: f477412685fe6bac49d3d080ba91896c28e62116

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

LOG: [lldb-tests] Remove dubious standard library flag

The test currently sets `USE_LIBSTDCPP = 0`, which is curious given the
behavior of `and` and `or` in Makefiles (the contents of the variables
are not important). In particular, this causes the tests to not use the
standard libraries appropriately.

To capture the actual intent of the test, we're changing this to
`USE_LIBCXX=1`.

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

Added: 


Modified: 

lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile

Removed: 




diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
index 6bfb97cd2c2bc..3966839e1f8a0 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
-USE_LIBSTDCPP := 0
-
-
+USE_LIBCPP := 1
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules



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

[Lldb-commits] [PATCH] D136171: [lldb-tests] Remove dubious standard library flag

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf477412685fe: [lldb-tests] Remove dubious standard library 
flag (authored by fdeazeve).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136171

Files:
  
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile


Index: 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
===
--- 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ 
lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
-USE_LIBSTDCPP := 0
-
-
+USE_LIBCPP := 1
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules


Index: lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,7 +1,5 @@
 CXX_SOURCES := main.cpp
-USE_LIBSTDCPP := 0
-
-
+USE_LIBCPP := 1
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 3dfc39d - Revert "[lldb-tests] Remove dubious standard library flag"

[Felipe de Azevedo Piovezan via lldb-commits]

Author: Felipe de Azevedo Piovezan
Date: 2022-10-18T13:59:29-04:00
New Revision: 3dfc39db582b57151c889dd0dbf3d841d0e724c4

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

LOG: Revert "[lldb-tests] Remove dubious standard library flag"

This reverts commit f477412685fe6bac49d3d080ba91896c28e62116.

Added: 


Modified: 

lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile

Removed: 




diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
index 3966839e1f8a0..6bfb97cd2c2bc 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/Makefile
@@ -1,5 +1,7 @@
 CXX_SOURCES := main.cpp
-USE_LIBCPP := 1
+USE_LIBSTDCPP := 0
+
+
 
 CXXFLAGS_EXTRAS := -O0
 include Makefile.rules



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

[Lldb-commits] [PATCH] D136171: [lldb-tests] Remove dubious standard library flag

[Felipe de Azevedo Piovezan via Phabricator via lldb-commits]

fdeazeve added a comment.

This linux bot failed: https://lab.llvm.org/buildbot/#/builders/68/builds/41314
I've reverted while I give it a try in a linux VM. Interestingly, the standard 
library are not being passed correctly according to the log.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136171

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

[Lldb-commits] [lldb] 566146c - [lldb][trace] Add a basic function call dumpdump [1] - Add the command scaffolding

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2022-10-18T13:57:52-07:00
New Revision: 566146c03b054db2530f6b5997dfd0cd1a243657

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

LOG: [lldb][trace] Add a basic function call dumpdump [1] - Add the command 
scaffolding

The command is thread trace dump function-calls and as minimum will
require printing to a file in json and non-json format

I added a test

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

Added: 
lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py

Modified: 
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Commands/Options.td

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index 2a22900793ce5..ae2a8edd12d40 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -2090,6 +2090,113 @@ class CommandObjectTraceStop : public 
CommandObjectMultipleThreads {
   }
 };
 
+static ThreadSP GetSingleThreadFromArgs(ExecutionContext &exe_ctx, Args &args,
+CommandReturnObject &result) {
+  if (args.GetArgumentCount() == 0)
+return exe_ctx.GetThreadSP();
+
+  const char *arg = args.GetArgumentAtIndex(0);
+  uint32_t thread_idx;
+
+  if (!llvm::to_integer(arg, thread_idx)) {
+result.AppendErrorWithFormat("invalid thread specification: \"%s\"\n", 
arg);
+return nullptr;
+  }
+  ThreadSP thread_sp =
+  exe_ctx.GetProcessRef().GetThreadList().FindThreadByIndexID(thread_idx);
+  if (!thread_sp)
+result.AppendErrorWithFormat("no thread with index: \"%s\"\n", arg);
+  return thread_sp;
+}
+
+// CommandObjectTraceDumpFunctionCalls
+#define LLDB_OPTIONS_thread_trace_dump_function_calls
+#include "CommandOptions.inc"
+
+class CommandObjectTraceDumpFunctionCalls : public CommandObjectParsed {
+public:
+  class CommandOptions : public Options {
+  public:
+CommandOptions() { OptionParsingStarting(nullptr); }
+
+~CommandOptions() override = default;
+
+Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
+  ExecutionContext *execution_context) override {
+  Status error;
+  const int short_option = m_getopt_table[option_idx].val;
+
+  switch (short_option) {
+  case 'j': {
+m_json = true;
+break;
+  }
+  case 'J': {
+m_pretty_json = true;
+break;
+  }
+  case 'F': {
+m_output_file.emplace(option_arg);
+break;
+  }
+  default:
+llvm_unreachable("Unimplemented option");
+  }
+  return error;
+}
+
+void OptionParsingStarting(ExecutionContext *execution_context) override {
+  m_json = false;
+  m_pretty_json = false;
+  m_output_file = llvm::None;
+}
+
+llvm::ArrayRef GetDefinitions() override {
+  return llvm::makeArrayRef(g_thread_trace_dump_function_calls_options);
+}
+
+static const size_t kDefaultCount = 20;
+
+// Instance variables to hold the values for command options.
+bool m_json;
+bool m_pretty_json;
+llvm::Optional m_output_file;
+  };
+
+  CommandObjectTraceDumpFunctionCalls(CommandInterpreter &interpreter)
+  : CommandObjectParsed(
+interpreter, "thread trace dump function-calls",
+"Dump the traced function-calls for one thread. If no "
+"thread is specified, the current thread is used.",
+nullptr,
+eCommandRequiresProcess | eCommandRequiresThread |
+eCommandTryTargetAPILock | eCommandProcessMustBeLaunched |
+eCommandProcessMustBePaused | eCommandProcessMustBeTraced) {
+CommandArgumentData thread_arg{eArgTypeThreadIndex, eArgRepeatOptional};
+m_arguments.push_back({thread_arg});
+  }
+
+  ~CommandObjectTraceDumpFunctionCalls() override = default;
+
+  Options *GetOptions() override { return &m_options; }
+
+protected:
+  bool DoExecute(Args &args, CommandReturnObject &result) override {
+ThreadSP thread_sp = GetSingleThreadFromArgs(m_exe_ctx, args, result);
+if (!thread_sp) {
+  result.AppendError("invalid thread\n");
+  return false;
+}
+result.AppendMessageWithFormatv(
+"json = {0}, pretty_json = {1}, file = {2}, thread = {3}",
+m_options.m_json, m_options.m_pretty_json, !!m_options.m_output_file,
+thread_sp->GetID());
+return true;
+  }
+
+  CommandOptions m_options;
+};
+
 // CommandObjectTraceDumpInstructions
 #define LLDB_OPTIONS_thread_trace_dump_instructions
 #include "CommandOptions.inc"
@@ -2238,28 +2345,8 @@ class CommandObjectTraceDumpInstructions : public 
CommandObjectParsed {
   }
 
 protected:
-  ThreadSP GetThread(Args &args, CommandReturnObject &result) 

[Lldb-commits] [PATCH] D135521: [lldb][trace] Add a basic function call dump [1] - Add the command scaffolding

[Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG566146c03b05: [lldb][trace] Add a basic function call 
dumpdump [1] - Add the command… (authored by Walter Erquinigo 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135521

Files:
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/Options.td
  lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py

Index: lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
@@ -0,0 +1,17 @@
+from intelpt_testcase import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+class TestTraceDumpInfo(TraceIntelPTTestCaseBase):
+def testDumpFunctionCalls(self):
+  self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"))
+
+  self.expect("thread trace dump function-calls 2",
+error=True, substrs=['error: no thread with index: "2"'])
+
+  self.expect("thread trace dump function-calls 1 -j",
+substrs=['json = true, pretty_json = false, file = false, thread = 3842849'])
+
+  self.expect("thread trace dump function-calls 1 -F /tmp -J",
+substrs=['false, pretty_json = true, file = true, thread = 3842849'])
Index: lldb/source/Commands/Options.td
===
--- lldb/source/Commands/Options.td
+++ lldb/source/Commands/Options.td
@@ -1093,6 +1093,19 @@
 Desc<"Display thread plans for unreported threads">;
 }
 
+let Command = "thread trace dump function calls" in {
+  def thread_trace_dump_function_calls_file : Option<"file", "F">, Group<1>,
+Arg<"Filename">,
+Desc<"Dump the function calls to a file instead of the standard output.">;
+  def thread_trace_dump_function_calls_json: Option<"json", "j">,
+Group<1>,
+Desc<"Dump in simple JSON format.">;
+  def thread_trace_dump_function_calls_pretty_json: Option<"pretty-json", "J">,
+Group<1>,
+Desc<"Dump in JSON format but pretty printing the output for easier "
+"readability.">;
+}
+
 let Command = "thread trace dump instructions" in {
   def thread_trace_dump_instructions_forwards: Option<"forwards", "f">,
 Group<1>,
Index: lldb/source/Commands/CommandObjectThread.cpp
===
--- lldb/source/Commands/CommandObjectThread.cpp
+++ lldb/source/Commands/CommandObjectThread.cpp
@@ -2090,6 +2090,113 @@
   }
 };
 
+static ThreadSP GetSingleThreadFromArgs(ExecutionContext &exe_ctx, Args &args,
+CommandReturnObject &result) {
+  if (args.GetArgumentCount() == 0)
+return exe_ctx.GetThreadSP();
+
+  const char *arg = args.GetArgumentAtIndex(0);
+  uint32_t thread_idx;
+
+  if (!llvm::to_integer(arg, thread_idx)) {
+result.AppendErrorWithFormat("invalid thread specification: \"%s\"\n", arg);
+return nullptr;
+  }
+  ThreadSP thread_sp =
+  exe_ctx.GetProcessRef().GetThreadList().FindThreadByIndexID(thread_idx);
+  if (!thread_sp)
+result.AppendErrorWithFormat("no thread with index: \"%s\"\n", arg);
+  return thread_sp;
+}
+
+// CommandObjectTraceDumpFunctionCalls
+#define LLDB_OPTIONS_thread_trace_dump_function_calls
+#include "CommandOptions.inc"
+
+class CommandObjectTraceDumpFunctionCalls : public CommandObjectParsed {
+public:
+  class CommandOptions : public Options {
+  public:
+CommandOptions() { OptionParsingStarting(nullptr); }
+
+~CommandOptions() override = default;
+
+Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
+  ExecutionContext *execution_context) override {
+  Status error;
+  const int short_option = m_getopt_table[option_idx].val;
+
+  switch (short_option) {
+  case 'j': {
+m_json = true;
+break;
+  }
+  case 'J': {
+m_pretty_json = true;
+break;
+  }
+  case 'F': {
+m_output_file.emplace(option_arg);
+break;
+  }
+  default:
+llvm_unreachable("Unimplemented option");
+  }
+  return error;
+}
+
+void OptionParsingStarting(ExecutionContext *execution_context) override {
+  m_json = false;
+  m_pretty_json = false;
+  m_output_file = llvm::None;
+}
+
+llvm::ArrayRef GetDefinitions() override {
+  return llvm::makeArrayRef(g_thread_trace_dump_function_calls_options);
+}
+
+static const size_t kDefaultCount = 20;
+
+// Instance variables to hold the values for command options.
+bool m_json;
+bool m_pretty_json;
+llvm::Optional m_output_file;
+  };
+
+  CommandObjectTraceDumpFunctionCalls(CommandInterpreter &interpreter)
+  : CommandObjectParsed(
+interpreter, 

[Lldb-commits] [lldb] f1e6385 - [lldb][trace] Add a basic function call dump [3] - Add a JSON dumper

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2022-10-18T13:57:53-07:00
New Revision: f1e63855b08e366dc9d3bf1d3394a8f5c77ab3a6

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

LOG: [lldb][trace] Add a basic function call dump [3] - Add a JSON dumper

The JSON dumper is very minimalistic. It pretty much only shows the
delimiting instruction IDs of every segment, so that further queries to
the SBCursor can be used to make sense of the data. It's main purpose is
to be serialized somewhat cheaply.

I also renamed untracedSegment to untracedPrefixSegment, in case in the
future we add an untracedSuffixSegment. In any case, this new name is
more explicit, which I like.

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

Added: 


Modified: 
lldb/include/lldb/Target/TraceDumper.h
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Target/TraceDumper.cpp
lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py

Removed: 




diff  --git a/lldb/include/lldb/Target/TraceDumper.h 
b/lldb/include/lldb/Target/TraceDumper.h
index bcbe8e525197..59f88787 100644
--- a/lldb/include/lldb/Target/TraceDumper.h
+++ b/lldb/include/lldb/Target/TraceDumper.h
@@ -92,10 +92,10 @@ class TraceDumper {
   ///   In terms of implementation details, as segment can be represented with
   ///   the beginning and ending instruction IDs from the instruction trace.
   ///
-  ///  UntracedSegment:
+  ///  UntracedPrefixSegment:
   ///   It might happen that we didn't trace the beginning of a function and we
   ///   saw it for the first time as part of a return. As a way to signal these
-  ///   cases, we have a placeholder UntracedSegment class that completes the
+  ///   cases, we have a placeholder UntracedPrefixSegment class that 
completes the
   ///   callgraph.
   ///
   ///  Example:
@@ -119,7 +119,7 @@ class TraceDumper {
   ///
   ///   Notice that we changed the instruction ids because this is a new trace.
   ///   Here, in order to have a somewhat complete tree with good traversal
-  ///   capabilities, we can create an UntracedSegment to signal the portion of
+  ///   capabilities, we can create an UntracedPrefixSegment to signal the 
portion of
   ///   main() that we didn't trace. We don't know if this segment was in fact
   ///   multiple segments with many function calls. We'll never know. The
   ///   resulting tree looks like the following:
@@ -131,7 +131,7 @@ class TraceDumper {
   ///   And in pseudo-code:
   ///
   /// FunctionCall [
-  ///   UntracedSegment {
+  ///   UntracedPrefixSegment {
   /// symbol: main()
   /// nestedCall: FunctionCall [ # this untraced segment has a nested
   /// call
@@ -289,20 +289,20 @@ class TraceDumper {
   FunctionCall &m_owning_call;
 };
 
-class UntracedSegment {
+class UntracedPrefixSegment {
 public:
   /// Note: Untraced segments can only exist if have also seen a traced
   /// segment of the same function call. Thus, we can use those traced
   /// segments if we want symbol information and such.
 
-  UntracedSegment(FunctionCallUP &&nested_call)
+  UntracedPrefixSegment(FunctionCallUP &&nested_call)
   : m_nested_call(std::move(nested_call)) {}
 
   const FunctionCall &GetNestedCall() const;
 
 private:
-  UntracedSegment(const UntracedSegment &) = delete;
-  UntracedSegment &operator=(UntracedSegment const &);
+  UntracedPrefixSegment(const UntracedPrefixSegment &) = delete;
+  UntracedPrefixSegment &operator=(UntracedPrefixSegment const &);
   FunctionCallUP m_nested_call;
 };
 
@@ -346,11 +346,11 @@ class TraceDumper {
 
 /// Create an untraced segment for this call that jumps to the provided
 /// nested call.
-void SetUntracedSegment(FunctionCallUP &&nested_call);
+void SetUntracedPrefixSegment(FunctionCallUP &&nested_call);
 
 /// \return
-///   A optional to the untraced segment of this call.
-const llvm::Optional &GetUntracedSegment() const;
+///   A optional to the untraced prefix segment of this call.
+const llvm::Optional &GetUntracedPrefixSegment() 
const;
 
 /// \return
 ///   A pointer to the parent call. It may be \b nullptr.
@@ -360,7 +360,7 @@ class TraceDumper {
 
   private:
 /// An optional untraced segment that precedes all the traced segments.
-llvm::Optional m_untraced_segment;
+llvm::Optional m_untraced_prefix_segment;
 /// The traced segments in order. We used a deque to prevent moving these
 /// objects when appending to the list, which would happen with vector.
 std::deque m_traced_segments;
@@ -384,8 +384,8 @@ class TraceDumper {
 virtual void TraceItem(const TraceItem &item) = 0;
 
 /// Dump a function call forest.
-virtu

[Lldb-commits] [PATCH] D135917: [lldb][trace] Add a basic function call dump [2] - Implement the reconstruction algorithm

[Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG840d861d6e52: [lldb][trace] Add a basic function call dump 
[2] - Implement the reconstruction… (authored by Walter Erquinigo 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135917

Files:
  lldb/include/lldb/Target/TraceDumper.h
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Target/TraceDumper.cpp
  lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/inline-function/a.out
  lldb/test/API/commands/trace/inline-function/inline.cpp

Index: lldb/test/API/commands/trace/inline-function/inline.cpp
===
--- /dev/null
+++ lldb/test/API/commands/trace/inline-function/inline.cpp
@@ -0,0 +1,18 @@
+__attribute__((always_inline)) inline int mult(int x, int y) {
+  int f = x * y;
+  f++;
+  f *= f;
+  return f;
+}
+
+int foo(int x) {
+  int z = mult(x, x - 1);
+  z++;
+  return z;
+}
+
+int main() {
+  int x = 12;
+  int z = foo(x);
+  return z + x;
+}
Index: lldb/test/API/commands/trace/TestTraceLoad.py
===
--- lldb/test/API/commands/trace/TestTraceLoad.py
+++ lldb/test/API/commands/trace/TestTraceLoad.py
@@ -68,8 +68,8 @@
   "individualCounts": {
 "software disabled tracing": 1,
 "trace synchronization point": 1,
-"HW clock tick": 8,
-"CPU core changed": 1
+"CPU core changed": 1,
+"HW clock tick": 8
   }
 },
 "continuousExecutions": 1,
Index: lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
===
--- lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
+++ lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
@@ -3,15 +3,107 @@
 from lldbsuite.test.decorators import *
 
 class TestTraceDumpInfo(TraceIntelPTTestCaseBase):
-def testDumpFunctionCalls(self):
+def testDumpSimpleFunctionCalls(self):
   self.expect("trace load -v " +
 os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"))
 
   self.expect("thread trace dump function-calls 2",
 error=True, substrs=['error: no thread with index: "2"'])
 
-  self.expect("thread trace dump function-calls 1 -j",
-substrs=['json = true, pretty_json = false, file = false, thread = 3842849'])
+  # We don't support yet JSON
+  self.expect("thread trace dump function-calls 1 -j", substrs=['[]'])
 
-  self.expect("thread trace dump function-calls 1 -F /tmp -J",
-substrs=['false, pretty_json = true, file = true, thread = 3842849'])
+  # We test first some code without function call
+  self.expect("thread trace dump function-calls 1",
+substrs=['''thread #1: tid = 3842849
+
+[call tree #0]
+a.out`main + 4 at main.cpp:2 to 4:0  [1, 22]'''])
+
+def testFunctionCallsWithErrors(self):
+  self.expect("trace load -v " +
+os.path.join(self.getSourceDir(), "intelpt-multi-core-trace", "trace.json"))
+
+  # We expect that tracing errors appear as a different tree
+  self.expect("thread trace dump function-calls 2",
+substrs=['''thread #2: tid = 3497496
+
+[call tree #0]
+m.out`foo() + 65 at multi_thread.cpp:12:21 to 12:21  [4, 19524]
+
+[call tree #1]
+  [19532, 19532]'''])
+
+  self.expect("thread trace dump function-calls 3",
+substrs=['''thread #3: tid = 3497497
+
+[call tree #0]
+m.out`bar() + 30 at multi_thread.cpp:19:3 to 20:6  [5, 61831]
+
+[call tree #1]
+  [61834, 61834]'''])
+
+def testInlineFunctionCalls(self):
+  self.expect("file " + os.path.join(self.getSourceDir(), "inline-function", "a.out"))
+  self.expect("b main") # we'll trace from the beginning of main
+  self.expect("b 17")
+  self.expect("r")
+  self.expect("thread trace start")
+  self.expect("c")
+  self.expect("thread trace dump function-calls",
+substrs=['''[call tree #0]
+a.out`main + 8 at inline.cpp:15:7 to 16:14  [1, 5]
+  a.out`foo(int) at inline.cpp:8:16 to 9:15  [6, 13]
+a.out`foo(int) + 22 [inlined] mult(int, int) at inline.cpp:2:7 to 5:10  [14, 21]
+  a.out`foo(int) + 49 at inline.cpp:9:15 to 12:1  [22, 26]
+a.out`main + 25 at inline.cpp:16:14 to 16:14  [27, 27]'''])
+
+def testIncompleteInlineFunctionCalls(self):
+  self.expect("file " + os.path.join(self.getSourceDir(), "inline-function", "a.out"))
+  self.expect("b 4") # we'll trace from the middle of the inline method
+  self.expect("b 17")
+  self.expect("r")
+  self.expect("thread trace start")
+  self.expect("c")
+  self.expect("thread trace dump function-calls",
+substrs=['''[call tree #0]
+a.out`main
+  a.out`foo(int)
+   

[Lldb-commits] [lldb] 840d861 - [lldb][trace] Add a basic function call dump [2] - Implement the reconstruction algorithm

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2022-10-18T13:57:53-07:00
New Revision: 840d861d6e524637a96fe9b7f6d2d77091521167

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

LOG: [lldb][trace] Add a basic function call dump [2] - Implement the 
reconstruction algorithm

This diff implements the reconstruction algorithm for the call tree and
add tests.

See TraceDumper.h for documentation and explanations.

One important detail is that the tree objects are in TraceDumper, even
though Trace.h is a better home. I'm leaving that as future work.

Another detail is that this code is as slow as dumping the entire
symolicated trace, which is not that bad tbh. The reason is that we use
symbols throughout the algorithm and we are not being careful about
memory and speed. This is also another area for future improvement.

Lastly, I made sure that incomplete traces work, i.e. you start tracing
very deep in the stack or failures randomly appear in the trace.

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

Added: 
lldb/test/API/commands/trace/inline-function/a.out
lldb/test/API/commands/trace/inline-function/inline.cpp

Modified: 
lldb/include/lldb/Target/TraceDumper.h
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Target/TraceDumper.cpp
lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
lldb/test/API/commands/trace/TestTraceLoad.py

Removed: 




diff  --git a/lldb/include/lldb/Target/TraceDumper.h 
b/lldb/include/lldb/Target/TraceDumper.h
index 2936cdcfd7c54..bcbe8e525197a 100644
--- a/lldb/include/lldb/Target/TraceDumper.h
+++ b/lldb/include/lldb/Target/TraceDumper.h
@@ -6,9 +6,9 @@
 //
 
//===--===//
 
-#include "lldb/Target/TraceCursor.h"
-
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/TraceCursor.h"
+#include 
 
 #ifndef LLDB_TARGET_TRACE_INSTRUCTION_DUMPER_H
 #define LLDB_TARGET_TRACE_INSTRUCTION_DUMPER_H
@@ -73,6 +73,304 @@ class TraceDumper {
 llvm::Optional cpu_id;
   };
 
+  /// An object representing a traced function call.
+  ///
+  /// A function call is represented using segments and subcalls.
+  ///
+  /// TracedSegment:
+  ///   A traced segment is a maximal list of consecutive traced instructions
+  ///   that belong to the same function call. A traced segment will end in
+  ///   three possible ways:
+  /// - With a call to a function deeper in the callstack. In this case,
+  /// most of the times this nested call will return
+  ///   and resume with the next segment of this segment's owning function
+  ///   call. More on this later.
+  /// - Abruptly due to end of trace. In this case, we weren't able to 
trace
+  /// the end of this function call.
+  /// - Simply a return higher in the callstack.
+  ///
+  ///   In terms of implementation details, as segment can be represented with
+  ///   the beginning and ending instruction IDs from the instruction trace.
+  ///
+  ///  UntracedSegment:
+  ///   It might happen that we didn't trace the beginning of a function and we
+  ///   saw it for the first time as part of a return. As a way to signal these
+  ///   cases, we have a placeholder UntracedSegment class that completes the
+  ///   callgraph.
+  ///
+  ///  Example:
+  ///   We might have this piece of execution:
+  ///
+  /// main() [offset 0x00 to 0x20] [traced instruction ids 1 to 4]
+  ///   foo()  [offset 0x00 to 0x80] [traced instruction ids 5 to 20] # 
main
+  ///   invoked foo
+  /// main() [offset 0x24 to 0x40] [traced instruction ids 21 to 30]
+  ///
+  ///   In this case, our function main invokes foo. We have 3 segments: main
+  ///   [offset 0x00 to 0x20], foo() [offset 0x00 to 0x80], and main() [offset
+  ///   0x24 to 0x40]. We also have the instruction ids from the corresponding
+  ///   linear instruction trace for each segment.
+  ///
+  ///   But what if we started tracing since the middle of foo? Then we'd have
+  ///   an incomplete trace
+  ///
+  ///   foo() [offset 0x30 to 0x80] [traced instruction ids 1 to 10]
+  /// main() [offset 0x24 to 0x40] [traced instruction ids 11 to 20]
+  ///
+  ///   Notice that we changed the instruction ids because this is a new trace.
+  ///   Here, in order to have a somewhat complete tree with good traversal
+  ///   capabilities, we can create an UntracedSegment to signal the portion of
+  ///   main() that we didn't trace. We don't know if this segment was in fact
+  ///   multiple segments with many function calls. We'll never know. The
+  ///   resulting tree looks like the following:
+  ///
+  /// main() [untraced]
+  ///   foo() [offset 0x30 to 0x80] [traced instruction ids 1 to 10]
+  /// main() [offset 0x24 to 0x40] [

[Lldb-commits] [PATCH] D136034: [lldb][trace] Add a basic function call dump [3] - Add a JSON dumper

[Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf1e63855b08e: [lldb][trace] Add a basic function call dump 
[3] - Add a JSON dumper (authored by Walter Erquinigo ).

Changed prior to commit:
  https://reviews.llvm.org/D136034?vs=468055&id=468691#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136034

Files:
  lldb/include/lldb/Target/TraceDumper.h
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Target/TraceDumper.cpp
  lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py

Index: lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
===
--- lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
+++ lldb/test/API/commands/trace/TestTraceDumpFunctionCalls.py
@@ -10,8 +10,20 @@
   self.expect("thread trace dump function-calls 2",
 error=True, substrs=['error: no thread with index: "2"'])
 
-  # We don't support yet JSON
-  self.expect("thread trace dump function-calls 1 -j", substrs=['[]'])
+  self.expect("thread trace dump function-calls 1 -j",
+substrs=['[{"tracedSegments":[{"firstInstructionId":"1","lastInstructionId":"22"}]}]'])
+
+  self.expect("thread trace dump function-calls 1 -J",
+substrs=['''[
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "1",
+"lastInstructionId": "22"
+  }
+]
+  }
+]'''])
 
   # We test first some code without function call
   self.expect("thread trace dump function-calls 1",
@@ -34,6 +46,26 @@
 [call tree #1]
   [19532, 19532]'''])
 
+  self.expect("thread trace dump function-calls 2 -J",
+substrs=['''[
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "4",
+"lastInstructionId": "19524"
+  }
+]
+  },
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "19532",
+"lastInstructionId": "19532"
+  }
+]
+  }
+]'''])
+
   self.expect("thread trace dump function-calls 3",
 substrs=['''thread #3: tid = 3497497
 
@@ -43,6 +75,26 @@
 [call tree #1]
   [61834, 61834]'''])
 
+  self.expect("thread trace dump function-calls 3 -J",
+substrs=['''[
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "5",
+"lastInstructionId": "61831"
+  }
+]
+  },
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "61834",
+"lastInstructionId": "61834"
+  }
+]
+  }
+]'''])
+
 def testInlineFunctionCalls(self):
   self.expect("file " + os.path.join(self.getSourceDir(), "inline-function", "a.out"))
   self.expect("b main") # we'll trace from the beginning of main
@@ -58,6 +110,42 @@
   a.out`foo(int) + 49 at inline.cpp:9:15 to 12:1  [22, 26]
 a.out`main + 25 at inline.cpp:16:14 to 16:14  [27, 27]'''])
 
+  self.expect("thread trace dump function-calls -J",
+substrs=['''[
+  {
+"tracedSegments": [
+  {
+"firstInstructionId": "1",
+"lastInstructionId": "5",
+"nestedCall": {
+  "tracedSegments": [
+{
+  "firstInstructionId": "6",
+  "lastInstructionId": "13",
+  "nestedCall": {
+"tracedSegments": [
+  {
+"firstInstructionId": "14",
+"lastInstructionId": "21"
+  }
+]
+  }
+},
+{
+  "firstInstructionId": "22",
+  "lastInstructionId": "26"
+}
+  ]
+}
+  },
+  {
+"firstInstructionId": "27",
+"lastInstructionId": "27"
+  }
+]
+  }
+]'''])
+
 def testIncompleteInlineFunctionCalls(self):
   self.expect("file " + os.path.join(self.getSourceDir(), "inline-function", "a.out"))
   self.expect("b 4") # we'll trace from the middle of the inline method
@@ -73,6 +161,38 @@
   a.out`foo(int) + 49 at inline.cpp:9:15 to 12:1  [6, 10]
 a.out`main + 25 at inline.cpp:16:14 to 16:14  [11, 11]'''])
 
+  self.expect("thread trace dump function-calls -J",
+substrs=['''[
+  {
+"untracedPrefixSegment": {
+  "nestedCall": {
+"untracedPrefixSegment": {
+  "nestedCall": {
+"tracedSegments": [
+  {
+"firstInstructionId": "1",
+"lastInstructionId": "5"
+  }
+]
+  }
+},
+"tracedSegments": [
+  {
+"firstInstructionId": "6",
+"lastInstructionId": "10"
+  }
+]
+  }
+},
+"tracedSegments": [
+  {
+"firstInstructionId": "11",
+"lastInstructionId": "11"
+  }
+]
+  }
+]'''])
+
 def testMultifileFunctionCalls(self):
   # This test i

[Lldb-commits] [PATCH] D136207: Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

[Greg Clayton via Phabricator via lldb-commits]

clayborg created this revision.
clayborg added reviewers: labath, JDevlieghere, aadsm, yinghuitan.
Herald added a project: All.
clayborg requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: lldb-commits, sstefan1.
Herald added a project: LLDB.

Prior to this fix, if the compile unit function:

  void CompileUnit::ResolveSymbolContext(const SourceLocationSpec 
&src_location_spec, SymbolContextItem resolve_scope, SymbolContextList 
&sc_list);

was called with a resolve scope that wasn't just eSymbolContextLineEntry, we 
would end up calling:

  line_entry.range.GetBaseAddress().CalculateSymbolContext(&sc, resolve_scope);

This is ok as long as the line entry's base address is able to be resolved back 
to the same information, but there were problems when it didn't. The example I 
found was we have a file with a bad .debug_aranges section where the address to 
compile unit mapping was incomplete. When this happens, the above function call 
to calculate the symbol context would end up matching the module and it would 
NULL out the compile unit and line entry, which means we would fail to set this 
breakpoint. We have many other clients that ask for eSymbolContextEverything as 
the resolve_scope, so all other locations could end up failing as well.

The solutions is to make sure the compile unit matches the current compile unit 
after calling the calculate symbol context. If the compile unit is NULL, then 
we report an error via the module/debugger as this indicates an entry in the 
line table fails to resolve back to any compile unit. If the compile unit is 
not NULL and it differs from the current compile unit, we restore the current 
compile unit and line entry to ensure the call to .CalculateSymbolContext 
doesn't match something completely different, as can easily happen if LTO or 
other link time optimizations are enabled that could end up outlining or 
merging functions.

This patch allows breakpoint succeeding to work as expected and not get short 
circuited by our address lookup logic failing.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136207

Files:
  lldb/source/Symbol/CompileUnit.cpp
  
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py


Index: 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
===
--- 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
+++ 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
@@ -106,6 +106,44 @@
 'Incorrectly resolved a breakpoint using full path "%s" with '
 'debug info that has relative path with matching suffix' % 
(path))
 
+@skipIf(oslist=["windows"])
+@no_debug_info_test
+def test_breakpoints_with_bad_aranges(self):
+"""
+Test that we can set breakpoints in a file that has an invalid
+.debug_aranges. Older versions of LLDB would find a line entry
+in the line table and then would use the start address of the line
+entry to do an address lookup on the entry from the line table. If
+this address to symbol context lookup would fail, due to a bad
+.debug_aranges, it would cause the breakpoint to not get resolved.
+Verify that even in these conditions we are able to resolve a
+breakpoint.
+
+The "bad_aranges.yaml" contains a line table that is:
+
+Line table for /tmp/ab/main.cpp in `a.out
+0x00013f94: /tmp/ab/main.cpp:1
+0x00013fb0: /tmp/ab/main.cpp:2:3
+0x00013fb8: /tmp/ab/main.cpp:2:3
+
+The .debug_aranges has one range for this compile unit that is
+invalid: [0x00023f94-0x00023fb8). This will cause
+the resolving of the addresses to fail.
+"""
+src_dir = self.getSourceDir()
+yaml_path = os.path.join(src_dir, "bad_aranges.yaml")
+yaml_base, ext = os.path.splitext(yaml_path)
+obj_path = self.getBuildArtifact("a.out")
+self.yaml2obj(yaml_path, obj_path)
+
+# Create a target with the object file we just created from YAML
+target = self.dbg.CreateTarget(obj_path)
+src_path = '/tmp/ab/main.cpp'
+bkpt = target.BreakpointCreateByLocation(src_path, 2)
+self.assertTrue(bkpt.GetNumLocations() > 0,
+'Couldn\'t resolve breakpoint using "%s" in executate "%s" with '
+'debug info that has a bad .debug_aranges section' % (src_path, 
self.getBuildArtifact("a.out")))
+
 
 def setUp(self):
 # Call super's setUp().
Index: lldb/source/Symbol/CompileUnit.cpp
===
--- lldb/source/Symbol/CompileUnit.cpp
+++ lldb/source/Symbol/CompileUnit.cpp
@@ -333,8 +333,38

[Lldb-commits] [PATCH] D136207: [lldb] Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Seems reasonable that when resolving the start address of a line entry from CU 
A we get back a line entry in CU B, then there's just something wrong in the 
debug info.  Trying to recover whatever info is recoverable seems worthwhile: 
essentially by falling back to a `resolve_scope` of `eSymbolContextLineEntry`.

However, that does produce a fairly SymbolContext.  Did we ever have a case 
where you can have aSymbolContext with a valid CU & LineEntry that is in no 
function and no block for realz?  I wouldn't be altogether surprised if we had 
code that asks to resolve everything in ResolveSymbolContext and if we get a CU 
& LineEntry back, assumes you've must have a block or function, and uses them 
w/o checking.  I can't think of a good way to defend against this except maybe 
saying explicitly in SymbolContext.h that because of potential bad debug info 
you can't make any assumptions about which entities will get filled in in a 
symbol context.

I also found the first of the two comments you added confusing.




Comment at: lldb/source/Symbol/CompileUnit.cpp:336
 } else {
+  // Doing a reverse address lookup based on the line entry might not be
+  // what we want to do. Why? We might have an address that appears in

This comment seems odd to me.  You say "X might not be something we want to do 
for reason Y" right before you actually do do X.  

The following comment make it seem like you more mean "The address lookup might 
be problematic for reasons A & B which we're going to detect in way C & fix by 
setting the SC by hand, which doesn't really jibe with what the first comment 
said.

The first comment makes me think we shouldn't be calling CalculateSymbolContext 
at all and do something else - it's not clear what that would be, however.  So 
I think it is just confusing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136207

___
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

[Augusto Noronha via Phabricator via lldb-commits]

augusto2112 updated this revision to Diff 468729.
augusto2112 added a comment.
Herald added subscribers: ormris, steven_wu, hiraditya.

Added test, changed DWARFCompileUnit::BuildAddressRangeTable to not stop 
looking at oso ranges at offset 0.


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;
+}
\ No newline at end of file
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);
\ No newline at end of file
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;
+}
\ No newline at end of file
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,30 @@
+"""Test that types defined in shared libraries work correctly."""
+
+
+
+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"))
+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,8 @@
 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;
 uint32_t first_symbol_index = UINT32_MAX;
 uint32_t last_symbol_index = UINT32_MAX;
 uint32_t first_symbol_id = UINT32_MAX;
@@ -182,10 +184,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 +192,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 CalculateNumCompileUn

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

[Augusto Noronha via Phabricator via lldb-commits]

augusto2112 marked 6 inline comments as done.
augusto2112 added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp:644
+   if (&comp_unit == extra.get())
+ return &m_compile_unit_infos[i];
   }

aprantl wrote:
> is std::find() shorter here?
I think it'd be worse, because we're comparing pointers so we'd need to pass in 
a lambda, which would make things more confusing imo (ditto for the next 
comment).


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] [PATCH] D136209: [LLDB][NativePDB] Fix parameter size for member functions LF_MFUNCTION

[Zequan Wu via Phabricator via lldb-commits]

zequanwu created this revision.
zequanwu added reviewers: labath, rnk.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Fix the problem that it was treating member functions as non-member functions
when trying to get the parameter size. This causes some non-parameter variables
showing up in function signature. Suprisingly,
`cantFail(TypeDeserializer::deserializeAs(...))` just sliently
parse it without error and gave the wrong result.

It's hard to test it. This only causes problem when `params_remaining`
is larger than the real parameter size. If it's smaller, we also check
individual local variable's attribute to see it's a parameter. When I trying to
come up with a test, the parameter size is always 0 if we parse LF_MFUNCTION as
LF_PROCEDURE.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136209

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp


Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1897,9 +1897,24 @@
 ProcSym proc(static_cast(sym.kind()));
 cantFail(SymbolDeserializer::deserializeAs(sym, proc));
 CVType signature = m_index->tpi().getType(proc.FunctionType);
-ProcedureRecord sig;
-cantFail(TypeDeserializer::deserializeAs(signature, sig));
-params_remaining = sig.getParameterCount();
+if (signature.kind() == LF_PROCEDURE) {
+  ProcedureRecord sig;
+  if (llvm::Error e = TypeDeserializer::deserializeAs(
+  signature, sig)) {
+llvm::consumeError(std::move(e));
+return 0;
+  }
+  params_remaining = sig.getParameterCount();
+} else if (signature.kind() == LF_MFUNCTION) {
+  MemberFunctionRecord sig;
+  if (llvm::Error e = 
TypeDeserializer::deserializeAs(
+  signature, sig)) {
+llvm::consumeError(std::move(e));
+return 0;
+  }
+  params_remaining = sig.getParameterCount();
+} else
+  return 0;
 break;
   }
   case S_BLOCK32:


Index: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -1897,9 +1897,24 @@
 ProcSym proc(static_cast(sym.kind()));
 cantFail(SymbolDeserializer::deserializeAs(sym, proc));
 CVType signature = m_index->tpi().getType(proc.FunctionType);
-ProcedureRecord sig;
-cantFail(TypeDeserializer::deserializeAs(signature, sig));
-params_remaining = sig.getParameterCount();
+if (signature.kind() == LF_PROCEDURE) {
+  ProcedureRecord sig;
+  if (llvm::Error e = TypeDeserializer::deserializeAs(
+  signature, sig)) {
+llvm::consumeError(std::move(e));
+return 0;
+  }
+  params_remaining = sig.getParameterCount();
+} else if (signature.kind() == LF_MFUNCTION) {
+  MemberFunctionRecord sig;
+  if (llvm::Error e = TypeDeserializer::deserializeAs(
+  signature, sig)) {
+llvm::consumeError(std::move(e));
+return 0;
+  }
+  params_remaining = sig.getParameterCount();
+} else
+  return 0;
 break;
   }
   case S_BLOCK32:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136207: [lldb] Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

[Greg Clayton via Phabricator via lldb-commits]

clayborg updated this revision to Diff 468737.
clayborg added a comment.

Added missing test case file and clarified comments to be more consistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136207

Files:
  lldb/source/Symbol/CompileUnit.cpp
  
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py


Index: 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
===
--- 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
+++ 
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
@@ -106,6 +106,44 @@
 'Incorrectly resolved a breakpoint using full path "%s" with '
 'debug info that has relative path with matching suffix' % 
(path))
 
+@skipIf(oslist=["windows"])
+@no_debug_info_test
+def test_breakpoints_with_bad_aranges(self):
+"""
+Test that we can set breakpoints in a file that has an invalid
+.debug_aranges. Older versions of LLDB would find a line entry
+in the line table and then would use the start address of the line
+entry to do an address lookup on the entry from the line table. If
+this address to symbol context lookup would fail, due to a bad
+.debug_aranges, it would cause the breakpoint to not get resolved.
+Verify that even in these conditions we are able to resolve a
+breakpoint.
+
+The "bad_aranges.yaml" contains a line table that is:
+
+Line table for /tmp/ab/main.cpp in `a.out
+0x00013f94: /tmp/ab/main.cpp:1
+0x00013fb0: /tmp/ab/main.cpp:2:3
+0x00013fb8: /tmp/ab/main.cpp:2:3
+
+The .debug_aranges has one range for this compile unit that is
+invalid: [0x00023f94-0x00023fb8). This will cause
+the resolving of the addresses to fail.
+"""
+src_dir = self.getSourceDir()
+yaml_path = os.path.join(src_dir, "bad_aranges.yaml")
+yaml_base, ext = os.path.splitext(yaml_path)
+obj_path = self.getBuildArtifact("a.out")
+self.yaml2obj(yaml_path, obj_path)
+
+# Create a target with the object file we just created from YAML
+target = self.dbg.CreateTarget(obj_path)
+src_path = '/tmp/ab/main.cpp'
+bkpt = target.BreakpointCreateByLocation(src_path, 2)
+self.assertTrue(bkpt.GetNumLocations() > 0,
+'Couldn\'t resolve breakpoint using "%s" in executate "%s" with '
+'debug info that has a bad .debug_aranges section' % (src_path, 
self.getBuildArtifact("a.out")))
+
 
 def setUp(self):
 # Call super's setUp().
Index: lldb/source/Symbol/CompileUnit.cpp
===
--- lldb/source/Symbol/CompileUnit.cpp
+++ lldb/source/Symbol/CompileUnit.cpp
@@ -335,6 +335,37 @@
 } else {
   line_entry.range.GetBaseAddress().CalculateSymbolContext(&sc,
resolve_scope);
+  // Sometimes debug info is bad and isn't able to resolve the line entry's
+  // address back to the same compile unit and/or line entry. If the 
compile
+  // unit changed, then revert back to just the compile unit and line 
entry.
+  // Prior to this fix, the above code might end up not being able to 
lookup
+  // the address, and then it would clear compile unit and the line entry 
in
+  // the symbol context and the breakpoint would fail to get set even 
though
+  // we have a valid line table entry in this compile unit. The address
+  // lookup can also end up finding another function in another compiler
+  // unit if the DWARF has overlappging address ranges. So if we end up 
with
+  // no compile unit or a different one after the above function call,
+  // revert back to the same results as if resolve_scope was set exactly to
+  // eSymbolContextLineEntry.
+  if (sc.comp_unit != this) {
+if (sc.comp_unit == nullptr && sc.module_sp) {
+  // Only report an error if we don't map back to any compile unit. 
With
+  // link time optimizations, the debug info might have many compile
+  // units that have the same address range due to function outlining
+  // or other link time optimizations. If the compile unit is NULL, 
then
+  // address resolving is completely failing and more deserving of an
+  // error message the user can see.
+  sc.module_sp->ReportError(
+  "unable to resolve a line table file address 0x%" PRIx64 " back "
+  "to a compile unit, please file a bug and attach the address "
+  "and file.", line

[Lldb-commits] [PATCH] D136207: [lldb] Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D136207#3866729 , @jingham wrote:

> Seems reasonable that when resolving the start address of a line entry from 
> CU A we get back a line entry in CU B, then there's just something wrong in 
> the debug info.  Trying to recover whatever info is recoverable seems 
> worthwhile: essentially by falling back to a `resolve_scope` of 
> `eSymbolContextLineEntry`.
>
> However, that does produce a fairly odd SymbolContext.  Did we ever have a 
> case where you can have aSymbolContext with a valid CU & LineEntry that is in 
> no function and no block for realz?  I wouldn't be altogether surprised if we 
> had code that asks to resolve everything in ResolveSymbolContext and if we 
> get a CU & LineEntry back, assumes you must also have a block or function, 
> and uses them w/o checking.  I can't think of a good way to defend against 
> this except maybe saying explicitly in SymbolContext.h that because of 
> potential bad debug info you can't make any assumptions about which entities 
> will get filled in in a symbol context.
>
> I also found the first of the two comments you added confusing.

I didn't mean to leave the first comment it actually. When I first figured out 
the root cause I put that in there. Let me know if the current state of the 
comments makes more sense


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136207

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

[Lldb-commits] [PATCH] D136207: [lldb] Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

[Greg Clayton via Phabricator via lldb-commits]

clayborg updated this revision to Diff 468738.
clayborg added a comment.

Added missing file for real this time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136207

Files:
  lldb/source/Symbol/CompileUnit.cpp
  
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py
  lldb/test/API/functionalities/breakpoint/breakpoint_command/bad_aranges.yaml

Index: lldb/test/API/functionalities/breakpoint/breakpoint_command/bad_aranges.yaml
===
--- /dev/null
+++ lldb/test/API/functionalities/breakpoint/breakpoint_command/bad_aranges.yaml
@@ -0,0 +1,445 @@
+--- !mach-o
+FileHeader:
+  magic:   0xFEEDFACF
+  cputype: 0x10C
+  cpusubtype:  0x0
+  filetype:0xA
+  ncmds:   7
+  sizeofcmds:  1240
+  flags:   0x0
+  reserved:0x0
+LoadCommands:
+  - cmd: LC_UUID
+cmdsize: 24
+uuid:030921EA-6D76-3A68-B515-386B9AF6D568
+  - cmd: LC_BUILD_VERSION
+cmdsize: 24
+platform:1
+minos:   786432
+sdk: 787200
+ntools:  0
+  - cmd: LC_SYMTAB
+cmdsize: 24
+symoff:  4096
+nsyms:   2
+stroff:  4128
+strsize: 28
+  - cmd: LC_SEGMENT_64
+cmdsize: 72
+segname: __PAGEZERO
+vmaddr:  0
+vmsize:  4294967296
+fileoff: 0
+filesize:0
+maxprot: 0
+initprot:0
+nsects:  0
+flags:   0
+  - cmd: LC_SEGMENT_64
+cmdsize: 232
+segname: __TEXT
+vmaddr:  4294967296
+vmsize:  16384
+fileoff: 0
+filesize:0
+maxprot: 5
+initprot:5
+nsects:  2
+flags:   0
+Sections:
+  - sectname:__text
+segname: __TEXT
+addr:0x13F94
+size:36
+offset:  0x0
+align:   2
+reloff:  0x0
+nreloc:  0
+flags:   0x8400
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+content: CFFAEDFE0C010A000700D8041B00
+  - sectname:__unwind_info
+segname: __TEXT
+addr:0x13FB8
+size:72
+offset:  0x0
+align:   2
+reloff:  0x0
+nreloc:  0
+flags:   0x0
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+content: CFFAEDFE0C010A000700D8041B001800030921EA6D763A68B515386B9AF6D5683200180001000C00
+  - cmd: LC_SEGMENT_64
+cmdsize: 72
+segname: __LINKEDIT
+vmaddr:  4294983680
+vmsize:  4096
+fileoff: 4096
+filesize:60
+maxprot: 1
+initprot:1
+nsects:  0
+flags:   0
+  - cmd: LC_SEGMENT_64
+cmdsize: 792
+segname: __DWARF
+vmaddr:  4294987776
+vmsize:  4096
+fileoff: 8192
+filesize:796
+maxprot: 7
+initprot:3
+nsects:  9
+flags:   0
+Sections:
+  - sectname:__debug_line
+segname: __DWARF
+addr:0x15000
+size:64
+offset:  0x2000
+align:   0
+reloff:  0x0
+nreloc:  0
+flags:   0x0
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+  - sectname:__debug_aranges
+segname: __DWARF
+addr:0x15040
+size:48
+offset:  0x2040
+align:   0
+reloff:  0x0
+nreloc:  0
+flags:   0x0
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+  - sectname:__debug_info
+segname: __DWARF
+addr:0x15070
+size:148
+offset:  0x2070
+align:   0
+reloff:  0x0
+nreloc:  0
+flags:   0x0
+reserved1:   0x0
+reserved2:   0x0
+reserved3:   0x0
+  - sectname:__debug_abbrev
+segname: __DWARF
+addr:0x15104
+size:90
+offset:  0x2104
+align: 

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

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp:1270
+  
+for (auto &cu : m_compile_unit_infos[cu_idx].compile_units_sps)
+  if (cu->GetID() == dwarf_cu.GetID())

This is technically a O(n^2) algorithm. What do you think about adding a 
`SmallDenseMap` into compile_unit_infos?



Comment at: lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py:1
+"""Test that types defined in shared libraries work correctly."""
+

I think this docstring looks copied&pasted?
`test that debugging from object files with multiple compile units works`.





Comment at: lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py:13
+
+@skipIf(compiler=no_match("clang"))
+def test(self):

You might want to mark the test as `@skipUnlessDarwin` since it's about debug 
maps.



Comment at: lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py:26
+# Check that we start out in main.
+self.assertEqual(name, 'main')
+thread.StepInto()

If you use `lldbutil.run_to_name_breakpoint` I think you can delete most of the 
setup code?


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] [PATCH] D136011: [lldb] Don't check environment default char signedness when creating clang type for "char"

[Arthur Eubanks via Phabricator via lldb-commits]

aeubanks 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.

Maybe looking for a "char" entry and setting `ast.getLangOpts().CharIsSigned` 
from it would probably work in most cases, but not sure that it's worth the 
effort. Rendering the wrong signedness for chars doesn't seem like the worst 
thing, and this patch improves things (as the removed `expectedFailureAll` 
show, plus this helps with some testing of lldb I've been doing). I can add a 
TODO if you'd like.

>> I'm curious why there were all those expected failures re: PR23069. Were 
>> they not using the default char signedness? Or is the test using explicit 
>> signedness, and so whatever platforms happen not to have the explicit value 
>> sa their default are/were failing?
>
> Yes, I'm pretty sure that's the case.
>
> In D136011#3861792 , @DavidSpickett 
> wrote:
>
>>> With -f(un)signed-char, the die corresponding to "char" may be the wrong 
>>> DW_ATE_(un)signed_char.
>>
>> As the producer of the DWARF (so, clang for example) is this correct by the 
>> existing rules?
>
> Yes, because DWARF never expected people will be round-tripping the debug 
> info back into C(++). As far as it is concerned, it has correctly given you 
> the signedness of the type.

"wrong" is inaccurate, I've updated the summary


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

[Augusto Noronha via Phabricator via lldb-commits]

augusto2112 updated this revision to Diff 468750.
augusto2112 marked an inline comment as done.
augusto2112 added a comment.

Add a map from compile unit id to index in vector.


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() overri

[Lldb-commits] [PATCH] D136209: [LLDB][NativePDB] Fix parameter size for member functions LF_MFUNCTION

[Reid Kleckner via Phabricator via lldb-commits]

rnk added a comment.

Right, so `cantFail` must be an assertions-only check. That's not great. These 
deserialization APIs have really, really bad ergonomics and could use a lot of 
improvement if you want to look into that.

It would be really nice if, for example, this worked more like dyn_cast. 
Consider this kind of code:

  CVType signature;
  NewTypeMatcher d(signature);
  if (auto *sig = d.getAs()) {
 ... handle ProcedureRecord
  } else if (auto *sig = d.getAs()) {
... handle MemberFunctionRecord
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136209

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