date:20210208

[Lldb-commits] [lldb] 9abd8c1 - [elf-core] Improve reading memory from core file

2021-02-08 Thread Djordje Todorovic via lldb-commits


Author: Djordje Todorovic
Date: 2021-02-08T00:14:32-08:00
New Revision: 9abd8c1a4c3870f2831ee805cd3c0cec516a1c17

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

LOG: [elf-core] Improve reading memory from core file

This patch tries to improve memory-read from core files
(in order to improve disassembly functionality).

I am using RHEL 7.7 (linux kernel 3.10) and for a lot of cases,
I was not able to disassemble some functions from backtrace when
debugging crashes from core files. It outputs some dummy code.

The cause of the problem was the fact we are returning all the zeros
from ProcessElfCore::ReadMemory() that is being called within
Disassembler::ParseInstructions() and it disassembles some dummy
opcodes from the buffer returned. Therefore, we are removing zero
bytes filling (padding) completely.

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

Added: 


Modified: 
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py

Removed: 




diff  --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index ae19367ca3ae..9896638fa8ff 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -353,7 +353,6 @@ size_t ProcessElfCore::DoReadMemory(lldb::addr_t addr, void 
*buf, size_t size,
   const lldb::addr_t file_end = address_range->data.GetRangeEnd();
   size_t bytes_to_read = size; // Number of bytes to read from the core file
   size_t bytes_copied = 0;   // Number of bytes actually read from the core 
file
-  size_t zero_fill_size = 0; // Padding
   lldb::addr_t bytes_left =
   0; // Number of bytes available in the core file from the given address
 
@@ -367,24 +366,15 @@ size_t ProcessElfCore::DoReadMemory(lldb::addr_t addr, 
void *buf, size_t size,
   if (file_end > file_start + offset)
 bytes_left = file_end - (file_start + offset);
 
-  // Figure out how many bytes we need to zero-fill if we are reading more
-  // bytes than available in the on-disk segment
-  if (bytes_to_read > bytes_left) {
-zero_fill_size = bytes_to_read - bytes_left;
+  if (bytes_to_read > bytes_left)
 bytes_to_read = bytes_left;
-  }
 
   // If there is data available on the core file read it
   if (bytes_to_read)
 bytes_copied =
 core_objfile->CopyData(offset + file_start, bytes_to_read, buf);
 
-  assert(zero_fill_size <= size);
-  // Pad remaining bytes
-  if (zero_fill_size)
-memset(((char *)buf) + bytes_copied, 0, zero_fill_size);
-
-  return bytes_copied + zero_fill_size;
+  return bytes_copied;
 }
 
 void ProcessElfCore::Clear() {

diff  --git 
a/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py 
b/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
index 162503c33d37..f3edf4b82bcd 100644
--- a/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ b/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -155,6 +155,24 @@ def test_two_cores_same_pid(self):
 self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions,
  "a.out")
 
+
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+@skipIfReproducer
+def test_read_memory(self):
+"""Test that we are able to read as many bytes as available"""
+target = self.dbg.CreateTarget("linux-x86_64.out")
+process = target.LoadCore("linux-x86_64.core")
+self.assertTrue(process, PROCESS_IS_VALID)
+
+error = lldb.SBError()
+bytesread = process.ReadMemory(0x400ff0, 20, error)
+
+# read only 16 bytes without zero bytes filling
+self.assertEqual(len(bytesread), 16)
+self.dbg.DeleteTarget(target)
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("X86")
 def test_FPR_SSE(self):



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

[Lldb-commits] [PATCH] D93939: [elf-core] Improve reading memory from core file

2021-02-08 Thread Djordje Todorovic via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9abd8c1a4c38: [elf-core] Improve reading memory from core 
file (authored by djtodoro).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93939

Files:
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py


Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -155,6 +155,24 @@
 self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions,
  "a.out")
 
+
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+@skipIfReproducer
+def test_read_memory(self):
+"""Test that we are able to read as many bytes as available"""
+target = self.dbg.CreateTarget("linux-x86_64.out")
+process = target.LoadCore("linux-x86_64.core")
+self.assertTrue(process, PROCESS_IS_VALID)
+
+error = lldb.SBError()
+bytesread = process.ReadMemory(0x400ff0, 20, error)
+
+# read only 16 bytes without zero bytes filling
+self.assertEqual(len(bytesread), 16)
+self.dbg.DeleteTarget(target)
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("X86")
 def test_FPR_SSE(self):
Index: lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -353,7 +353,6 @@
   const lldb::addr_t file_end = address_range->data.GetRangeEnd();
   size_t bytes_to_read = size; // Number of bytes to read from the core file
   size_t bytes_copied = 0;   // Number of bytes actually read from the core 
file
-  size_t zero_fill_size = 0; // Padding
   lldb::addr_t bytes_left =
   0; // Number of bytes available in the core file from the given address
 
@@ -367,24 +366,15 @@
   if (file_end > file_start + offset)
 bytes_left = file_end - (file_start + offset);
 
-  // Figure out how many bytes we need to zero-fill if we are reading more
-  // bytes than available in the on-disk segment
-  if (bytes_to_read > bytes_left) {
-zero_fill_size = bytes_to_read - bytes_left;
+  if (bytes_to_read > bytes_left)
 bytes_to_read = bytes_left;
-  }
 
   // If there is data available on the core file read it
   if (bytes_to_read)
 bytes_copied =
 core_objfile->CopyData(offset + file_start, bytes_to_read, buf);
 
-  assert(zero_fill_size <= size);
-  // Pad remaining bytes
-  if (zero_fill_size)
-memset(((char *)buf) + bytes_copied, 0, zero_fill_size);
-
-  return bytes_copied + zero_fill_size;
+  return bytes_copied;
 }
 
 void ProcessElfCore::Clear() {


Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -155,6 +155,24 @@
 self.do_test("linux-x86_64", self._x86_64_pid, self._x86_64_regions,
  "a.out")
 
+
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+@skipIfReproducer
+def test_read_memory(self):
+"""Test that we are able to read as many bytes as available"""
+target = self.dbg.CreateTarget("linux-x86_64.out")
+process = target.LoadCore("linux-x86_64.core")
+self.assertTrue(process, PROCESS_IS_VALID)
+
+error = lldb.SBError()
+bytesread = process.ReadMemory(0x400ff0, 20, error)
+
+# read only 16 bytes without zero bytes filling
+self.assertEqual(len(bytesread), 16)
+self.dbg.DeleteTarget(target)
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("X86")
 def test_FPR_SSE(self):
Index: lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -353,7 +353,6 @@
   const lldb::addr_t file_end = address_range->data.GetRangeEnd();
   size_t bytes_to_read = size; // Number of bytes to read from the core file
   size_t bytes_copied = 0;   // Number of bytes actually read from the core file
-  size_t zero_fill_size = 0; // Padding
   lldb::addr_t bytes_left =
   0; // Number of bytes available in the core file from the given address
 
@@ -367,24 +366,15 @@
   if (file_end > file_start + offset)
 bytes_left = file_end - (file_start + offset);
 
-  // Fi

[Lldb-commits] [lldb] bec6b5e - [LLDB] Disable TestExprsChar.py, still fails on Arm/Linux

2021-02-08 Thread Muhammad Omair Javaid via lldb-commits


Author: Muhammad Omair Javaid
Date: 2021-02-08T14:05:36+05:00
New Revision: bec6b5e3cec71a9560cc761fd7804f354c3aca02

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

LOG: [LLDB] Disable TestExprsChar.py, still fails on Arm/Linux

TestExprsChar.py was enabled on Arm as it passes on apple silicon but
still fails on Arm/Linux.

Added: 


Modified: 
lldb/test/API/commands/expression/char/TestExprsChar.py

Removed: 




diff  --git a/lldb/test/API/commands/expression/char/TestExprsChar.py 
b/lldb/test/API/commands/expression/char/TestExprsChar.py
index e2229a074d3f..a7f37e868b4d 100644
--- a/lldb/test/API/commands/expression/char/TestExprsChar.py
+++ b/lldb/test/API/commands/expression/char/TestExprsChar.py
@@ -20,6 +20,7 @@ def do_test(self, dictionary=None):
 def test_default_char(self):
 self.do_test()
 
+@skipIf(oslist=["linux"], archs=["arm"], bugnumber="llvm.org/pr23069")
 @expectedFailureAll(
 archs=[
 "aarch64",



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

[Lldb-commits] [lldb] 8561ad9 - Use remote regnums in expedited list, value regs and invalidate regs

2021-02-08 Thread Muhammad Omair Javaid via lldb-commits


Author: Muhammad Omair Javaid
Date: 2021-02-08T14:09:15+05:00
New Revision: 8561ad9296b70b5a2af1574a1576090520d62a7c

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

LOG: Use remote regnums in expedited list, value regs and invalidate regs

Native register descriptions in LLDB specify lldb register numbers in
value_regs and invalidate_regs lists. These register numbers may not
match with Process gdb-remote register numbers which are generated by
native process after counting all registers in its register sets.

It was coincidentally not causing any problems as we never came across
a native target with dynamically changing register sets and register
numbers generated by counter matched with LLDB native register numbers.
This came up while testing target AArch64 SVE which can choose register
sets based on underlying hardware.

This patch fixes this behavior and always tries to use remote register
numbers while reading/writing registers over gdb-remote protocol.

Reviewed By: labath

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

Added: 
lldb/test/API/functionalities/gdb_remote_client/TestRemoteRegNums.py

Modified: 
lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp 
b/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
index 5463a071503c..a85d7bd6f525 100644
--- a/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
+++ b/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
@@ -697,6 +697,14 @@ RegisterInfo 
*DynamicRegisterInfo::GetRegisterInfoAtIndex(uint32_t i) {
   return nullptr;
 }
 
+const RegisterInfo *DynamicRegisterInfo::GetRegisterInfo(uint32_t kind,
+ uint32_t num) const {
+  uint32_t reg_index = ConvertRegisterKindToRegisterNumber(kind, num);
+  if (reg_index != LLDB_INVALID_REGNUM)
+return &m_regs[reg_index];
+  return nullptr;
+}
+
 const RegisterSet *DynamicRegisterInfo::GetRegisterSet(uint32_t i) const {
   if (i < m_sets.size())
 return &m_sets[i];

diff  --git a/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h 
b/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
index fbf9db685b71..7e90454c6d9d 100644
--- a/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
+++ b/lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
@@ -60,6 +60,9 @@ class DynamicRegisterInfo {
   uint32_t ConvertRegisterKindToRegisterNumber(uint32_t kind,
uint32_t num) const;
 
+  const lldb_private::RegisterInfo *GetRegisterInfo(uint32_t kind,
+uint32_t num) const;
+
   void Dump() const;
 
   void Clear();

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index 10006616b0c6..b607b156d7b4 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -249,7 +249,8 @@ bool GDBRemoteRegisterContext::ReadRegisterBytes(const 
RegisterInfo *reg_info,
   break;
 // We have a valid primordial register as our constituent. Grab the
 // corresponding register info.
-const RegisterInfo *prim_reg_info = GetRegisterInfoAtIndex(prim_reg);
+const RegisterInfo *prim_reg_info =
+GetRegisterInfo(eRegisterKindProcessPlugin, prim_reg);
 if (prim_reg_info == nullptr)
   success = false;
 else {
@@ -395,7 +396,8 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
   break;
 // We have a valid primordial register as our constituent. Grab the
 // corresponding register info.
-const RegisterInfo *value_reg_info = GetRegisterInfoAtIndex(reg);
+const RegisterInfo *value_reg_info =
+GetRegisterInfo(eRegisterKindProcessPlugin, reg);
 if (value_reg_info == nullptr)
   success = false;
 else
@@ -414,9 +416,10 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
 if (reg_info->invalidate_regs) {
   for (uint32_t idx = 0, reg = reg_info->invalidate_regs[0];
reg != LLDB_INVALID_REGNUM;
-   reg = reg_info->invalidate_regs[++idx]) {
-SetRegisterIsValid(reg, false);
-  }
+   reg = reg_info->invalidate

[Lldb-commits] [PATCH] D77043: Use remote regnums in expedited list, value regs and invalidate regs

2021-02-08 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8561ad9296b7: Use remote regnums in expedited list, value 
regs and invalidate regs (authored by omjavaid).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77043

Files:
  lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.cpp
  lldb/source/Plugins/Process/Utility/DynamicRegisterInfo.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestRemoteRegNums.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestRemoteRegNums.py
===
--- /dev/null
+++ lldb/test/API/functionalities/gdb_remote_client/TestRemoteRegNums.py
@@ -0,0 +1,126 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+# This test case checks for register number mismatch between lldb and gdb stub.
+# LLDB client assigns register numbers to target xml registers in increasing
+# order starting with regnum = 0, while gdb-remote may specify different regnum
+# which is stored as eRegisterKindProcessPlugin. Remote side will use its
+# register number in expedited register list, value_regs and invalidate_regnums.
+#
+# This test creates a ficticious target xml with non-sequential regnums to test
+# that correct registers are accessed in all of above mentioned cases.
+
+class TestRemoteRegNums(GDBRemoteTestBase):
+
+@skipIfXmlSupportMissing
+def test(self):
+class MyResponder(MockGDBServerResponder):
+def haltReason(self):
+return "T02thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:00bc01000100;09:c04825ebfe7f;"
+
+def threadStopInfo(self, threadnum):
+return "T02thread:1ff0d;threads:1ff0d;thread-pcs:00010001bc00;00:00bc01000100;09:c04825ebfe7f;"
+
+def writeRegisters(self):
+return "E02"
+
+def readRegisters(self):
+return "E01"
+
+rax_regnum2_val = "7882773ce0ff"
+rbx_regnum4_val = "1122334455667788"
+
+def readRegister(self, regnum):
+# lldb will try sending "p0" to see if the p packet is supported,
+# give a bogus value; in theory lldb could use this value in the
+# register context and that would be valid behavior.
+
+# notably, don't give values for registers 1 & 3 -- lldb should
+# get those from the ? stop packet ("T11") and it is a pref regression
+# if lldb is asking for these register values.
+if regnum == 0:
+return ""
+if regnum == 2:
+return self.rax_regnum2_val
+if regnum == 4:
+return self.rbx_regnum4_val
+
+return "E03"
+
+def writeRegister(self, regnum, value_hex):
+if regnum == 2:
+self.rax_regnum2_val = value_hex
+if regnum == 4:
+self.rbx_regnum4_val = value_hex
+
+return "OK"
+
+def qXferRead(self, obj, annex, offset, length):
+if annex == "target.xml":
+return """
+
+  i386:x86-64
+  
+
+
+
+
+
+
+  
+""", False
+else:
+return None, False
+
+self.server.responder = MyResponder()
+target = self.dbg.CreateTarget('')
+if self.TraceOn():
+self.runCmd("log enable gdb-remote packets")
+self.addTearDownHook(
+lambda: self.runCmd("log disable gdb-remote packets"))
+process = self.connect(target)
+
+thread = process.GetThreadAtIndex(0)
+frame = thread.GetFrameAtIndex(0)
+rax = frame.FindRegister("rax").GetValueAsUnsigned()
+eax = frame.FindRegister("eax").GetValueAsUnsigned()
+rbx = frame.FindRegister("rbx").GetValueAsUnsigned()
+ebx = frame.FindRegister("ebx").GetValueAsUnsigned()
+rsi = frame.FindRegister("rsi").GetValueAsUnsigned()
+pc = frame.GetPC()
+rip = frame.FindRegister("rip").GetValueAsUnsigned()
+
+if self.TraceOn():
+print("Register values: rax == 0x%x, rbx == 0x%x, rsi == 0x%x, pc == 0x%x, rip == 0x%x" % (
+rax, rbx, rsi, pc, rip))
+
+

[Lldb-commits] [lldb] d813c37 - [LLDB] Fix buildbot regression in symbol-binding.test

2021-02-08 Thread Muhammad Omair Javaid via lldb-commits


Author: Muhammad Omair Javaid
Date: 2021-02-08T15:20:39+05:00
New Revision: d813c37fc7ce507e008bdee1fc1726a57bc76df5

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

LOG: [LLDB] Fix buildbot regression in symbol-binding.test

This patch fixes regression in symbol-binding.test due to change in
symbol order.

Added: 


Modified: 
lldb/test/Shell/SymbolFile/symbol-binding.test

Removed: 




diff  --git a/lldb/test/Shell/SymbolFile/symbol-binding.test 
b/lldb/test/Shell/SymbolFile/symbol-binding.test
index ce8a5af4c880..9bf6acfeae85 100644
--- a/lldb/test/Shell/SymbolFile/symbol-binding.test
+++ b/lldb/test/Shell/SymbolFile/symbol-binding.test
@@ -11,11 +11,11 @@ image lookup --address 6
 image dump symtab
 # CHECK: Index   UserID DSX TypeFile Address/Value Load 
Address   Size   Flags  Name
 # CHECK-NEXT:--- -- --- --- -- 
-- -- -- 
--
-# CHECK-NEXT:[0]  1 Code0x0004 
   0x0001 0x case1_local
-# CHECK-NEXT:[1]  2 Code0x0005 
   0x0001 0x case2_local
+# CHECK-NEXT:[0]  1 Code0x0001 
   0x0002 0x sizeless
+# CHECK-NEXT:[1]  2 Code0x0001 
   0x0002 0x sizeful
 # CHECK-NEXT:[2]  3 Code0x0003 
   0x0001 0x sizeend
-# CHECK-NEXT:[3]  4 Code0x0001 
   0x0002 0x sizeful
-# CHECK-NEXT:[4]  5 Code0x0001 
   0x0002 0x sizeless
+# CHECK-NEXT:[3]  4 Code0x0004 
   0x0001 0x case1_local
+# CHECK-NEXT:[4]  5 Code0x0005 
   0x0001 0x case2_local
 # CHECK-NEXT:[5]  6   X Code0x0004 
   0x0001 0x0010 case1_global
 # CHECK-NEXT:[6]  7 Code0x0005 
   0x0001 0x0020 case2_weak
 # CHECK-NEXT:[7]  8   X Code0x0006 
   0x0001 0x0010 case3_global



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

[Lldb-commits] [PATCH] D96254: [ELFObjectWriter] Fix `symbol-binding.test` to conform to unsorted local symbols

2021-02-08 Thread Frederik Gossen via Phabricator via lldb-commits

frgossen created this revision.
frgossen requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Commit 980d28d9556a 
 
(ELFObjectWriter: Don't sort local symbols) caused
`symbol-binding.test` to fail (see
http://lab.llvm.org:8011/#/builders/96/builds/4268).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96254

Files:
  lldb/test/Shell/SymbolFile/symbol-binding.test


Index: lldb/test/Shell/SymbolFile/symbol-binding.test
===
--- lldb/test/Shell/SymbolFile/symbol-binding.test
+++ lldb/test/Shell/SymbolFile/symbol-binding.test
@@ -11,11 +11,11 @@
 image dump symtab
 # CHECK: Index   UserID DSX TypeFile Address/Value Load 
Address   Size   Flags  Name
 # CHECK-NEXT:--- -- --- --- -- 
-- -- -- 
--
-# CHECK-NEXT:[0]  1 Code0x0004 
   0x0001 0x case1_local
-# CHECK-NEXT:[1]  2 Code0x0005 
   0x0001 0x case2_local
+# CHECK-NEXT:[0]  1 Code0x0001 
   0x0002 0x sizeless
+# CHECK-NEXT:[1]  2 Code0x0001 
   0x0002 0x sizeful
 # CHECK-NEXT:[2]  3 Code0x0003 
   0x0001 0x sizeend
-# CHECK-NEXT:[3]  4 Code0x0001 
   0x0002 0x sizeful
-# CHECK-NEXT:[4]  5 Code0x0001 
   0x0002 0x sizeless
+# CHECK-NEXT:[3]  4 Code0x0004 
   0x0001 0x case1_local
+# CHECK-NEXT:[4]  5 Code0x0005 
   0x0001 0x case2_local
 # CHECK-NEXT:[5]  6   X Code0x0004 
   0x0001 0x0010 case1_global
 # CHECK-NEXT:[6]  7 Code0x0005 
   0x0001 0x0020 case2_weak
 # CHECK-NEXT:[7]  8   X Code0x0006 
   0x0001 0x0010 case3_global


Index: lldb/test/Shell/SymbolFile/symbol-binding.test
===
--- lldb/test/Shell/SymbolFile/symbol-binding.test
+++ lldb/test/Shell/SymbolFile/symbol-binding.test
@@ -11,11 +11,11 @@
 image dump symtab
 # CHECK: Index   UserID DSX TypeFile Address/Value Load Address   Size   Flags  Name
 # CHECK-NEXT:--- -- --- --- -- -- -- -- --
-# CHECK-NEXT:[0]  1 Code0x00040x0001 0x case1_local
-# CHECK-NEXT:[1]  2 Code0x00050x0001 0x case2_local
+# CHECK-NEXT:[0]  1 Code0x00010x0002 0x sizeless
+# CHECK-NEXT:[1]  2 Code0x00010x0002 0x sizeful
 # CHECK-NEXT:[2]  3 Code0x00030x0001 0x sizeend
-# CHECK-NEXT:[3]  4 Code0x00010x0002 0x sizeful
-# CHECK-NEXT:[4]  5 Code0x00010x0002 0x sizeless
+# CHECK-NEXT:[3]  4 Code0x00040x0001 0x case1_local
+# CHECK-NEXT:[4]  5 Code0x00050x0001 0x case2_local
 # CHECK-NEXT:[5]  6   X Code0x00040x0001 0x0010 case1_global
 # CHECK-NEXT:[6]  7 Code0x00050x0001 0x0020 case2_weak
 # CHECK-NEXT:[7]  8   X Code0x00060x0001 0x0010 case3_global
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D96254: [ELFObjectWriter] Fix `symbol-binding.test` to conform to unsorted local symbols

2021-02-08 Thread Frederik Gossen via Phabricator via lldb-commits

frgossen abandoned this revision.
frgossen added a comment.

Already fixed in d813c37fc7ce507e008bdee1fc1726a57bc76df5 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96254

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

[Lldb-commits] [lldb] a39bcbc - [lldb] Debugger: reuse ExecutionContextRef to create ExecutionContext from Target

2021-02-08 Thread Tatyana Krasnukha via lldb-commits


Author: Tatyana Krasnukha
Date: 2021-02-08T15:09:08+03:00
New Revision: a39bcbca92e169baeb8b2c55dff90141ddd53888

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

LOG: [lldb] Debugger: reuse ExecutionContextRef to create ExecutionContext from 
Target

The Debugger didn't take the Process's run lock, that causes deadlocks and races
after applying https://reviews.llvm.org/D92164 revision. Since 
ExecutionContextRef
does the same job correctly, Debugger::GetSelectedExecutionContext just can use 
it
to build execution context upon the selected target.

Added: 


Modified: 
lldb/source/Core/Debugger.cpp

Removed: 




diff  --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index b16ce68c2fd2..1294b600c611 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -816,24 +816,9 @@ void Debugger::SaveInputTerminalState() {
 void Debugger::RestoreInputTerminalState() { m_terminal_state.Restore(); }
 
 ExecutionContext Debugger::GetSelectedExecutionContext() {
-  ExecutionContext exe_ctx;
-  TargetSP target_sp(GetSelectedTarget());
-  exe_ctx.SetTargetSP(target_sp);
-
-  if (target_sp) {
-ProcessSP process_sp(target_sp->GetProcessSP());
-exe_ctx.SetProcessSP(process_sp);
-if (process_sp && !process_sp->IsRunning()) {
-  ThreadSP thread_sp(process_sp->GetThreadList().GetSelectedThread());
-  if (thread_sp) {
-exe_ctx.SetThreadSP(thread_sp);
-exe_ctx.SetFrameSP(thread_sp->GetSelectedFrame());
-if (exe_ctx.GetFramePtr() == nullptr)
-  exe_ctx.SetFrameSP(thread_sp->GetStackFrameAtIndex(0));
-  }
-}
-  }
-  return exe_ctx;
+  bool adopt_selected = true;
+  ExecutionContextRef exe_ctx_ref(GetSelectedTarget().get(), adopt_selected);
+  return ExecutionContext(exe_ctx_ref);
 }
 
 void Debugger::DispatchInputInterrupt() {



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

[Lldb-commits] [lldb] f9c5e16 - [lldb/tests] Un-skip TestGuiBasicDebug.py on Arm and AArch64

2021-02-08 Thread Tatyana Krasnukha via lldb-commits


Author: Tatyana Krasnukha
Date: 2021-02-08T15:09:09+03:00
New Revision: f9c5e1664e081031e7deec3df49953952771d21b

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

LOG: [lldb/tests] Un-skip TestGuiBasicDebug.py on Arm and AArch64

The test was timing out because of https://reviews.llvm.org/D92164, it should 
pass now.

Added: 


Modified: 
lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py

Removed: 




diff  --git a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py 
b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
index d2e223a57be9..9deb700da39c 100644
--- a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
+++ b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
@@ -15,7 +15,6 @@ class TestGuiBasicDebugCommandTest(PExpectTest):
 # under ASAN on a loaded machine..
 @skipIfAsan
 @skipIfCursesSupportMissing
-@skipIf(archs=["arm", "aarch64"], oslist=["linux"])
 def test_gui(self):
 self.build()
 



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

[Lldb-commits] [lldb] 36de94c - Reland "[lldb] Make CommandInterpreter's execution context the same as debugger's one"

2021-02-08 Thread Tatyana Krasnukha via lldb-commits


Author: Tatyana Krasnukha
Date: 2021-02-08T15:09:09+03:00
New Revision: 36de94cf54efbad967a9a0fa41329a8b59bc35c4

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

LOG: Reland "[lldb] Make CommandInterpreter's execution context the same as 
debugger's one"

Added: 
lldb/test/API/python_api/debugger/Makefile
lldb/test/API/python_api/debugger/main.cpp

Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/API/SBCommandInterpreter.cpp
lldb/source/Breakpoint/BreakpointOptions.cpp
lldb/source/Commands/CommandObjectCommands.cpp
lldb/source/Commands/CommandObjectExpression.cpp
lldb/source/Commands/CommandObjectProcess.cpp
lldb/source/Commands/CommandObjectRegexCommand.cpp
lldb/source/Commands/CommandObjectSettings.cpp
lldb/source/Commands/CommandObjectWatchpointCommand.cpp
lldb/source/Core/IOHandlerCursesGUI.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Target/Target.cpp
lldb/test/API/python_api/debugger/TestDebuggerAPI.py

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index c4f9dd2fdb37..7f897bf20185 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -24,7 +24,9 @@
 #include "lldb/Utility/StringList.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-private.h"
+
 #include 
+#include 
 
 namespace lldb_private {
 class CommandInterpreter;
@@ -245,7 +247,7 @@ class CommandInterpreter : public Broadcaster,
 
   CommandInterpreter(Debugger &debugger, bool synchronous_execution);
 
-  ~CommandInterpreter() override;
+  ~CommandInterpreter() override = default;
 
   // These two functions fill out the Broadcaster interface:
 
@@ -300,10 +302,11 @@ class CommandInterpreter : public Broadcaster,
   CommandReturnObject &result);
 
   bool HandleCommand(const char *command_line, LazyBool add_to_history,
- CommandReturnObject &result,
- ExecutionContext *override_context = nullptr,
- bool repeat_on_empty_command = true,
- bool no_context_switching = false);
+ const ExecutionContext &override_context,
+ CommandReturnObject &result);
+
+  bool HandleCommand(const char *command_line, LazyBool add_to_history,
+ CommandReturnObject &result);
 
   bool WasInterrupted() const;
 
@@ -312,9 +315,7 @@ class CommandInterpreter : public Broadcaster,
   /// \param[in] commands
   ///The list of commands to execute.
   /// \param[in,out] context
-  ///The execution context in which to run the commands. Can be nullptr in
-  ///which case the default
-  ///context will be used.
+  ///The execution context in which to run the commands.
   /// \param[in] options
   ///This object holds the options used to control when to stop, whether to
   ///execute commands,
@@ -324,8 +325,13 @@ class CommandInterpreter : public Broadcaster,
   ///safely,
   ///and failed with some explanation if we aborted executing the commands
   ///at some point.
-  void HandleCommands(const StringList &commands, ExecutionContext *context,
-  CommandInterpreterRunOptions &options,
+  void HandleCommands(const StringList &commands,
+  const ExecutionContext &context,
+  const CommandInterpreterRunOptions &options,
+  CommandReturnObject &result);
+
+  void HandleCommands(const StringList &commands,
+  const CommandInterpreterRunOptions &options,
   CommandReturnObject &result);
 
   /// Execute a list of commands from a file.
@@ -333,9 +339,7 @@ class CommandInterpreter : public Broadcaster,
   /// \param[in] file
   ///The file from which to read in commands.
   /// \param[in,out] context
-  ///The execution context in which to run the commands. Can be nullptr in
-  ///which case the default
-  ///context will be used.
+  ///The execution context in which to run the commands.
   /// \param[in] options
   ///This object holds the options used to control when to stop, whether to
   ///execute commands,
@@ -345,8 +349,12 @@ class CommandInterpreter : public Broadcaster,
   ///safely,
   ///and failed with some explanation if we aborted executing the commands
   ///at some point.
-  void HandleCommandsFromFile(FileSpec &file, ExecutionContext *context,
-  CommandInterpreterRunOptions &options,
+  void HandleCommandsFromFile(FileSpec &file, const ExecutionContext &context,
+

[Lldb-commits] [lldb] 05d7d69 - [lldb/tests] Removed add_test_categories decorator for python API tests, NFC

2021-02-08 Thread Tatyana Krasnukha via lldb-commits


Author: Tatyana Krasnukha
Date: 2021-02-08T15:10:48+03:00
New Revision: 05d7d6949c7cd3f1566d4c8394fa59160a7ffd05

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

LOG: [lldb/tests] Removed add_test_categories decorator for python API tests, 
NFC

There is a .categories file in the python_api directory that makes all nested 
tests
belong to the category "pyapi". The decorator is unnecessary for these tests.

Added: 


Modified: 
lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
lldb/test/API/python_api/class_members/TestSBTypeClassMembers.py
lldb/test/API/python_api/debugger/TestDebuggerAPI.py

lldb/test/API/python_api/default-constructor/TestDefaultConstructorForAPIObjects.py
lldb/test/API/python_api/disassemble-raw-data/TestDisassembleRawData.py
lldb/test/API/python_api/disassemble-raw-data/TestDisassemble_VST1_64.py
lldb/test/API/python_api/event/TestEvents.py
lldb/test/API/python_api/file_handle/TestFileHandle.py
lldb/test/API/python_api/findvalue_duplist/TestSBFrameFindValue.py
lldb/test/API/python_api/formatters/TestFormattersSBAPI.py
lldb/test/API/python_api/frame/TestFrames.py
lldb/test/API/python_api/frame/inlines/TestInlinedFrame.py
lldb/test/API/python_api/function_symbol/TestDisasmAPI.py
lldb/test/API/python_api/function_symbol/TestSymbolAPI.py
lldb/test/API/python_api/hello_world/TestHelloWorld.py
lldb/test/API/python_api/interpreter/TestCommandInterpreterAPI.py
lldb/test/API/python_api/interpreter/TestRunCommandInterpreterAPI.py
lldb/test/API/python_api/lldbutil/frame/TestFrameUtils.py
lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
lldb/test/API/python_api/lldbutil/iter/TestRegistersIterator.py
lldb/test/API/python_api/lldbutil/process/TestPrintStackTraces.py
lldb/test/API/python_api/module_section/TestModuleAndSection.py
lldb/test/API/python_api/name_lookup/TestNameLookup.py
lldb/test/API/python_api/process/TestProcessAPI.py
lldb/test/API/python_api/process/io/TestProcessIO.py
lldb/test/API/python_api/sbdata/TestSBData.py
lldb/test/API/python_api/sbenvironment/TestSBEnvironment.py
lldb/test/API/python_api/sbplatform/TestSBPlatform.py
lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
lldb/test/API/python_api/sbvalue_persist/TestSBValuePersist.py
lldb/test/API/python_api/section/TestSectionAPI.py
lldb/test/API/python_api/signals/TestSignalsAPI.py
lldb/test/API/python_api/symbol-context/TestSymbolContext.py

lldb/test/API/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
lldb/test/API/python_api/target/TestTargetAPI.py
lldb/test/API/python_api/thread/TestThreadAPI.py
lldb/test/API/python_api/type/TestTypeList.py
lldb/test/API/python_api/value/TestValueAPI.py
lldb/test/API/python_api/value/change_values/TestChangeValueAPI.py
lldb/test/API/python_api/value/empty_class/TestValueAPIEmptyClass.py
lldb/test/API/python_api/value/linked_list/TestValueAPILinkedList.py
lldb/test/API/python_api/value_var_update/TestValueVarUpdate.py
lldb/test/API/python_api/watchpoint/TestSetWatchpoint.py
lldb/test/API/python_api/watchpoint/TestWatchpointIgnoreCount.py
lldb/test/API/python_api/watchpoint/TestWatchpointIter.py
lldb/test/API/python_api/watchpoint/watchlocation/TestSetWatchlocation.py
lldb/test/API/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py

Removed: 




diff  --git a/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py 
b/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
index 80324ee61b70..bd02b7663f07 100644
--- a/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
+++ b/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
@@ -13,7 +13,6 @@ class BreakpointAPITestCase(TestBase):
 mydir = TestBase.compute_mydir(__file__)
 NO_DEBUG_INFO_TESTCASE = True
 
-@add_test_categories(['pyapi'])
 def test_breakpoint_is_valid(self):
 """Make sure that if an SBBreakpoint gets deleted its IsValid returns 
false."""
 self.build()
@@ -45,7 +44,6 @@ def test_breakpoint_is_valid(self):
 not breakpoint,
 "Breakpoint we deleted is no longer valid.")
 
-@add_test_categories(['pyapi'])
 def test_target_delete(self):
 """Make sure that if an SBTarget gets deleted the associated
 Breakpoint's IsValid returns false."""

diff  --git a/lldb/test/API/python_api/class_members/TestSBTypeClassMembers.py 
b/lldb/test/API/python_api/class_members/TestSBTypeClassMembers.py
index 091bb1bc5acc..061556ac0552 100644
--- a/lldb/test/API/python_api/class_members/TestSBTypeClassMembers.py
+++ b/lldb/test/API/python_api/class_members/TestSBTypeClassMembers.py
@@ -24,7 +2

[Lldb-commits] [PATCH] D96236: [lldb] DWZ 01/08: Pass main DWARFUnit * along DWARFDIEs

2021-02-08 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

I stopped looking after the first file, as the introduction of DWARF-ness to 
the CompileUnit class is a show-stopper. These classes are supposed to be 
independent of the actual format used to represent the data, and having them 
know anything about DWARF breaks that.
What's the reason for that? We already have a way to obtain the 
DWARFCompileUnit given a (generic) CompileUnit from within DWARF code 
(`SymbolFileDWARF::GetDWARFCompileUnit`). Given that your changes are (should 
be?) inside DWARF code, it's not clear to me why is that not sufficient (?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96236

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

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny updated this revision to Diff 322088.
mgorny added a comment.

Switch to `SetBreakpoint()`. remove `friend` and refactor `size_hint` to a 
variable while at it.


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

https://reviews.llvm.org/D95802

Files:
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
  lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -17,13 +17,15 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-#include "Plugins/Process/Utility/lldb-x86-register-enums.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
+#include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 #include "Plugins/Process/Utility/lldb-arm-register-enums.h"
 #include "Plugins/Process/Utility/lldb-arm64-register-enums.h"
+#include "Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h"
+#include "Plugins/Process/Utility/lldb-x86-register-enums.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -398,3 +400,61 @@
 }
 
 #endif // defined(__aarch64__)
+
+#if defined(__mips64__)
+
+#define EXPECT_GPR_MIPS64(lldb_reg, fbsd_regno)\
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_mips64),  \
+  ::testing::Pair(offsetof(reg, r_regs[fbsd_regno]),   \
+  sizeof(reg::r_regs[fbsd_regno])))
+
+TEST(RegisterContextFreeBSDTest, mips64) {
+  ArchSpec arch{"mips64-unknown-freebsd"};
+  RegisterContextFreeBSD_mips64 reg_ctx{arch};
+
+  // we can not use aliases from  because macros defined
+  // there are not namespaced and collide a lot, e.g. 'A1'
+
+  EXPECT_GPR_MIPS64(zero, 0);
+  EXPECT_GPR_MIPS64(r1, 1);
+  EXPECT_GPR_MIPS64(r2, 2);
+  EXPECT_GPR_MIPS64(r3, 3);
+  EXPECT_GPR_MIPS64(r4, 4);
+  EXPECT_GPR_MIPS64(r5, 5);
+  EXPECT_GPR_MIPS64(r6, 6);
+  EXPECT_GPR_MIPS64(r7, 7);
+  EXPECT_GPR_MIPS64(r8, 8);
+  EXPECT_GPR_MIPS64(r9, 9);
+  EXPECT_GPR_MIPS64(r10, 10);
+  EXPECT_GPR_MIPS64(r11, 11);
+  EXPECT_GPR_MIPS64(r12, 12);
+  EXPECT_GPR_MIPS64(r13, 13);
+  EXPECT_GPR_MIPS64(r14, 14);
+  EXPECT_GPR_MIPS64(r15, 15);
+  EXPECT_GPR_MIPS64(r16, 16);
+  EXPECT_GPR_MIPS64(r17, 17);
+  EXPECT_GPR_MIPS64(r18, 18);
+  EXPECT_GPR_MIPS64(r19, 19);
+  EXPECT_GPR_MIPS64(r20, 20);
+  EXPECT_GPR_MIPS64(r21, 21);
+  EXPECT_GPR_MIPS64(r22, 22);
+  EXPECT_GPR_MIPS64(r23, 23);
+  EXPECT_GPR_MIPS64(r24, 24);
+  EXPECT_GPR_MIPS64(r25, 25);
+  EXPECT_GPR_MIPS64(r26, 26);
+  EXPECT_GPR_MIPS64(r27, 27);
+  EXPECT_GPR_MIPS64(gp, 28);
+  EXPECT_GPR_MIPS64(sp, 29);
+  EXPECT_GPR_MIPS64(r30, 30);
+  EXPECT_GPR_MIPS64(ra, 31);
+  EXPECT_GPR_MIPS64(sr, 32);
+  EXPECT_GPR_MIPS64(mullo, 33);
+  EXPECT_GPR_MIPS64(mulhi, 34);
+  EXPECT_GPR_MIPS64(badvaddr, 35);
+  EXPECT_GPR_MIPS64(cause, 36);
+  EXPECT_GPR_MIPS64(pc, 37);
+  EXPECT_GPR_MIPS64(ic, 38);
+  EXPECT_GPR_MIPS64(dummy, 39);
+}
+
+#endif // defined(__mips64__)
Index: lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
@@ -0,0 +1,31 @@
+//===-- NativeProcessSoftwareSingleStep.h ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeProcessSoftwareSingleStep_h
+#define lldb_NativeProcessSoftwareSingleStep_h
+
+#include "lldb/Host/common/NativeProcessProtocol.h"
+#include "lldb/Host/common/NativeThreadProtocol.h"
+
+#include 
+
+namespace lldb_private {
+
+class Nativ

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny added a comment.

@labath, done. Does it look reasonably good now?


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

https://reviews.llvm.org/D95802

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

[Lldb-commits] [PATCH] D96260: [lldb/test] Test lldb-server named pipe functionality on windows

2021-02-08 Thread Pavel Labath via Phabricator via lldb-commits

labath created this revision.
labath added reviewers: amccarth, stella.stamenova.
labath requested review of this revision.
Herald added a project: LLDB.

lldb-server can use a named pipe to communicate the port number it is
listening on. This windows bits of this are already implemented, but we
did not have a test for that, most likely because python does not have
native pipe functionality.

This patch implements the windows bits necessary to test this. I'm using
the ctypes package to call the native APIs directly to avoid a
dependency to non-standard python packages. This introduces some amount
of boilerplate, but our named pipe use case is fairly limited, so we
should not end up needing to wrap large chunks of windows APIs.

Surprisingly to changes to lldb-server were needed to make the test
pass.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96260

Files:
  lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py

Index: lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
===
--- lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
+++ lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
@@ -5,6 +5,122 @@
 import socket
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbplatformutil
+import random
+
+if lldbplatformutil.getHostPlatform() == "windows":
+import ctypes
+import ctypes.wintypes
+from ctypes.wintypes import (BOOL, DWORD, HANDLE, LPCWSTR, LPDWORD, LPVOID)
+
+kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+
+PIPE_ACCESS_INBOUND = 1
+FILE_FLAG_FIRST_PIPE_INSTANCE = 0x0008
+FILE_FLAG_OVERLAPPED = 0x4000
+PIPE_TYPE_BYTE = 0
+PIPE_REJECT_REMOTE_CLIENTS = 8
+INVALID_HANDLE_VALUE = -1
+ERROR_ACCESS_DENIED = 5
+ERROR_IO_PENDING = 997
+
+
+class OVERLAPPED(ctypes.Structure):
+_fields_ = [("Internal", LPVOID), ("InternalHigh", LPVOID), ("Offset",
+DWORD), ("OffsetHigh", DWORD), ("hEvent", HANDLE)]
+
+def __init__(self):
+super(OVERLAPPED, self).__init__(Internal=0, InternalHigh=0,
+Offset=0, OffsetHigh=0, hEvent=None)
+LPOVERLAPPED = ctypes.POINTER(OVERLAPPED)
+
+CreateNamedPipe = kernel32.CreateNamedPipeW
+CreateNamedPipe.restype = HANDLE
+CreateNamedPipe.argtypes = (LPCWSTR, DWORD, DWORD, DWORD, DWORD, DWORD,
+DWORD, LPVOID)
+
+ConnectNamedPipe = kernel32.ConnectNamedPipe
+ConnectNamedPipe.restype = BOOL
+ConnectNamedPipe.argtypes = (HANDLE, LPOVERLAPPED)
+
+CreateEvent = kernel32.CreateEventW
+CreateEvent.restype = HANDLE
+CreateEvent.argtypes = (LPVOID, BOOL, BOOL, LPCWSTR)
+
+GetOverlappedResultEx = kernel32.GetOverlappedResultEx
+GetOverlappedResultEx.restype = BOOL
+GetOverlappedResultEx.argtypes = (HANDLE, LPOVERLAPPED, LPDWORD, DWORD,
+BOOL)
+
+ReadFile = kernel32.ReadFile
+ReadFile.restype = BOOL
+ReadFile.argtypes = (HANDLE, LPVOID, DWORD, LPDWORD, LPOVERLAPPED)
+
+CloseHandle = kernel32.CloseHandle
+CloseHandle.restype = BOOL
+CloseHandle.argtypes = (HANDLE,)
+
+class Pipe(object):
+def __init__(self, prefix):
+while True:
+self.name = "lldb-" + str(random.randrange(1e10))
+full_name = ".\\pipe\\" + self.name
+self._handle = CreateNamedPipe(full_name, PIPE_ACCESS_INBOUND |
+FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_BYTE | PIPE_REJECT_REMOTE_CLIENTS, 1, 4096,
+4096, 0, None)
+if self._handle != INVALID_HANDLE_VALUE:
+break
+if ctypes.get_last_error() != ERROR_ACCESS_DENIED:
+raise ctypes.WinError(ctypes.get_last_error())
+
+self._overlapped = OVERLAPPED()
+self._overlapped.hEvent = CreateEvent(None, True, False, None)
+result = ConnectNamedPipe(self._handle, self._overlapped)
+assert result == 0
+if ctypes.get_last_error() != ERROR_IO_PENDING:
+raise ctypes.WinError(ctypes.get_last_error())
+
+def finish_connection(self, timeout):
+if not GetOverlappedResultEx(self._handle, self._overlapped,
+ctypes.byref(DWORD(0)), timeout*1000, True):
+raise ctypes.WinError(ctypes.get_last_error())
+
+def read(self, size, timeout):
+buf = ctypes.create_string_buffer(size)
+if not ReadFile(self._handle, ctypes.byref(buf), size, None,
+self._overlapped):
+if ctypes.get_last_error() != ERROR_IO_PENDING:
+raise ctypes.WinError(ctypes.get_last_error())
+read = DWORD(0)
+if not GetOverlappedResultEx(self._hand

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-08 Thread Pavel Labath via Phabricator via lldb-commits

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

Ok, seems reasonable.




Comment at: 
lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp:20
+
+namespace lldb_private {
+

This should be an anonymous namespace.


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

https://reviews.llvm.org/D95802

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

[Lldb-commits] [PATCH] D96236: [lldb] DWZ 01/08: Pass main DWARFUnit * along DWARFDIEs

2021-02-08 Thread Jan Kratochvil via Phabricator via lldb-commits

jankratochvil planned changes to this revision.
jankratochvil added a comment.

I will try to update it, I agree with your comment, thanks for the review.
I agree this first patch needs to be decided first before looking at the other 
parts 02..08.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96236

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

[Lldb-commits] [lldb] 5a63045 - [LLDB] Fix `Wunused-result` warning

2021-02-08 Thread Frederik Gossen via lldb-commits


Author: Frederik Gossen
Date: 2021-02-08T18:10:08+01:00
New Revision: 5a63045fe78834937785ed5081052e083a98077f

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

LOG: [LLDB] Fix `Wunused-result` warning

Added: 


Modified: 
lldb/source/Interpreter/CommandInterpreter.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 0b25abc9cdea..a7afa1034762 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2832,7 +2832,9 @@ void CommandInterpreter::IOHandlerInputComplete(IOHandler 
&io_handler,
   StartHandlingCommand();
 
   OverrideExecutionContext(m_debugger.GetSelectedExecutionContext());
-  llvm::make_scope_exit([this]() { RestoreExecutionContext(); });
+  auto finalize = llvm::make_scope_exit([this]() {
+RestoreExecutionContext();
+  });
 
   lldb_private::CommandReturnObject result(m_debugger.GetUseColor());
   HandleCommand(line.c_str(), eLazyBoolCalculate, result);



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

[Lldb-commits] [PATCH] D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC)

2021-02-08 Thread Dave Lee via Phabricator via lldb-commits

kastiglione created this revision.
kastiglione added a reviewer: jingham.
kastiglione requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

These two `AppleThreadPlanStepThrough` thread plans have parameterized behavior
that is unutilized. To make their interface and implementation simpler, this
change inlines those outside parameters.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96276

Files:
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h

Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
@@ -24,8 +24,7 @@
 public:
   AppleThreadPlanStepThroughObjCTrampoline(
   Thread &thread, AppleObjCTrampolineHandler &trampoline_handler,
-  ValueList &values, lldb::addr_t isa_addr, lldb::addr_t sel_addr,
-  bool stop_others);
+  ValueList &values, lldb::addr_t isa_addr, lldb::addr_t sel_addr);
 
   ~AppleThreadPlanStepThroughObjCTrampoline() override;
 
@@ -39,7 +38,9 @@
 
   bool ShouldStop(Event *event_ptr) override;
 
-  bool StopOthers() override { return m_stop_others; }
+  // The step through code might have to fill in the cache, so it is not safe
+  // to run only one thread.
+  bool StopOthers() override { return false; }
 
   // The base class MischiefManaged does some cleanup - so you have to call it
   // in your MischiefManaged derived class.
@@ -69,15 +70,13 @@
   FunctionCaller *m_impl_function; /// This is a pointer to a impl function that
/// is owned by the client that pushes this
/// plan.
-  bool m_stop_others;  /// Whether we should stop other threads.
 };
 
 class AppleThreadPlanStepThroughDirectDispatch: public ThreadPlanStepOut {
 public:
-  AppleThreadPlanStepThroughDirectDispatch(
-  Thread &thread, AppleObjCTrampolineHandler &handler,
-  llvm::StringRef dispatch_func_name, bool stop_others,
-  LazyBool step_in_avoids_code_without_debug_info);
+  AppleThreadPlanStepThroughDirectDispatch(Thread &thread,
+   AppleObjCTrampolineHandler &handler,
+   llvm::StringRef dispatch_func_name);
 
   ~AppleThreadPlanStepThroughDirectDispatch() override;
 
@@ -85,7 +84,7 @@
 
   bool ShouldStop(Event *event_ptr) override;
 
-  bool StopOthers() override { return m_stop_others; }
+  bool StopOthers() override { return false; }
 
   bool MischiefManaged() override;
 
@@ -107,7 +106,6 @@
   std::vector m_msgSend_bkpts; /// Breakpoints on the objc
/// dispatch functions.
   bool m_at_msg_send;  /// Are we currently handling an msg_send
-  bool m_stop_others;  /// Whether we should stop other threads.
 
 };
 
Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
@@ -30,15 +30,13 @@
 AppleThreadPlanStepThroughObjCTrampoline::
 AppleThreadPlanStepThroughObjCTrampoline(
 Thread &thread, AppleObjCTrampolineHandler &trampoline_handler,
-ValueList &input_values, lldb::addr_t isa_addr, lldb::addr_t sel_addr,
-bool stop_others)
+ValueList &input_values, lldb::addr_t isa_addr, lldb::addr_t sel_addr)
 : ThreadPlan(ThreadPlan::eKindGeneric,
  "MacOSX Step through ObjC Trampoline", thread, eVoteNoOpinion,
  eVoteNoOpinion),
   m_trampoline_handler(trampoline_handler),
   m_args_addr(LLDB_INVALID_ADDRESS), m_input_values(input_values),
-  m_isa_addr(isa_addr), m_sel_addr(sel_addr), m_impl_function(nullptr),
-  m_stop_others(stop_others) {}
+  m_isa_addr(isa_addr), m_sel_addr(sel_addr), m_impl_function(nullptr) {}
 
 // Destructor
 AppleThreadPlanStepThroughObjCTrampoline::
@@ -66,7 +64,7 @@
 EvaluateExpressionOptions options;
 options.SetUnwindOnError(true);
 options.SetIgnoreBreakpoints(true);
-options.SetStopOthers(m_stop_others);
+options.SetStopOthers(false);
 GetThread().CalculateExecutionContext(exc_ctx);
 m_func_sp = m_impl_function->GetThreadPlanToCallFunction(
 exc_ctx, m_args_a

[Lldb-commits] [PATCH] D96277: [lldb] Minor cleanups to ThreadPlan.h (NFC)

2021-02-08 Thread Dave Lee via Phabricator via lldb-commits

kastiglione created this revision.
kastiglione added a reviewer: jingham.
kastiglione requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

While learning about ThreadPlan, I did a bit of cleanup:

- Remove unused code
- Move functions to protected where applicable
- Remove virtual for functions that are not overridden


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96277

Files:
  lldb/include/lldb/Target/ThreadPlan.h

Index: lldb/include/lldb/Target/ThreadPlan.h
===
--- lldb/include/lldb/Target/ThreadPlan.h
+++ lldb/include/lldb/Target/ThreadPlan.h
@@ -281,8 +281,6 @@
 class ThreadPlan : public std::enable_shared_from_this,
public UserID {
 public:
-  enum ThreadScope { eAllThreads, eSomeThreads, eThisThread };
-
   // We use these enums so that we can cast a base thread plan to it's real
   // type without having to resort to dynamic casting.
   enum ThreadPlanKind {
@@ -298,15 +296,9 @@
 eKindStepInRange,
 eKindRunToAddress,
 eKindStepThrough,
-eKindStepUntil,
-eKindTestCondition
-
+eKindStepUntil
   };
 
-  // Constructors and Destructors
-  ThreadPlan(ThreadPlanKind kind, const char *name, Thread &thread,
- Vote stop_vote, Vote run_vote);
-
   virtual ~ThreadPlan();
 
   /// Returns the name of this thread plan.
@@ -375,7 +367,7 @@
 
   virtual Vote ShouldReportStop(Event *event_ptr);
 
-  virtual Vote ShouldReportRun(Event *event_ptr);
+  Vote ShouldReportRun(Event *event_ptr);
 
   virtual void SetStopOthers(bool new_value);
 
@@ -416,15 +408,6 @@
 
   virtual void WillPop();
 
-  // This pushes a plan onto the plan stack of the current plan's thread.
-  // Also sets the plans to private and not master plans.  A plan pushed by 
-  // another thread plan is never either of the above.
-  void PushPlan(lldb::ThreadPlanSP &thread_plan_sp) {
-GetThread().PushPlan(thread_plan_sp);
-thread_plan_sp->SetPrivate(false);
-thread_plan_sp->SetIsMasterPlan(false);
-  }
-
   ThreadPlanKind GetKind() const { return m_kind; }
 
   bool IsPlanComplete();
@@ -488,7 +471,7 @@
 
   virtual bool IsVirtualStep() { return false; }
 
-  virtual bool SetIterationCount(size_t count) {
+  bool SetIterationCount(size_t count) {
 if (m_takes_iteration_count) {
   // Don't tell me to do something 0 times...
   if (count == 0)
@@ -498,14 +481,11 @@
 return m_takes_iteration_count;
   }
 
-  virtual size_t GetIterationCount() {
-if (!m_takes_iteration_count)
-  return 0;
-else
-  return m_iteration_count;
-  }
-
 protected:
+  // Constructors and Destructors
+  ThreadPlan(ThreadPlanKind kind, const char *name, Thread &thread,
+ Vote stop_vote, Vote run_vote);
+
   // Classes that inherit from ThreadPlan can see and modify these
 
   virtual bool DoWillResume(lldb::StateType resume_state, bool current_plan) {
@@ -514,6 +494,15 @@
 
   virtual bool DoPlanExplainsStop(Event *event_ptr) = 0;
 
+  // This pushes a plan onto the plan stack of the current plan's thread.
+  // Also sets the plans to private and not master plans.  A plan pushed by
+  // another thread plan is never either of the above.
+  void PushPlan(lldb::ThreadPlanSP &thread_plan_sp) {
+GetThread().PushPlan(thread_plan_sp);
+thread_plan_sp->SetPrivate(false);
+thread_plan_sp->SetIsMasterPlan(false);
+  }
+
   // This gets the previous plan to the current plan (for forwarding requests).
   // This is mostly a formal requirement, it allows us to make the Thread's
   // GetPreviousPlan protected, but only friend ThreadPlan to thread.
@@ -531,10 +520,6 @@
 GetThread().SetStopInfo(stop_reason_sp);
   }
 
-  void CachePlanExplainsStop(bool does_explain) {
-m_cached_plan_explains_stop = does_explain ? eLazyBoolYes : eLazyBoolNo;
-  }
-
   LazyBool GetCachedPlanExplainsStop() const {
 return m_cached_plan_explains_stop;
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95802: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8244fc505def: [lldb] [Process/FreeBSDRemote] Introduce 
mips64 support (authored by mgorny).
Herald added a subscriber: jrtc27.
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D95802?vs=322088&id=322144#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95802

Files:
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
  lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -17,13 +17,15 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-#include "Plugins/Process/Utility/lldb-x86-register-enums.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
+#include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 #include "Plugins/Process/Utility/lldb-arm-register-enums.h"
 #include "Plugins/Process/Utility/lldb-arm64-register-enums.h"
+#include "Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h"
+#include "Plugins/Process/Utility/lldb-x86-register-enums.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -398,3 +400,61 @@
 }
 
 #endif // defined(__aarch64__)
+
+#if defined(__mips64__)
+
+#define EXPECT_GPR_MIPS64(lldb_reg, fbsd_regno)\
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_mips64),  \
+  ::testing::Pair(offsetof(reg, r_regs[fbsd_regno]),   \
+  sizeof(reg::r_regs[fbsd_regno])))
+
+TEST(RegisterContextFreeBSDTest, mips64) {
+  ArchSpec arch{"mips64-unknown-freebsd"};
+  RegisterContextFreeBSD_mips64 reg_ctx{arch};
+
+  // we can not use aliases from  because macros defined
+  // there are not namespaced and collide a lot, e.g. 'A1'
+
+  EXPECT_GPR_MIPS64(zero, 0);
+  EXPECT_GPR_MIPS64(r1, 1);
+  EXPECT_GPR_MIPS64(r2, 2);
+  EXPECT_GPR_MIPS64(r3, 3);
+  EXPECT_GPR_MIPS64(r4, 4);
+  EXPECT_GPR_MIPS64(r5, 5);
+  EXPECT_GPR_MIPS64(r6, 6);
+  EXPECT_GPR_MIPS64(r7, 7);
+  EXPECT_GPR_MIPS64(r8, 8);
+  EXPECT_GPR_MIPS64(r9, 9);
+  EXPECT_GPR_MIPS64(r10, 10);
+  EXPECT_GPR_MIPS64(r11, 11);
+  EXPECT_GPR_MIPS64(r12, 12);
+  EXPECT_GPR_MIPS64(r13, 13);
+  EXPECT_GPR_MIPS64(r14, 14);
+  EXPECT_GPR_MIPS64(r15, 15);
+  EXPECT_GPR_MIPS64(r16, 16);
+  EXPECT_GPR_MIPS64(r17, 17);
+  EXPECT_GPR_MIPS64(r18, 18);
+  EXPECT_GPR_MIPS64(r19, 19);
+  EXPECT_GPR_MIPS64(r20, 20);
+  EXPECT_GPR_MIPS64(r21, 21);
+  EXPECT_GPR_MIPS64(r22, 22);
+  EXPECT_GPR_MIPS64(r23, 23);
+  EXPECT_GPR_MIPS64(r24, 24);
+  EXPECT_GPR_MIPS64(r25, 25);
+  EXPECT_GPR_MIPS64(r26, 26);
+  EXPECT_GPR_MIPS64(r27, 27);
+  EXPECT_GPR_MIPS64(gp, 28);
+  EXPECT_GPR_MIPS64(sp, 29);
+  EXPECT_GPR_MIPS64(r30, 30);
+  EXPECT_GPR_MIPS64(ra, 31);
+  EXPECT_GPR_MIPS64(sr, 32);
+  EXPECT_GPR_MIPS64(mullo, 33);
+  EXPECT_GPR_MIPS64(mulhi, 34);
+  EXPECT_GPR_MIPS64(badvaddr, 35);
+  EXPECT_GPR_MIPS64(cause, 36);
+  EXPECT_GPR_MIPS64(pc, 37);
+  EXPECT_GPR_MIPS64(ic, 38);
+  EXPECT_GPR_MIPS64(dummy, 39);
+}
+
+#endif // defined(__mips64__)
Index: lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h
@@ -0,0 +1,31 @@
+//===-- NativeProcessSoftwareSingleStep.h ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef lldb_NativeProcessSoftwareSingleStep_h
+#def

[Lldb-commits] [lldb] 8244fc5 - [lldb] [Process/FreeBSDRemote] Introduce mips64 support

2021-02-08 Thread Michał Górny via lldb-commits


Author: Michał Górny
Date: 2021-02-08T18:27:26+01:00
New Revision: 8244fc505def67f1094713202a2345f0c39d33dd

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

LOG: [lldb] [Process/FreeBSDRemote] Introduce mips64 support

Introduce mips64 support to match the legacy FreeBSD plugin. Similarly
to the legacy plugin, the code does not support FPU registers at the
moment.  The support for them will be submitted separately as it
requires changes to the register context shared by both plugins.

This also includes software single-stepping support that is moved from
the Linux plugin into a common Utility class.  The FreeBSD code also
starts explicitly ignoring EINVAL from PT_CLEARSTEP since this is easier
to implement than checking whether hardware single-stepping were used.

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

Added: 

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.cpp

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_mips64.h
lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h

Modified: 
lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
lldb/source/Plugins/Process/Utility/CMakeLists.txt
lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp 
b/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
index 40fef595752b..7994e602703a 100644
--- a/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
+++ b/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
@@ -255,6 +255,7 @@ bool PlatformFreeBSD::CanDebugProcess() {
 switch (host_triple.getArch()) {
   case llvm::Triple::aarch64:
   case llvm::Triple::arm:
+  case llvm::Triple::mips64:
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
 use_legacy_plugin = !!getenv("FREEBSD_LEGACY_PLUGIN");

diff  --git a/lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt 
b/lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
index 9d102bee24b6..826d7162967a 100644
--- a/lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
@@ -3,6 +3,7 @@ add_lldb_library(lldbPluginProcessFreeBSDRemote
   NativeRegisterContextFreeBSD.cpp
   NativeRegisterContextFreeBSD_arm.cpp
   NativeRegisterContextFreeBSD_arm64.cpp
+  NativeRegisterContextFreeBSD_mips64.cpp
   NativeRegisterContextFreeBSD_x86_64.cpp
   NativeThreadFreeBSD.cpp
 

diff  --git 
a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
index 139313bb5310..10fafe675221 100644
--- a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
@@ -265,7 +265,17 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) 
{
 switch (info.pl_siginfo.si_code) {
 case TRAP_BRKPT:
   if (thread) {
-thread->SetStoppedByBreakpoint();
+auto thread_info =
+m_threads_stepping_with_breakpoint.find(thread->GetID());
+if (thread_info != m_threads_stepping_with_breakpoint.end()) {
+  thread->SetStoppedByTrace();
+  Status brkpt_error = RemoveBreakpoint(thread_info->second);
+  if (brkpt_error.Fail())
+LLDB_LOG(log, "pid = {0} remove stepping breakpoint: {1}",
+ thread_info->first, brkpt_error);
+  m_threads_stepping_with_breakpoint.erase(thread_info);
+} else
+  thread->SetStoppedByBreakpoint();
 FixupBreakpointPCAsNeeded(*thread);
   }
   SetState(StateType::eStateStopped, true);
@@ -899,3 +909,7 @@ Status NativeProcessFreeBSD::ReinitializeThreads() {
 
   return error;
 }
+
+bool NativeProcessFreeBSD::SupportHardwareSingleStepping() const {
+  return !m_arch.IsMIPS();
+}

diff  --git a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h 
b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
index 99123d598186..ceffc370ca33 100644
--- a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
+++ b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
@@ -10,6 +10,8 @@
 #define liblldb_NativeP

[Lldb-commits] [PATCH] D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC)

2021-02-08 Thread Dave Lee via Phabricator via lldb-commits

kastiglione added inline comments.
Herald added a subscriber: JDevlieghere.



Comment at: 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp:1163
-  // stop_others value passed in to us here:
-  const bool trampoline_stop_others = false;
   ret_plan_sp = std::make_shared(

This is one parameter being inlined.



Comment at: 
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp:1188-1189
-
-  bool trampoline_stop_others = false;
-  LazyBool step_in_should_stop = eLazyBoolCalculate;
-  ret_plan_sp = std::make_shared 
(

These are two other parameters being inlined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96276

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

[Lldb-commits] [PATCH] D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC)

2021-02-08 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

I can't think of a really good reason why you would need to override the 
general "step in avoids nodebug" behavior.  I'm pretty sure I was thinking of a 
trampoline that got you half way to somewhere interesting, at which point you 
would want to negotiate again for the trampoline to take you the rest of the 
way.  In that case you would not want to obey the general setting.  But this is 
really about what happens when you don't find a good place to go, so that seems 
unnecessary.

It still seems to me like a trampoline which knew that to implement itself, all 
it had to do was a couple of stepi's - for instance if a dyld stub knew that 
the stub had been filled in and would jump straight to the target, it could run 
without letting the other threads go.  That's actually something the dyld stubs 
could figure out, they just don't at present. So I'd rather not remove this 
control.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96276

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

[Lldb-commits] [PATCH] D95683: [lldb] Fix fallout caused by D89156 on 11.0.1 for MacOS

2021-02-08 Thread Andi via Phabricator via lldb-commits

Abpostelnicu added a comment.

Landed in 11.1 
https://github.com/llvm/llvm-project/commit/1fdec59bffc11ae37eb51a1b9869f0696bfd5312#diff-2fa23ad0cf1839955ddaf4a0d78a9d9b5fd9b88933f82f6433035916a2655c6c.
Patch needs to be rebased for trunk now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95683

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

[Lldb-commits] [PATCH] D96277: [lldb] Minor cleanups to ThreadPlan.h (NFC)

2021-02-08 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

This is okay.  It seems like CachePlanExplainsStop wasn't used because it's 
done by hand instead.  A better patch might be to stop doing that and use the 
function instead?  But the argument's not terribly compelling either way...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96277

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Jessica Clarke via Phabricator via lldb-commits

jrtc27 added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

Why are these two different? Should it not always be `trap` ie `tw 31,0,0`? If 
not that should be explained here. These names also aren't great as it's 
unclear which ppc64 is using unless you read the code below (I'd expect either 
ppc and ppc64 or ppc and ppcle as the two "axes", but ppc and ppc64le are on a 
diagonal in the 2x2 grid).


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Kamil Rytarowski via Phabricator via lldb-commits

krytarowski added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

jrtc27 wrote:
> Why are these two different? Should it not always be `trap` ie `tw 31,0,0`? 
> If not that should be explained here. These names also aren't great as it's 
> unclear which ppc64 is using unless you read the code below (I'd expect 
> either ppc and ppc64 or ppc and ppcle as the two "axes", but ppc and ppc64le 
> are on a diagonal in the 2x2 grid).
On PPC we assume Big-Endian unless specified otherwise, so no need to specify 
ppcbe or ppc64be.


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h, remove AlignedCharArray

2021-02-08 Thread Mandeep Singh Grang via Phabricator via lldb-commits

mgrang added a comment.
Herald added a subscriber: JDevlieghere.

Hi @jfb This patch results in a compiler crash when building a simple C program 
on a Windows X86 Debug build. I have filed this 
 issue to track it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Jessica Clarke via Phabricator via lldb-commits

jrtc27 added inline comments.

Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap

krytarowski wrote:
> jrtc27 wrote:
> > Why are these two different? Should it not always be `trap` ie `tw 31,0,0`? 
> > If not that should be explained here. These names also aren't great as it's 
> > unclear which ppc64 is using unless you read the code below (I'd expect 
> > either ppc and ppc64 or ppc and ppcle as the two "axes", but ppc and 
> > ppc64le are on a diagonal in the 2x2 grid).
> On PPC we assume Big-Endian unless specified otherwise, so no need to specify 
> ppcbe or ppc64be.
I realise why there is no `be` suffix, that's not what I was asking. Currently 
there are four options (though ppcle isn't implemented in FreeBSD):
|  | Big | Little |
| 32 | ppc | ppcle |
| 64 | ppc64 | ppc64le |

If the difference between the two encodings is solely endianness then they 
should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the difference between 
the two encodings is solely machine word size then they should be called 
`g_ppc_opcode` and g_ppc64_opcode`. But `g_ppc_opcode` vs g_ppc64le_opcode` has 
*both* differences in the name, which tells you nothing about *why* they are 
different, and thus does not obviously state which encoding ppc64 uses, if 
either of them.

As for the encodings themselves, they obviously differ in endianness, but there 
is also a difference in the second/third byte where `g_ppc_opcode[1]` is `0xc0` 
but `g_ppc64le_opcode[2]` is `0xe0`. That does not make sense to me, but if 
it's there for a reason it needs a comment.

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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC)

2021-02-08 Thread Dave Lee via Phabricator via lldb-commits

kastiglione added a comment.

In D96276#2549007 , @jingham wrote:

> It still seems to me like a trampoline which knew that to implement itself, 
> all it had to do was a couple of stepi's - for instance if a dyld stub knew 
> that the stub had been filled in and would jump straight to the target, it 
> could run without letting the other threads go.  That's actually something 
> the dyld stubs could figure out, they just don't at present. So I'd rather 
> not remove this control.

Happy to restore the stop_others parameter, but for my understanding I have two 
questions:

1. Is the behavior you envision something that applies to these specific thread 
plan subclasses (ie not dyld stubs)
2. Will callers decide to stop others from the outside, or is the decision to 
stop others something that these subclasses would make internally?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96276

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

jrtc27 wrote:
> krytarowski wrote:
> > jrtc27 wrote:
> > > Why are these two different? Should it not always be `trap` ie `tw 
> > > 31,0,0`? If not that should be explained here. These names also aren't 
> > > great as it's unclear which ppc64 is using unless you read the code below 
> > > (I'd expect either ppc and ppc64 or ppc and ppcle as the two "axes", but 
> > > ppc and ppc64le are on a diagonal in the 2x2 grid).
> > On PPC we assume Big-Endian unless specified otherwise, so no need to 
> > specify ppcbe or ppc64be.
> I realise why there is no `be` suffix, that's not what I was asking. 
> Currently there are four options (though ppcle isn't implemented in FreeBSD):
> |  | Big | Little |
> | 32 | ppc | ppcle |
> | 64 | ppc64 | ppc64le |
> 
> If the difference between the two encodings is solely endianness then they 
> should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the difference 
> between the two encodings is solely machine word size then they should be 
> called `g_ppc_opcode` and g_ppc64_opcode`. But `g_ppc_opcode` vs 
> g_ppc64le_opcode` has *both* differences in the name, which tells you nothing 
> about *why* they are different, and thus does not obviously state which 
> encoding ppc64 uses, if either of them.
> 
> As for the encodings themselves, they obviously differ in endianness, but 
> there is also a difference in the second/third byte where `g_ppc_opcode[1]` 
> is `0xc0` but `g_ppc64le_opcode[2]` is `0xe0`. That does not make sense to 
> me, but if it's there for a reason it needs a comment.
I don't really know what's the difference between the `0xc0` and `0xe0` opcode. 
Both can be found in various places in LLDB sources. I've copied this one from 
`source/Target/Platform.cpp`). Maybe `0xc0` works on Big Endian ppc as well, 
I've copied `0xe0` because it was used by the relevant code before. I'll 
simplify the code as suggested and try `0xc0`.


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

mgorny wrote:
> jrtc27 wrote:
> > krytarowski wrote:
> > > jrtc27 wrote:
> > > > Why are these two different? Should it not always be `trap` ie `tw 
> > > > 31,0,0`? If not that should be explained here. These names also aren't 
> > > > great as it's unclear which ppc64 is using unless you read the code 
> > > > below (I'd expect either ppc and ppc64 or ppc and ppcle as the two 
> > > > "axes", but ppc and ppc64le are on a diagonal in the 2x2 grid).
> > > On PPC we assume Big-Endian unless specified otherwise, so no need to 
> > > specify ppcbe or ppc64be.
> > I realise why there is no `be` suffix, that's not what I was asking. 
> > Currently there are four options (though ppcle isn't implemented in 
> > FreeBSD):
> > |  | Big | Little |
> > | 32 | ppc | ppcle |
> > | 64 | ppc64 | ppc64le |
> > 
> > If the difference between the two encodings is solely endianness then they 
> > should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the difference 
> > between the two encodings is solely machine word size then they should be 
> > called `g_ppc_opcode` and g_ppc64_opcode`. But `g_ppc_opcode` vs 
> > g_ppc64le_opcode` has *both* differences in the name, which tells you 
> > nothing about *why* they are different, and thus does not obviously state 
> > which encoding ppc64 uses, if either of them.
> > 
> > As for the encodings themselves, they obviously differ in endianness, but 
> > there is also a difference in the second/third byte where `g_ppc_opcode[1]` 
> > is `0xc0` but `g_ppc64le_opcode[2]` is `0xe0`. That does not make sense to 
> > me, but if it's there for a reason it needs a comment.
> I don't really know what's the difference between the `0xc0` and `0xe0` 
> opcode. Both can be found in various places in LLDB sources. I've copied this 
> one from `source/Target/Platform.cpp`). Maybe `0xc0` works on Big Endian ppc 
> as well, I've copied `0xe0` because it was used by the relevant code before. 
> I'll simplify the code as suggested and try `0xc0`.
Sorry, I got the two exchanged. I meant I'm going to try `0xe0`.


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Jessica Clarke via Phabricator via lldb-commits

jrtc27 added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

mgorny wrote:
> mgorny wrote:
> > jrtc27 wrote:
> > > krytarowski wrote:
> > > > jrtc27 wrote:
> > > > > Why are these two different? Should it not always be `trap` ie `tw 
> > > > > 31,0,0`? If not that should be explained here. These names also 
> > > > > aren't great as it's unclear which ppc64 is using unless you read the 
> > > > > code below (I'd expect either ppc and ppc64 or ppc and ppcle as the 
> > > > > two "axes", but ppc and ppc64le are on a diagonal in the 2x2 grid).
> > > > On PPC we assume Big-Endian unless specified otherwise, so no need to 
> > > > specify ppcbe or ppc64be.
> > > I realise why there is no `be` suffix, that's not what I was asking. 
> > > Currently there are four options (though ppcle isn't implemented in 
> > > FreeBSD):
> > > |  | Big | Little |
> > > | 32 | ppc | ppcle |
> > > | 64 | ppc64 | ppc64le |
> > > 
> > > If the difference between the two encodings is solely endianness then 
> > > they should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the 
> > > difference between the two encodings is solely machine word size then 
> > > they should be called `g_ppc_opcode` and g_ppc64_opcode`. But 
> > > `g_ppc_opcode` vs g_ppc64le_opcode` has *both* differences in the name, 
> > > which tells you nothing about *why* they are different, and thus does not 
> > > obviously state which encoding ppc64 uses, if either of them.
> > > 
> > > As for the encodings themselves, they obviously differ in endianness, but 
> > > there is also a difference in the second/third byte where 
> > > `g_ppc_opcode[1]` is `0xc0` but `g_ppc64le_opcode[2]` is `0xe0`. That 
> > > does not make sense to me, but if it's there for a reason it needs a 
> > > comment.
> > I don't really know what's the difference between the `0xc0` and `0xe0` 
> > opcode. Both can be found in various places in LLDB sources. I've copied 
> > this one from `source/Target/Platform.cpp`). Maybe `0xc0` works on Big 
> > Endian ppc as well, I've copied `0xe0` because it was used by the relevant 
> > code before. I'll simplify the code as suggested and try `0xc0`.
> Sorry, I got the two exchanged. I meant I'm going to try `0xe0`.
FWIW 0xc is `tw 30, 0, 0` whereas 0xe is `tw 31, 0, 0` i.e. the canonical 
unconditional trap instruction, which `trap` is an alias for.


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D96202: [lldb/test] Automatically find debug servers to test

2021-02-08 Thread Jonas Devlieghere via Phabricator via lldb-commits

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

This will break my "run the tests against an Xcode install", but it seems like 
I should be able to work around that looking for debugserver in the 
LLDB.framework in `get_debugserver_exe`. Overall this is a pretty nice cleanup 
so seems like a fair trade-off. LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96202

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Kamil Rytarowski via Phabricator via lldb-commits

krytarowski added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

jrtc27 wrote:
> mgorny wrote:
> > mgorny wrote:
> > > jrtc27 wrote:
> > > > krytarowski wrote:
> > > > > jrtc27 wrote:
> > > > > > Why are these two different? Should it not always be `trap` ie `tw 
> > > > > > 31,0,0`? If not that should be explained here. These names also 
> > > > > > aren't great as it's unclear which ppc64 is using unless you read 
> > > > > > the code below (I'd expect either ppc and ppc64 or ppc and ppcle as 
> > > > > > the two "axes", but ppc and ppc64le are on a diagonal in the 2x2 
> > > > > > grid).
> > > > > On PPC we assume Big-Endian unless specified otherwise, so no need to 
> > > > > specify ppcbe or ppc64be.
> > > > I realise why there is no `be` suffix, that's not what I was asking. 
> > > > Currently there are four options (though ppcle isn't implemented in 
> > > > FreeBSD):
> > > > |  | Big | Little |
> > > > | 32 | ppc | ppcle |
> > > > | 64 | ppc64 | ppc64le |
> > > > 
> > > > If the difference between the two encodings is solely endianness then 
> > > > they should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the 
> > > > difference between the two encodings is solely machine word size then 
> > > > they should be called `g_ppc_opcode` and g_ppc64_opcode`. But 
> > > > `g_ppc_opcode` vs g_ppc64le_opcode` has *both* differences in the name, 
> > > > which tells you nothing about *why* they are different, and thus does 
> > > > not obviously state which encoding ppc64 uses, if either of them.
> > > > 
> > > > As for the encodings themselves, they obviously differ in endianness, 
> > > > but there is also a difference in the second/third byte where 
> > > > `g_ppc_opcode[1]` is `0xc0` but `g_ppc64le_opcode[2]` is `0xe0`. That 
> > > > does not make sense to me, but if it's there for a reason it needs a 
> > > > comment.
> > > I don't really know what's the difference between the `0xc0` and `0xe0` 
> > > opcode. Both can be found in various places in LLDB sources. I've copied 
> > > this one from `source/Target/Platform.cpp`). Maybe `0xc0` works on Big 
> > > Endian ppc as well, I've copied `0xe0` because it was used by the 
> > > relevant code before. I'll simplify the code as suggested and try `0xc0`.
> > Sorry, I got the two exchanged. I meant I'm going to try `0xe0`.
> FWIW 0xc is `tw 30, 0, 0` whereas 0xe is `tw 31, 0, 0` i.e. the canonical 
> unconditional trap instruction, which `trap` is an alias for.
NetBSD uses:

`#define PTRACE_BREAKPOINT   ((const uint8_t[]) { 0x7f, 0xe0, 0x00, 0x08 
})`.

https://nxr.netbsd.org/xref/src/sys/arch/powerpc/include/ptrace.h#76


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Jessica Clarke via Phabricator via lldb-commits

jrtc27 added inline comments.



Comment at: lldb/source/Host/common/NativeProcessProtocol.cpp:525-526
   static const uint8_t g_s390x_opcode[] = {0x00, 0x01};
+  static const uint8_t g_ppc_opcode[] = {0x7f, 0xc0, 0x00, 0x08};
   static const uint8_t g_ppc64le_opcode[] = {0x08, 0x00, 0xe0, 0x7f}; // trap
 

krytarowski wrote:
> jrtc27 wrote:
> > mgorny wrote:
> > > mgorny wrote:
> > > > jrtc27 wrote:
> > > > > krytarowski wrote:
> > > > > > jrtc27 wrote:
> > > > > > > Why are these two different? Should it not always be `trap` ie 
> > > > > > > `tw 31,0,0`? If not that should be explained here. These names 
> > > > > > > also aren't great as it's unclear which ppc64 is using unless you 
> > > > > > > read the code below (I'd expect either ppc and ppc64 or ppc and 
> > > > > > > ppcle as the two "axes", but ppc and ppc64le are on a diagonal in 
> > > > > > > the 2x2 grid).
> > > > > > On PPC we assume Big-Endian unless specified otherwise, so no need 
> > > > > > to specify ppcbe or ppc64be.
> > > > > I realise why there is no `be` suffix, that's not what I was asking. 
> > > > > Currently there are four options (though ppcle isn't implemented in 
> > > > > FreeBSD):
> > > > > |  | Big | Little |
> > > > > | 32 | ppc | ppcle |
> > > > > | 64 | ppc64 | ppc64le |
> > > > > 
> > > > > If the difference between the two encodings is solely endianness then 
> > > > > they should be called `g_ppc_opcode` and `g_ppcle_opcode`. If the 
> > > > > difference between the two encodings is solely machine word size then 
> > > > > they should be called `g_ppc_opcode` and g_ppc64_opcode`. But 
> > > > > `g_ppc_opcode` vs g_ppc64le_opcode` has *both* differences in the 
> > > > > name, which tells you nothing about *why* they are different, and 
> > > > > thus does not obviously state which encoding ppc64 uses, if either of 
> > > > > them.
> > > > > 
> > > > > As for the encodings themselves, they obviously differ in endianness, 
> > > > > but there is also a difference in the second/third byte where 
> > > > > `g_ppc_opcode[1]` is `0xc0` but `g_ppc64le_opcode[2]` is `0xe0`. That 
> > > > > does not make sense to me, but if it's there for a reason it needs a 
> > > > > comment.
> > > > I don't really know what's the difference between the `0xc0` and `0xe0` 
> > > > opcode. Both can be found in various places in LLDB sources. I've 
> > > > copied this one from `source/Target/Platform.cpp`). Maybe `0xc0` works 
> > > > on Big Endian ppc as well, I've copied `0xe0` because it was used by 
> > > > the relevant code before. I'll simplify the code as suggested and try 
> > > > `0xc0`.
> > > Sorry, I got the two exchanged. I meant I'm going to try `0xe0`.
> > FWIW 0xc is `tw 30, 0, 0` whereas 0xe is `tw 31, 0, 0` i.e. the canonical 
> > unconditional trap instruction, which `trap` is an alias for.
> NetBSD uses:
> 
> `#define PTRACE_BREAKPOINT   ((const uint8_t[]) { 0x7f, 0xe0, 0x00, 0x08 
> })`.
> 
> https://nxr.netbsd.org/xref/src/sys/arch/powerpc/include/ptrace.h#76
Looking things up in more detail, the first value is a bit mask of conditions 
under which to trap (signed <, signed >, =, unsigned <, unsigned >), so if the 
same register is given twice it'll trap if and only if the third bit is set in 
the TO (trap operand?) field. Thus 30 and 31 should be entirely equivalent 
here, and I imagine it's best to use 31 (i.e. what ppc64le already uses) due to 
being the canonical version.


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

https://reviews.llvm.org/D95947

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

Re: [Lldb-commits] [lldb] 5a63045 - [LLDB] Fix `Wunused-result` warning

2021-02-08 Thread David Blaikie via lldb-commits

Might be worth making an "execution override" object that has a dtor
to do the cleanup?

On Mon, Feb 8, 2021 at 9:10 AM Frederik Gossen via lldb-commits
 wrote:
>
>
> Author: Frederik Gossen
> Date: 2021-02-08T18:10:08+01:00
> New Revision: 5a63045fe78834937785ed5081052e083a98077f
>
> URL: 
> https://github.com/llvm/llvm-project/commit/5a63045fe78834937785ed5081052e083a98077f
> DIFF: 
> https://github.com/llvm/llvm-project/commit/5a63045fe78834937785ed5081052e083a98077f.diff
>
> LOG: [LLDB] Fix `Wunused-result` warning
>
> Added:
>
>
> Modified:
> lldb/source/Interpreter/CommandInterpreter.cpp
>
> Removed:
>
>
>
> 
> diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
> b/lldb/source/Interpreter/CommandInterpreter.cpp
> index 0b25abc9cdea..a7afa1034762 100644
> --- a/lldb/source/Interpreter/CommandInterpreter.cpp
> +++ b/lldb/source/Interpreter/CommandInterpreter.cpp
> @@ -2832,7 +2832,9 @@ void 
> CommandInterpreter::IOHandlerInputComplete(IOHandler &io_handler,
>StartHandlingCommand();
>
>OverrideExecutionContext(m_debugger.GetSelectedExecutionContext());
> -  llvm::make_scope_exit([this]() { RestoreExecutionContext(); });
> +  auto finalize = llvm::make_scope_exit([this]() {
> +RestoreExecutionContext();
> +  });
>
>lldb_private::CommandReturnObject result(m_debugger.GetUseColor());
>HandleCommand(line.c_str(), eLazyBoolCalculate, result);
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny updated this revision to Diff 322208.
mgorny added a comment.

Improve consistency of trap opcodes.


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

https://reviews.llvm.org/D95947

Files:
  lldb/source/Host/common/NativeProcessProtocol.cpp
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_powerpc.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_powerpc.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_powerpc.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -19,7 +19,9 @@
 
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_i386.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
+#include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterContextPOSIX_powerpc.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 #include "Plugins/Process/Utility/lldb-arm-register-enums.h"
@@ -458,3 +460,95 @@
 }
 
 #endif // defined(__mips64__)
+
+#if defined(__powerpc__)
+
+#define EXPECT_GPR_PPC(lldb_reg, fbsd_reg)\
+  EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_powerpc),  \
+  ::testing::Pair(offsetof(reg, fbsd_reg),   \
+  sizeof(reg::fbsd_reg)))
+#define EXPECT_FPU_PPC(lldb_reg, fbsd_reg)   \
+  EXPECT_THAT(GetRegParams(reg_ctx, fpr_##lldb_reg##_powerpc),   \
+  ::testing::Pair(offsetof(fpreg, fbsd_reg) + base_offset, \
+  sizeof(fpreg::fbsd_reg)))
+
+TEST(RegisterContextFreeBSDTest, powerpc32) {
+  ArchSpec arch{"powerpc-unknown-freebsd"};
+  RegisterContextFreeBSD_powerpc32 reg_ctx{arch};
+
+  EXPECT_GPR_PPC(r0, fixreg[0]);
+  EXPECT_GPR_PPC(r1, fixreg[1]);
+  EXPECT_GPR_PPC(r2, fixreg[2]);
+  EXPECT_GPR_PPC(r3, fixreg[3]);
+  EXPECT_GPR_PPC(r4, fixreg[4]);
+  EXPECT_GPR_PPC(r5, fixreg[5]);
+  EXPECT_GPR_PPC(r6, fixreg[6]);
+  EXPECT_GPR_PPC(r7, fixreg[7]);
+  EXPECT_GPR_PPC(r8, fixreg[8]);
+  EXPECT_GPR_PPC(r9, fixreg[9]);
+  EXPECT_GPR_PPC(r10, fixreg[10]);
+  EXPECT_GPR_PPC(r11, fixreg[11]);
+  EXPECT_GPR_PPC(r12, fixreg[12]);
+  EXPECT_GPR_PPC(r13, fixreg[13]);
+  EXPECT_GPR_PPC(r14, fixreg[14]);
+  EXPECT_GPR_PPC(r15, fixreg[15]);
+  EXPECT_GPR_PPC(r16, fixreg[16]);
+  EXPECT_GPR_PPC(r17, fixreg[17]);
+  EXPECT_GPR_PPC(r18, fixreg[18]);
+  EXPECT_GPR_PPC(r19, fixreg[19]);
+  EXPECT_GPR_PPC(r20, fixreg[20]);
+  EXPECT_GPR_PPC(r21, fixreg[21]);
+  EXPECT_GPR_PPC(r22, fixreg[22]);
+  EXPECT_GPR_PPC(r23, fixreg[23]);
+  EXPECT_GPR_PPC(r24, fixreg[24]);
+  EXPECT_GPR_PPC(r25, fixreg[25]);
+  EXPECT_GPR_PPC(r26, fixreg[26]);
+  EXPECT_GPR_PPC(r27, fixreg[27]);
+  EXPECT_GPR_PPC(r28, fixreg[28]);
+  EXPECT_GPR_PPC(r29, fixreg[29]);
+  EXPECT_GPR_PPC(r30, fixreg[30]);
+  EXPECT_GPR_PPC(r31, fixreg[31]);
+  EXPECT_GPR_PPC(lr, lr);
+  EXPECT_GPR_PPC(cr, cr);
+  EXPECT_GPR_PPC(xer, xer);
+  EXPECT_GPR_PPC(ctr, ctr);
+  EXPECT_GPR_PPC(pc, pc);
+
+  size_t base_offset = reg_ctx.GetRegisterInfo()[fpr_f0_powerpc].byte_offset;
+
+  EXPECT_FPU_PPC(f0, fpreg[0]);
+  EXPECT_FPU_PPC(f1, fpreg[1]);
+  EXPECT_FPU_PPC(f2, fpreg[2]);
+  EXPECT_FPU_PPC(f3, fpreg[3]);
+  EXPECT_FPU_PPC(f4, fpreg[4]);
+  EXPECT_FPU_PPC(f5, fpreg[5]);
+  EXPECT_FPU_PPC(f6, fpreg[6]);
+  EXPECT_FPU_PPC(f7, fpreg[7]);
+  EXPECT_FPU_PPC(f8, fpreg[8]);
+  EXPECT_FPU_PPC(f9, fpreg[9]);
+  EXPECT_FPU_PPC(f10, fpreg[10]);
+  EXPECT_FPU_PPC(f11, fpreg[11]);
+  EXPECT_FPU_PPC(f12, fpreg[12]);
+  EXPECT_FPU_PPC(f13, fpreg[13]);
+  EXPECT_FPU_PPC(f14, fpreg[14]);
+  EXPECT_FPU_PPC(f15, fpreg[15]);
+  EXPECT_FPU_PPC(f16, fpreg[16]);
+  EXPECT_FPU_PPC(f17, fpreg[17]);
+  EXPECT_FPU_PPC(f18, fpreg[18]);
+  EXPECT_FPU_PPC(f19, fpreg[19]);
+  EXPECT_FPU_PPC(f20, fpreg[20]);
+  EXPECT_FPU_PPC(f21, fpreg[21]);
+  EXPECT_FPU_PPC(f22, fpreg[22]);
+  EXPECT_FPU_PPC(f23, fpreg[23]);
+  EXPECT_FPU_PPC(f24, fpreg[24]);
+  EXPECT_FPU_PPC(f25, fpreg[25]);
+  EXPECT_FPU_PPC(f26, fpreg[26]);
+  EXPECT_FPU_PPC(f27, fpreg[27]);
+  EXPECT_FPU_PPC(f28, fpreg[28]);
+  EXPECT_FPU_PPC(f29, fpreg[29]);
+  EXPECT_FPU_PPC(f30, fpreg[30]);
+  EXPECT_FPU_PPC(f31, fpreg[31]);
+  EXPECT_FPU_PPC(fpscr, fpscr);
+}
+
+#endif // defined(__powerpc__)
Index: lldb/source/Plugins/Process/Utility/RegisterInfos_powerpc.h
===
--- lldb/source/Plugins

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Michał Górny via Phabricator via lldb-commits

mgorny marked 6 inline comments as done.
mgorny added a comment.

@jrtc27 , does this look good?


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D96276: [lldb] Inline invariant params to AppleThreadPlanStepThrough (NFC)

2021-02-08 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

In D96276#2549406 , @kastiglione wrote:

> In D96276#2549007 , @jingham wrote:
>
>> It still seems to me like a trampoline which knew that to implement itself, 
>> all it had to do was a couple of stepi's - for instance if a dyld stub knew 
>> that the stub had been filled in and would jump straight to the target, it 
>> could run without letting the other threads go.  That's actually something 
>> the dyld stubs could figure out, they just don't at present. So I'd rather 
>> not remove this control.
>
> Happy to restore the stop_others parameter, but for my understanding I have 
> two questions:
>
> 1. Is the behavior you envision something that applies to these specific 
> thread plan subclasses (ie not dyld stubs)
> 2. Will callers decide to stop others from the outside, or is the decision to 
> stop others something that these subclasses would make internally?

Good questions.  I was reading this incorrectly.  This is the enqueuing plan 
telling the StepThrough plan whether to stop others.  That actually seems like 
a bad thing to do, since the enqueuer can't really know whether it is actually 
safe to stop others while running the enqueued plan.  These should go.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96276

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

[Lldb-commits] [PATCH] D95947: [lldb] [Process/FreeBSDRemote] Introduce powerpc support

2021-02-08 Thread Jessica Clarke via Phabricator via lldb-commits

jrtc27 accepted this revision.
jrtc27 added a comment.

In D95947#2549599 , @mgorny wrote:

> @jrtc27 , does this look good?

Yep, assuming it still works.


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

https://reviews.llvm.org/D95947

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

[Lldb-commits] [PATCH] D96307: [lldb] Fix crash in FormatEntity for mangled-name

2021-02-08 Thread Dave Lee via Phabricator via lldb-commits

kastiglione created this revision.
kastiglione added a reviewer: mib.
kastiglione requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Check a `Block` pointer before dereferencing.

Using `function.mangled-name` led to a crash for a frame where the symbol
context had no block info. In my case, the frame's function was a system frame.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96307

Files:
  lldb/source/Core/FormatEntity.cpp


Index: lldb/source/Core/FormatEntity.cpp
===
--- lldb/source/Core/FormatEntity.cpp
+++ lldb/source/Core/FormatEntity.cpp
@@ -1769,7 +1769,7 @@
   return false;
 s.PutCString(name);
 
-if (sc->block->GetContainingInlinedBlock()) {
+if (sc->block && sc->block->GetContainingInlinedBlock()) {
   if (const InlineFunctionInfo *inline_info =
   sc->block->GetInlinedFunctionInfo()) {
 s.PutCString(" [inlined] ");


Index: lldb/source/Core/FormatEntity.cpp
===
--- lldb/source/Core/FormatEntity.cpp
+++ lldb/source/Core/FormatEntity.cpp
@@ -1769,7 +1769,7 @@
   return false;
 s.PutCString(name);
 
-if (sc->block->GetContainingInlinedBlock()) {
+if (sc->block && sc->block->GetContainingInlinedBlock()) {
   if (const InlineFunctionInfo *inline_info =
   sc->block->GetInlinedFunctionInfo()) {
 s.PutCString(" [inlined] ");
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D96307: [lldb] Fix crash in FormatEntity for mangled-name

2021-02-08 Thread Med Ismail Bennani via Phabricator via lldb-commits

mib accepted this revision.
mib added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: JDevlieghere.

LGTM! Thanks for catching that!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96307

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

[Lldb-commits] [lldb] 7dc324a - [lldb] Fix crash in FormatEntity for mangled-name

2021-02-08 Thread Dave Lee via lldb-commits


Author: Dave Lee
Date: 2021-02-08T18:38:08-08:00
New Revision: 7dc324aafa2b17a4f9a992b9727a3642505053a6

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

LOG: [lldb] Fix crash in FormatEntity for mangled-name

Check a `Block` pointer before dereferencing.

Using `function.mangled-name` led to a crash for a frame where the symbol
context had no block info. In my case, the frame's function was a system frame.

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

Added: 


Modified: 
lldb/source/Core/FormatEntity.cpp

Removed: 




diff  --git a/lldb/source/Core/FormatEntity.cpp 
b/lldb/source/Core/FormatEntity.cpp
index d491ac14bec8..0ffd59938897 100644
--- a/lldb/source/Core/FormatEntity.cpp
+++ b/lldb/source/Core/FormatEntity.cpp
@@ -1769,7 +1769,7 @@ bool FormatEntity::Format(const Entry &entry, Stream &s,
   return false;
 s.PutCString(name);
 
-if (sc->block->GetContainingInlinedBlock()) {
+if (sc->block && sc->block->GetContainingInlinedBlock()) {
   if (const InlineFunctionInfo *inline_info =
   sc->block->GetInlinedFunctionInfo()) {
 s.PutCString(" [inlined] ");



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

[Lldb-commits] [PATCH] D96307: [lldb] Fix crash in FormatEntity for mangled-name

2021-02-08 Thread Dave Lee via 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 rG7dc324aafa2b: [lldb] Fix crash in FormatEntity for 
mangled-name (authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96307

Files:
  lldb/source/Core/FormatEntity.cpp


Index: lldb/source/Core/FormatEntity.cpp
===
--- lldb/source/Core/FormatEntity.cpp
+++ lldb/source/Core/FormatEntity.cpp
@@ -1769,7 +1769,7 @@
   return false;
 s.PutCString(name);
 
-if (sc->block->GetContainingInlinedBlock()) {
+if (sc->block && sc->block->GetContainingInlinedBlock()) {
   if (const InlineFunctionInfo *inline_info =
   sc->block->GetInlinedFunctionInfo()) {
 s.PutCString(" [inlined] ");


Index: lldb/source/Core/FormatEntity.cpp
===
--- lldb/source/Core/FormatEntity.cpp
+++ lldb/source/Core/FormatEntity.cpp
@@ -1769,7 +1769,7 @@
   return false;
 s.PutCString(name);
 
-if (sc->block->GetContainingInlinedBlock()) {
+if (sc->block && sc->block->GetContainingInlinedBlock()) {
   if (const InlineFunctionInfo *inline_info =
   sc->block->GetInlinedFunctionInfo()) {
 s.PutCString(" [inlined] ");
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

47 matches

Mail list logo