Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

2015-11-14 Thread Daniel Sanders via lldb-commits 
dsanders added a comment.

> The route cause of your problem is that ReadRegisterUnsigned returns a value 
> where the 32 MSB is garbage while the

>  expected behavior is to zero out those bits (it works on i386 and arm 
> AFAIK). You should find out why that is happening

>  and fix the root cause of it what will fix your single stepping issue as 
> well.


I don't know if this is important to problem or not, but I think I should 
mention that the expectation of zero bits disagrees with MIPS hardware. MIPS 
hardware would expect the 32 MSB to be a sign-extension of the 32 LSB.

As part of our forward compatibility strategy, we widen registers (e.g. from 
MIPS32 to MIPS64) by sign extending the values produced by every operation that 
existed before and add additional operations as needed (e.g. MIPS64 adds 'lwu' 
which is a unsigned 32-bit load). Admittedly it's a bit unintuitive for an 
unsigned 32-bit value from a MIPS32 binary to be represented in a 64-bit 
register as, for example, 0x8000 but the debugger shouldn't 
normally admit to the existence of the extra bits when debugging 32-bit code so 
the user won't normally see this.

Another result of this is that our address space grows at both ends and the 
previous address space is in the middle like so:

  MIPS64's extra user space | MIPS32's user space | MIPS32's kernel space | 
MIPS64's extra kernel space.

Hope this helps


Repository:
  rL LLVM

http://reviews.llvm.org/D14633



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

[Lldb-commits] [lldb] r247703 - Fix build after llvm r247683 was reverted.

2015-09-15 Thread Daniel Sanders via lldb-commits 
Author: dsanders
Date: Tue Sep 15 11:33:17 2015
New Revision: 247703

URL: http://llvm.org/viewvc/llvm-project?rev=247703&view=rev
Log:
Fix build after llvm r247683 was reverted.


Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp

Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp?rev=247703&r1=247702&r2=247703&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp Tue Sep 
15 11:33:17 2015
@@ -506,7 +506,7 @@ DisassemblerLLVMC::LLVMCDisassembler::LL
 asm_printer_variant = flavor;
 }
 
-
m_instr_printer_ap.reset(curr_target->createMCInstPrinter(llvm::TargetTuple{llvm::Triple{triple}},
+
m_instr_printer_ap.reset(curr_target->createMCInstPrinter(llvm::Triple{triple},
   
asm_printer_variant,
   
*m_asm_info_ap.get(),
   
*m_instr_info_ap.get(),


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

[Lldb-commits] [PATCH] D12900: Fix link failures when BUILD_SHARED_LIBS=ON.

2015-09-16 Thread Daniel Sanders via lldb-commits 
dsanders created this revision.
dsanders added a subscriber: lldb-commits.

http://reviews.llvm.org/D12900

Files:
  tools/lldb-server/CMakeLists.txt

Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -26,10 +26,19 @@
 LLDBServerUtilities.cpp
 )
 
-  target_link_libraries(lldb-server liblldb)
+  target_link_libraries(lldb-server liblldb dl)
   if (HAVE_LIBPTHREAD)
 target_link_libraries(lldb-server pthread)
   endif ()
+  if (LIBXML2_FOUND)
+target_link_libraries(lldb-server xml2)
+  endif()
+  if (NOT LLDB_DISABLE_LIBEDIT)
+target_link_libraries(lldb-server edit)
+  endif()
+  if (NOT LLDB_DISABLE_CURSES)
+target_link_libraries(lldb-server ncurses panel)
+  endif()
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp


Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -26,10 +26,19 @@
 LLDBServerUtilities.cpp
 )
 
-  target_link_libraries(lldb-server liblldb)
+  target_link_libraries(lldb-server liblldb dl)
   if (HAVE_LIBPTHREAD)
 target_link_libraries(lldb-server pthread)
   endif ()
+  if (LIBXML2_FOUND)
+target_link_libraries(lldb-server xml2)
+  endif()
+  if (NOT LLDB_DISABLE_LIBEDIT)
+target_link_libraries(lldb-server edit)
+  endif()
+  if (NOT LLDB_DISABLE_CURSES)
+target_link_libraries(lldb-server ncurses panel)
+  endif()
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D12900: Fix link failures when BUILD_SHARED_LIBS=ON.

2015-09-16 Thread Daniel Sanders via lldb-commits 
dsanders added a comment.

This patch does the trick for me but I'm not certain it's the right fix 
overall. Could someone take a look?


http://reviews.llvm.org/D12900



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

Re: [Lldb-commits] [PATCH] D12900: Fix link failures when BUILD_SHARED_LIBS=ON.

2015-09-18 Thread Daniel Sanders via lldb-commits 
dsanders updated this revision to Diff 35075.
dsanders added a comment.

Pavel's suggestion to use LLDB_SYSTEM_LIBS works for me. Updated the patch.


http://reviews.llvm.org/D12900

Files:
  tools/lldb-server/CMakeLists.txt

Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -30,6 +30,7 @@
   if (HAVE_LIBPTHREAD)
 target_link_libraries(lldb-server pthread)
   endif ()
+  target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp


Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -30,6 +30,7 @@
   if (HAVE_LIBPTHREAD)
 target_link_libraries(lldb-server pthread)
   endif ()
+  target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D12964: [lldb-server] No need to add pthread twice.

2015-09-18 Thread Daniel Sanders via lldb-commits 
dsanders created this revision.
dsanders added subscribers: krytarowski, labath, lldb-commits.

Following on from r247991:
pthread is in LLDB_SYSTEM_LIBS so there's no need to explicitly add it to the 
link.

http://reviews.llvm.org/D12964

Files:
  tools/lldb-server/CMakeLists.txt

Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,7 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
+  target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp


Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,7 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
+  target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
 lldb-gdbserver.cpp
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D12964: [lldb-server] No need to add pthread twice.

2015-09-18 Thread Daniel Sanders via lldb-commits 
dsanders updated this revision to Diff 35086.
dsanders added a comment.

Correct the patch. Arcanist created the diff based on a revision prior to 
r247991 for some reason.


http://reviews.llvm.org/D12964

Files:
  tools/lldb-server/CMakeLists.txt

Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,6 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
   target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server


Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,6 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
   target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D12964: [lldb-server] No need to add pthread twice.

2015-09-21 Thread Daniel Sanders via lldb-commits 
dsanders added a comment.

Thanks. I've acquired a new link failure (this time on lldb-mi) since my last 
build so I'll commit this once I have a temporary fix in place for that and can 
run the tests again.


http://reviews.llvm.org/D12964



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

Re: [Lldb-commits] [PATCH] D12964: [lldb-server] No need to add pthread twice.

2015-09-21 Thread Daniel Sanders via lldb-commits 
dsanders added a comment.

'ninja clean' seems to have made the lldb-mi link failure go away. Presumably 
something didn't rebuild when the references to llvm_regcomp and llvm_regfree 
were added.

I'll run the lldb tests and then commit this.


http://reviews.llvm.org/D12964



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

[Lldb-commits] [lldb] r248177 - [lldb-server] No need to add pthread twice.

2015-09-21 Thread Daniel Sanders via lldb-commits 
Author: dsanders
Date: Mon Sep 21 12:23:22 2015
New Revision: 248177

URL: http://llvm.org/viewvc/llvm-project?rev=248177&view=rev
Log:
[lldb-server] No need to add pthread twice.

Summary:
Following on from r247991:
pthread is in LLDB_SYSTEM_LIBS so there's no need to explicitly add it to the 
link.

Reviewers: labath

Subscribers: lldb-commits, labath, krytarowski

Differential Revision: http://reviews.llvm.org/D12964


Modified:
lldb/trunk/tools/lldb-server/CMakeLists.txt

Modified: lldb/trunk/tools/lldb-server/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/CMakeLists.txt?rev=248177&r1=248176&r2=248177&view=diff
==
--- lldb/trunk/tools/lldb-server/CMakeLists.txt (original)
+++ lldb/trunk/tools/lldb-server/CMakeLists.txt Mon Sep 21 12:23:22 2015
@@ -27,9 +27,6 @@ if (BUILD_SHARED_LIBS )
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
   target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server


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

Re: [Lldb-commits] [PATCH] D12964: [lldb-server] No need to add pthread twice.

2015-09-21 Thread Daniel Sanders via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL248177: [lldb-server] No need to add pthread twice. 
(authored by dsanders).

Changed prior to commit:
  http://reviews.llvm.org/D12964?vs=35086&id=35277#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12964

Files:
  lldb/trunk/tools/lldb-server/CMakeLists.txt

Index: lldb/trunk/tools/lldb-server/CMakeLists.txt
===
--- lldb/trunk/tools/lldb-server/CMakeLists.txt
+++ lldb/trunk/tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,6 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
   target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server


Index: lldb/trunk/tools/lldb-server/CMakeLists.txt
===
--- lldb/trunk/tools/lldb-server/CMakeLists.txt
+++ lldb/trunk/tools/lldb-server/CMakeLists.txt
@@ -27,9 +27,6 @@
 )
 
   target_link_libraries(lldb-server liblldb)
-  if (HAVE_LIBPTHREAD)
-target_link_libraries(lldb-server pthread)
-  endif ()
   target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
 else()
   add_lldb_executable(lldb-server
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D13027: [lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.

2015-09-21 Thread Daniel Sanders via lldb-commits 
dsanders created this revision.
dsanders added subscribers: lldb-commits, labath, krytarowski.

http://reviews.llvm.org/D13027

Files:
  tools/lldb-mi/CMakeLists.txt

Index: tools/lldb-mi/CMakeLists.txt
===
--- tools/lldb-mi/CMakeLists.txt
+++ tools/lldb-mi/CMakeLists.txt
@@ -83,6 +83,8 @@
 )
 endif ()
 
+include(../../cmake/LLDBDependencies.cmake)
+
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -92,7 +94,7 @@
 
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
-#llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
+llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})
 


Index: tools/lldb-mi/CMakeLists.txt
===
--- tools/lldb-mi/CMakeLists.txt
+++ tools/lldb-mi/CMakeLists.txt
@@ -83,6 +83,8 @@
 )
 endif ()
 
+include(../../cmake/LLDBDependencies.cmake)
+
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -92,7 +94,7 @@
 
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
-#llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
+llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13027: [lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.

2015-09-21 Thread Daniel Sanders via lldb-commits 
dsanders added a comment.

It seems I spoke too soon when I said the link error went away after a clean 
build. This patch fixes it.


http://reviews.llvm.org/D13027



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

[Lldb-commits] [lldb] r248251 - [lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.

2015-09-22 Thread Daniel Sanders via lldb-commits 
Author: dsanders
Date: Tue Sep 22 04:08:44 2015
New Revision: 248251

URL: http://llvm.org/viewvc/llvm-project?rev=248251&view=rev
Log:
[lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.

Subscribers: krytarowski, labath, lldb-commits

Differential Revision: http://reviews.llvm.org/D13027

Modified:
lldb/trunk/tools/lldb-mi/CMakeLists.txt

Modified: lldb/trunk/tools/lldb-mi/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/CMakeLists.txt?rev=248251&r1=248250&r2=248251&view=diff
==
--- lldb/trunk/tools/lldb-mi/CMakeLists.txt (original)
+++ lldb/trunk/tools/lldb-mi/CMakeLists.txt Tue Sep 22 04:08:44 2015
@@ -83,6 +83,8 @@ if ( CMAKE_SYSTEM_NAME MATCHES "Windows"
 )
 endif ()
 
+include(../../cmake/LLDBDependencies.cmake)
+
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -92,7 +94,7 @@ endif ()
 
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
-#llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
+llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})
 


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

Re: [Lldb-commits] [PATCH] D13027: [lldb-mi] Fix unresolved reference to llvm_regcomp and llvm_regfree.

2015-09-22 Thread Daniel Sanders via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL248251: [lldb-mi] Fix unresolved reference to llvm_regcomp 
and llvm_regfree. (authored by dsanders).

Changed prior to commit:
  http://reviews.llvm.org/D13027?vs=35278&id=35351#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13027

Files:
  lldb/trunk/tools/lldb-mi/CMakeLists.txt

Index: lldb/trunk/tools/lldb-mi/CMakeLists.txt
===
--- lldb/trunk/tools/lldb-mi/CMakeLists.txt
+++ lldb/trunk/tools/lldb-mi/CMakeLists.txt
@@ -83,6 +83,8 @@
 )
 endif ()
 
+include(../../cmake/LLDBDependencies.cmake)
+
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -92,7 +94,7 @@
 
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
-#llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
+llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})
 


Index: lldb/trunk/tools/lldb-mi/CMakeLists.txt
===
--- lldb/trunk/tools/lldb-mi/CMakeLists.txt
+++ lldb/trunk/tools/lldb-mi/CMakeLists.txt
@@ -83,6 +83,8 @@
 )
 endif ()
 
+include(../../cmake/LLDBDependencies.cmake)
+
 add_lldb_executable(lldb-mi ${LLDB_MI_SOURCES})
 
 target_link_libraries(lldb-mi liblldb)
@@ -92,7 +94,7 @@
 
 # TODO: why isn't this done by add_lldb_executable?
 #target_link_libraries(lldb-mi ${LLDB_USED_LIBS})
-#llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
+llvm_config(lldb-mi ${LLVM_LINK_COMPONENTS})
 
 set_target_properties(lldb-mi PROPERTIES VERSION ${LLDB_VERSION})
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-28 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/150732

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/4] [lldb] Implement DW_CFA_val_offset and
 DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+register_number; // in eRegisterKindLLDB register numbering system
+uint64_t offset;
+  } reg_plus_offset;
 } location;
   };
 
diff --git a/lldb/source/Symbol/DWARFCallFrameInfo.cpp 
b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
index a2d748adad64a..2f8f9e9182fb2 100644
--- a/lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -766,8 +766,32 @@ DWARFCallFrameI

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-28 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/150732

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/3] [lldb] Implement DW_CFA_val_offset and
 DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+register_number; // in eRegisterKindLLDB register numbering system
+uint64_t offset;
+  } reg_plus_offset;
 } location;
   };
 
diff --git a/lldb/source/Symbol/DWARFCallFrameInfo.cpp 
b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
index a2d748adad64a..2f8f9e9182fb2 100644
--- a/lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -766,8 +766,32 @@ DWARFCallFrameI

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-28 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

While looking into that, I found a couple mistakes that made me question how it 
managed to work and I found that that bit is not actually used. 
ConcreteRegisterLocation uses eRegisterIsRegisterPlusOffset for all 
reg+offset's including reg=CFA, but AbstractRegisterLocation has a specific 
isCFAPlusOffset for the reg=CFA case so I didn't need to add 
isOtherRegisterPlusOffset

I just pushed an update that removes that unnecessary code and fixes the 
clang-format issue raised by the bot

https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-25 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm created 
https://github.com/llvm/llvm-project/pull/150732

The test for this is artificial as I'm not aware of any upstream targets that 
use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to 
obtain the CFA unless all success/failure cases emit logs that clearly identify 
the method it was attempting. Previously several of the existing failure paths 
emit no message or a message that's indistinguishable from those on other paths.

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+re

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-08-04 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/150732

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/7] [lldb] Implement DW_CFA_val_offset and
 DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+register_number; // in eRegisterKindLLDB register numbering system
+uint64_t offset;
+  } reg_plus_offset;
 } location;
   };
 
diff --git a/lldb/source/Symbol/DWARFCallFrameInfo.cpp 
b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
index a2d748adad64a..2f8f9e9182fb2 100644
--- a/lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -766,8 +766,32 @@ DWARFCallFrameI

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-08-04 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

That makes sense, I've added the command and switched to register read to avoid 
the expression evaluator

https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-08-05 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm closed 
https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-30 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/150732

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/6] [lldb] Implement DW_CFA_val_offset and
 DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+register_number; // in eRegisterKindLLDB register numbering system
+uint64_t offset;
+  } reg_plus_offset;
 } location;
   };
 
diff --git a/lldb/source/Symbol/DWARFCallFrameInfo.cpp 
b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
index a2d748adad64a..2f8f9e9182fb2 100644
--- a/lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -766,8 +766,32 @@ DWARFCallFrameI

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-30 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/150732

>From bd27929645928939f319dc915da1a4636e4d317d Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Wed, 28 Aug 2024 19:02:21 -0700
Subject: [PATCH 1/5] [lldb] Implement DW_CFA_val_offset and
 DW_CFA_val_offset_sf

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting to
obtain the CFA unless all success/failure cases emit logs that clearly
identify the method it was attempting. Previously several of the existing
failure paths emit no message or a message that's indistinguishable from
those on other paths.
---
 lldb/include/lldb/Symbol/UnwindPlan.h |  20 +++
 lldb/include/lldb/Target/UnwindLLDB.h |   8 ++
 lldb/source/Symbol/DWARFCallFrameInfo.cpp |  28 +++-
 lldb/source/Symbol/UnwindPlan.cpp |  17 +++
 lldb/source/Target/RegisterContextUnwind.cpp  |  54 +++-
 .../Symbol/TestDWARFCallFrameInfo.cpp | 124 ++
 6 files changed, 248 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Symbol/UnwindPlan.h 
b/lldb/include/lldb/Symbol/UnwindPlan.h
index fe8081f83c590..9587f1312aa2e 100644
--- a/lldb/include/lldb/Symbol/UnwindPlan.h
+++ b/lldb/include/lldb/Symbol/UnwindPlan.h
@@ -67,6 +67,7 @@ class UnwindPlan {
 atAFAPlusOffset,   // reg = deref(AFA + offset)
 isAFAPlusOffset,   // reg = AFA + offset
 inOtherRegister,   // reg = other reg
+isOtherRegisterPlusOffset, // reg = other reg + offset
 atDWARFExpression, // reg = deref(eval(dwarf_expr))
 isDWARFExpression, // reg = eval(dwarf_expr)
 isConstant // reg = constant
@@ -102,6 +103,10 @@ class UnwindPlan {
 
   bool IsInOtherRegister() const { return m_type == inOtherRegister; }
 
+  bool IsOtherRegisterPlusOffset() const {
+return m_type == isOtherRegisterPlusOffset;
+  }
+
   bool IsAtDWARFExpression() const { return m_type == atDWARFExpression; }
 
   bool IsDWARFExpression() const { return m_type == isDWARFExpression; }
@@ -140,9 +145,17 @@ class UnwindPlan {
 m_location.reg_num = reg_num;
   }
 
+  void SetIsRegisterPlusOffset(uint32_t reg_num, int32_t offset = 0) {
+m_type = isOtherRegisterPlusOffset;
+m_location.reg_plus_offset.reg_num = reg_num;
+m_location.reg_plus_offset.offset = offset;
+  }
+
   uint32_t GetRegisterNumber() const {
 if (m_type == inOtherRegister)
   return m_location.reg_num;
+if (m_type == isOtherRegisterPlusOffset)
+  return m_location.reg_plus_offset.reg_num;
 return LLDB_INVALID_REGNUM;
   }
 
@@ -156,6 +169,8 @@ class UnwindPlan {
 case atAFAPlusOffset:
 case isAFAPlusOffset:
   return m_location.offset;
+case inOtherRegister:
+  return m_location.reg_plus_offset.offset;
 default:
   return 0;
 }
@@ -204,6 +219,11 @@ class UnwindPlan {
 } expr;
 // For m_type == isConstant
 uint64_t constant_value;
+// For m_type == inOtherRegisterPlusOffset
+struct {
+  uint32_t reg_num;
+  int32_t offset;
+} reg_plus_offset;
   } m_location;
 };
 
diff --git a/lldb/include/lldb/Target/UnwindLLDB.h 
b/lldb/include/lldb/Target/UnwindLLDB.h
index f2f65e67a7640..88180b37fd93a 100644
--- a/lldb/include/lldb/Target/UnwindLLDB.h
+++ b/lldb/include/lldb/Target/UnwindLLDB.h
@@ -49,6 +49,9 @@ class UnwindLLDB : public lldb_private::Unwind {
   // target mem (target_memory_location)
   eRegisterInRegister, // register is available in a (possible other)
// register (register_number)
+  eRegisterIsRegisterPlusOffset, // register is available in a (possible
+ // other) register (register_number) with
+ // an offset applied
   eRegisterSavedAtHostMemoryLocation, // register is saved at a word in
   // lldb's address space
   eRegisterValueInferred,// register val was computed (and is in
@@ -64,6 +67,11 @@ class UnwindLLDB : public lldb_private::Unwind {
   void *host_memory_location;
   uint64_t inferred_value; // eRegisterValueInferred - e.g. stack pointer 
==
// cfa + offset
+  struct {
+uint32_t
+register_number; // in eRegisterKindLLDB register numbering system
+uint64_t offset;
+  } reg_plus_offset;
 } location;
   };
 
diff --git a/lldb/source/Symbol/DWARFCallFrameInfo.cpp 
b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
index a2d748adad64a..2f8f9e9182fb2 100644
--- a/lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ b/lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -766,8 +766,32 @@ DWARFCallFrameI

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-30 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

I've added a test case to confirm it is read correctly computing the value. As 
I pushed it, it occurred to me that I should make the offset non-zero so I'll 
fix that quick.

I don't think the non-standard return pointer bit from 
eh-frame-dwarf-unwind.test should be necessary but if I remove it, lldb starts 
trying to read the code instead of using the CFI and it stops unwinding 
correctly

https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Implement DW_CFA_val_offset and DW_CFA_val_offset_sf (PR #150732)

2025-07-29 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

I don't think combining them in ConcreteRegisterLocation completely makes sense 
like it did for AbstractRegisterLocation because there's a difference in 
semantics. eRegisterInRegister refers to a storage location whereas 
eRegisterIsRegisterPlusOffset is a computed value without any storage.

It's true they're very similar in ReadRegisterValueFromRegisterLocation() and 
we could potentially combine those two implementations in that function, but 
there's nowhere to write eRegisterIsRegisterPlusOffset to in 
WriteRegisterValueToRegisterLocation(). I could conditionally drop the write if 
offset != 0 but I think it's potentially confusing to have the semantics depend 
on the values rather than the enumerator

https://github.com/llvm/llvm-project/pull/150732
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-08-22 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm created 
https://github.com/llvm/llvm-project/pull/155000

This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targets which are
not yet able to evaluate on the target.

As far as I know most targets have a vector memory layout that matches the
IR element order. Most little endian targets choose to use a little endian
element order, and two out of the three big endian targets I know of
(MIPS MSA and ARM NEON) choose to use little endian element order even
when the elements are big endian which matches LLVM-IR's order. The third
is PowerPC Altivec which has the highest indexed element first for
big-endian mode.

I've attempted to implement the correct element ordering on the relevant
operations but I don't really have a means to test the case where the
element order doesn't match LLVM-IR's element order so I've chosen to have
a guard against element order mismatches to ensure that this change can't
break expression evaluation on those targets.

>From 3d736e3685776467dd03d53d0f2c6abb4252e062 Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/2] [lldb] Add some vector operations to the IRInterpreter

This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targets which are
not yet able to evaluate on the target.

As far as I know most targets have a vector memory layout that matches the
IR element order. Most little endian targets choose to use a little endian
element order, and two out of the three big endian targets I know of
(MIPS MSA and ARM NEON) choose to use little endian element order even
when the elements are big endian which matches LLVM-IR's order. The third
is PowerPC Altivec which has the highest indexed element first for
big-endian mode.

I've attempted to implement the correct element ordering on the relevant
operations but I don't really have a means to test the case where the
element order doesn't match LLVM-IR's element order so I've chosen to have
a guard against element order mismatches to ensure that this change can't
break expression evaluation on those targets.
---
 lldb/include/lldb/Core/Architecture.h |  11 +
 lldb/include/lldb/Expression/IRInterpreter.h  |   3 +-
 lldb/source/Expression/IRInterpreter.cpp  | 207 +-
 .../Architecture/PPC64/ArchitecturePPC64.cpp  |   7 +-
 .../Architecture/PPC64/ArchitecturePPC64.h|   6 +-
 .../Clang/ClangExpressionParser.cpp   |   2 +-
 .../vector-types/TestVectorTypesFormatting.py |  36 ++-
 7 files changed, 255 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Core/Architecture.h 
b/lldb/include/lldb/Core/Architecture.h
index b6fc1a20e1e69..435fe20121869 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -129,6 +129,17 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
 return false;
   }
+
+  // Get the vector element order for this architecture. This determines how
+  // vector elements are indexed. This matters in a few places such as reading/
+  // writing LLVM-IR values to/from target memory. Some architectures use
+  // little-endian element ordering where element 0 is at the lowest address
+  // even when the architecture is otherwise big-endian (e.g. MIPS MSA, ARM
+  // NEON), but some architectures like PowerPC may use big-endian element
+  // ordering where element 0 is at the highest address.
+  virtual lldb::ByteOrder GetVectorElementOrder() const {
+return lldb::eByteOrderLittle;
+  }
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Expression/IRInterpreter.h 
b/lldb/include/lldb/Expression/IRInterpreter.h
index 9106f1b4d1c3d..1c0f10aabed21 100644
--- a/lldb/include/lldb/Expression/IRInterpreter.h
+++ b/lldb/include/lldb/Expression/IRInterpreter.h
@@ -37,7 +37,8 @@ class IRInterpreter {
 public:
   static bool CanInterpret(llvm::Module &module, llvm::Function &function,
lldb_private::Status &error,
-   const bool support_function_calls);
+   const bool support_function_calls,
+   lldb_private::ExecutionContext &exe_ctx);
 
   static bool Interpret(llvm::Module &module, llvm::Function &function,
 llvm::ArrayRef args,
diff --git a/lldb/source/Expression/IRInterpreter.cpp 
b/lldb/source/Expression/IRInterpreter.cpp
index 91404831aeb9b..73e33ed27d8f1 100644
--- a/lldb/source/Expression/IRInterpreter.cpp
+++ b/lldb/source/Expression/IRInterpreter.cpp
@@ -70,6 +70,17 @@ static std::string PrintType(const Type *type, bool truncate 
= false) {
   return

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-08-22 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/155000

>From 3ac398b2fad8d30a23d196c15a9cb9f1bd43fdcb Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/4] [lldb] Add some vector operations to the IRInterpreter

This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targets which are
not yet able to evaluate on the target.

As far as I know most targets have a vector memory layout that matches the
IR element order. Most little endian targets choose to use a little endian
element order, and two out of the three big endian targets I know of
(MIPS MSA and ARM NEON) choose to use little endian element order even
when the elements are big endian which matches LLVM-IR's order. The third
is PowerPC Altivec which has the highest indexed element first for
big-endian mode.

I've attempted to implement the correct element ordering on the relevant
operations but I don't really have a means to test the case where the
element order doesn't match LLVM-IR's element order so I've chosen to have
a guard against element order mismatches to ensure that this change can't
break expression evaluation on those targets.
---
 lldb/include/lldb/Core/Architecture.h |  11 +
 lldb/include/lldb/Expression/IRInterpreter.h  |   3 +-
 lldb/source/Expression/IRInterpreter.cpp  | 209 +-
 .../Architecture/PPC64/ArchitecturePPC64.cpp  |   7 +-
 .../Architecture/PPC64/ArchitecturePPC64.h|   7 +-
 .../Clang/ClangExpressionParser.cpp   |   2 +-
 .../vector-types/TestVectorTypesFormatting.py |  39 +++-
 7 files changed, 261 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Core/Architecture.h 
b/lldb/include/lldb/Core/Architecture.h
index b6fc1a20e1e69..435fe20121869 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -129,6 +129,17 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
 return false;
   }
+
+  // Get the vector element order for this architecture. This determines how
+  // vector elements are indexed. This matters in a few places such as reading/
+  // writing LLVM-IR values to/from target memory. Some architectures use
+  // little-endian element ordering where element 0 is at the lowest address
+  // even when the architecture is otherwise big-endian (e.g. MIPS MSA, ARM
+  // NEON), but some architectures like PowerPC may use big-endian element
+  // ordering where element 0 is at the highest address.
+  virtual lldb::ByteOrder GetVectorElementOrder() const {
+return lldb::eByteOrderLittle;
+  }
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Expression/IRInterpreter.h 
b/lldb/include/lldb/Expression/IRInterpreter.h
index 9106f1b4d1c3d..1c0f10aabed21 100644
--- a/lldb/include/lldb/Expression/IRInterpreter.h
+++ b/lldb/include/lldb/Expression/IRInterpreter.h
@@ -37,7 +37,8 @@ class IRInterpreter {
 public:
   static bool CanInterpret(llvm::Module &module, llvm::Function &function,
lldb_private::Status &error,
-   const bool support_function_calls);
+   const bool support_function_calls,
+   lldb_private::ExecutionContext &exe_ctx);
 
   static bool Interpret(llvm::Module &module, llvm::Function &function,
 llvm::ArrayRef args,
diff --git a/lldb/source/Expression/IRInterpreter.cpp 
b/lldb/source/Expression/IRInterpreter.cpp
index 91404831aeb9b..261574321a74e 100644
--- a/lldb/source/Expression/IRInterpreter.cpp
+++ b/lldb/source/Expression/IRInterpreter.cpp
@@ -70,6 +70,18 @@ static std::string PrintType(const Type *type, bool truncate 
= false) {
   return s;
 }
 
+static bool
+MemoryMatchesIRElementOrder(lldb_private::ExecutionContext &exe_ctx) {
+  lldb::TargetSP target_sp = exe_ctx.GetTargetSP();
+  if (target_sp) {
+const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+if (arch_plugin) {
+  return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+}
+  }
+  return true; // Default to little-endian (matches IR)
+}
+
 static bool CanIgnoreCall(const CallInst *call) {
   const llvm::Function *called_function = call->getCalledFunction();
 
@@ -124,6 +136,17 @@ class InterpreterStackFrame {
 
   ~InterpreterStackFrame() = default;
 
+  bool MemoryMatchesIRElementOrder() {
+lldb::TargetSP target_sp = m_execution_unit.GetTarget();
+if (target_sp) {
+  const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+  if (arch_plugin) {
+return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+  }
+}
+return true;
+  }
+
   void Jump(const BasicBlock *bb) {
 m_prev_bb = m_bb;
 m_bb = bb;
@@ -36

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-08-22 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/155000

>From 3ac398b2fad8d30a23d196c15a9cb9f1bd43fdcb Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/3] [lldb] Add some vector operations to the IRInterpreter

This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targets which are
not yet able to evaluate on the target.

As far as I know most targets have a vector memory layout that matches the
IR element order. Most little endian targets choose to use a little endian
element order, and two out of the three big endian targets I know of
(MIPS MSA and ARM NEON) choose to use little endian element order even
when the elements are big endian which matches LLVM-IR's order. The third
is PowerPC Altivec which has the highest indexed element first for
big-endian mode.

I've attempted to implement the correct element ordering on the relevant
operations but I don't really have a means to test the case where the
element order doesn't match LLVM-IR's element order so I've chosen to have
a guard against element order mismatches to ensure that this change can't
break expression evaluation on those targets.
---
 lldb/include/lldb/Core/Architecture.h |  11 +
 lldb/include/lldb/Expression/IRInterpreter.h  |   3 +-
 lldb/source/Expression/IRInterpreter.cpp  | 209 +-
 .../Architecture/PPC64/ArchitecturePPC64.cpp  |   7 +-
 .../Architecture/PPC64/ArchitecturePPC64.h|   7 +-
 .../Clang/ClangExpressionParser.cpp   |   2 +-
 .../vector-types/TestVectorTypesFormatting.py |  39 +++-
 7 files changed, 261 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Core/Architecture.h 
b/lldb/include/lldb/Core/Architecture.h
index b6fc1a20e1e69..435fe20121869 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -129,6 +129,17 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
 return false;
   }
+
+  // Get the vector element order for this architecture. This determines how
+  // vector elements are indexed. This matters in a few places such as reading/
+  // writing LLVM-IR values to/from target memory. Some architectures use
+  // little-endian element ordering where element 0 is at the lowest address
+  // even when the architecture is otherwise big-endian (e.g. MIPS MSA, ARM
+  // NEON), but some architectures like PowerPC may use big-endian element
+  // ordering where element 0 is at the highest address.
+  virtual lldb::ByteOrder GetVectorElementOrder() const {
+return lldb::eByteOrderLittle;
+  }
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Expression/IRInterpreter.h 
b/lldb/include/lldb/Expression/IRInterpreter.h
index 9106f1b4d1c3d..1c0f10aabed21 100644
--- a/lldb/include/lldb/Expression/IRInterpreter.h
+++ b/lldb/include/lldb/Expression/IRInterpreter.h
@@ -37,7 +37,8 @@ class IRInterpreter {
 public:
   static bool CanInterpret(llvm::Module &module, llvm::Function &function,
lldb_private::Status &error,
-   const bool support_function_calls);
+   const bool support_function_calls,
+   lldb_private::ExecutionContext &exe_ctx);
 
   static bool Interpret(llvm::Module &module, llvm::Function &function,
 llvm::ArrayRef args,
diff --git a/lldb/source/Expression/IRInterpreter.cpp 
b/lldb/source/Expression/IRInterpreter.cpp
index 91404831aeb9b..261574321a74e 100644
--- a/lldb/source/Expression/IRInterpreter.cpp
+++ b/lldb/source/Expression/IRInterpreter.cpp
@@ -70,6 +70,18 @@ static std::string PrintType(const Type *type, bool truncate 
= false) {
   return s;
 }
 
+static bool
+MemoryMatchesIRElementOrder(lldb_private::ExecutionContext &exe_ctx) {
+  lldb::TargetSP target_sp = exe_ctx.GetTargetSP();
+  if (target_sp) {
+const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+if (arch_plugin) {
+  return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+}
+  }
+  return true; // Default to little-endian (matches IR)
+}
+
 static bool CanIgnoreCall(const CallInst *call) {
   const llvm::Function *called_function = call->getCalledFunction();
 
@@ -124,6 +136,17 @@ class InterpreterStackFrame {
 
   ~InterpreterStackFrame() = default;
 
+  bool MemoryMatchesIRElementOrder() {
+lldb::TargetSP target_sp = m_execution_unit.GetTarget();
+if (target_sp) {
+  const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+  if (arch_plugin) {
+return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+  }
+}
+return true;
+  }
+
   void Jump(const BasicBlock *bb) {
 m_prev_bb = m_bb;
 m_bb = bb;
@@ -36

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-09-05 Thread Daniel Sanders via lldb-commits 


@@ -644,7 +723,25 @@ bool IRInterpreter::CanInterpret(llvm::Module &module, 
llvm::Function &function,
 switch (operand_type->getTypeID()) {
 default:
   break;
-case Type::FixedVectorTyID:
+case Type::FixedVectorTyID: {

dsandersllvm wrote:

I didn't check bitcast because it didn't come up in the expressions I was 
adding. I'll check it has appropriate guards. That should be the only one 
that's a bit weird (it's only an issue for big-endian ARM and MIPS). For the 
other instructions I was mostly leaning on the test suite showing issues if I 
broke something. I can have a look through them

https://github.com/llvm/llvm-project/pull/155000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-09-05 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

> For testing the endianess, I'm not sure we have PPC LLDB buildbots that would 
> test this (@DavidSpickett or @JDevlieghere might know). Any chance this can 
> be tested with unit-tests somehow? Maybe we can just pass an LLVM IR module 
> into the IRInterpreter? We could potentially build something into `lldb-test` 
> even. If that's too much hassle we can also just do that as a follow-up

I'm not sure we can. The problem arises from transferring LLVM-IR values 
to/from the targets memory. If we don't have the target consuming/producing 
that memory then our test could just be consistently-wrong and pass anyway.

https://github.com/llvm/llvm-project/pull/155000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-09-07 Thread Daniel Sanders via lldb-commits 


@@ -30,9 +30,14 @@ class ArchitecturePPC64 : public Architecture {
   void AdjustBreakpointAddress(const Symbol &func,
Address &addr) const override;
 
+  lldb::ByteOrder GetVectorElementOrder() const override;
+
 private:
   static std::unique_ptr Create(const ArchSpec &arch);
-  ArchitecturePPC64() = default;
+  ArchitecturePPC64(lldb::ByteOrder vector_element_order)

dsandersllvm wrote:

It's not the only big-endian target but it is the only target I know of where 
the order of vector elements doesn't match LLVM-IR's order. MIPS  and ARM both 
have big-endian modes but vectors are 0-element first in both endians whereas 
big-endian PowerPC is highest-indexed element first. If I hadn't handled this 
then we'd read/write their vectors in reversed element order every time we 
tried to copy memory to/from an LLVM-IR value.

MIPS and ARM's vector layout has a different quirk on LLVM-IR/memory which is 
that bitcast isn't a no-op, it's a shuffle (which bytes swaps depends on the 
types involved). This is because it's defined as a store of the original type 
followed by a load of the new type. I haven't implemented this yet because I 
didn't need to support vector bitcast.

https://github.com/llvm/llvm-project/pull/155000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add some vector operations to the IRInterpreter (PR #155000)

2025-09-03 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm updated 
https://github.com/llvm/llvm-project/pull/155000

>From be4ddf49a230b32699df153ecc3b2b3ee62c1c22 Mon Sep 17 00:00:00 2001
From: Daniel Sanders 
Date: Fri, 22 Aug 2025 10:54:52 -0700
Subject: [PATCH 1/7] [lldb] Add some vector operations to the IRInterpreter

This allows the debugger to evaluate expressions without requiring the
expression to be CodeGen'd and executed on the target. This should be more
efficient for many existing targets but is necessary for targets which are
not yet able to evaluate on the target.

As far as I know most targets have a vector memory layout that matches the
IR element order. Most little endian targets choose to use a little endian
element order, and two out of the three big endian targets I know of
(MIPS MSA and ARM NEON) choose to use little endian element order even
when the elements are big endian which matches LLVM-IR's order. The third
is PowerPC Altivec which has the highest indexed element first for
big-endian mode.

I've attempted to implement the correct element ordering on the relevant
operations but I don't really have a means to test the case where the
element order doesn't match LLVM-IR's element order so I've chosen to have
a guard against element order mismatches to ensure that this change can't
break expression evaluation on those targets.
---
 lldb/include/lldb/Core/Architecture.h |  11 +
 lldb/include/lldb/Expression/IRInterpreter.h  |   3 +-
 lldb/source/Expression/IRInterpreter.cpp  | 209 +-
 .../Architecture/PPC64/ArchitecturePPC64.cpp  |   7 +-
 .../Architecture/PPC64/ArchitecturePPC64.h|   7 +-
 .../Clang/ClangExpressionParser.cpp   |   2 +-
 .../vector-types/TestVectorTypesFormatting.py |  39 +++-
 7 files changed, 261 insertions(+), 17 deletions(-)

diff --git a/lldb/include/lldb/Core/Architecture.h 
b/lldb/include/lldb/Core/Architecture.h
index b6fc1a20e1e69..435fe20121869 100644
--- a/lldb/include/lldb/Core/Architecture.h
+++ b/lldb/include/lldb/Core/Architecture.h
@@ -129,6 +129,17 @@ class Architecture : public PluginInterface {
RegisterContext ®_context) const {
 return false;
   }
+
+  // Get the vector element order for this architecture. This determines how
+  // vector elements are indexed. This matters in a few places such as reading/
+  // writing LLVM-IR values to/from target memory. Some architectures use
+  // little-endian element ordering where element 0 is at the lowest address
+  // even when the architecture is otherwise big-endian (e.g. MIPS MSA, ARM
+  // NEON), but some architectures like PowerPC may use big-endian element
+  // ordering where element 0 is at the highest address.
+  virtual lldb::ByteOrder GetVectorElementOrder() const {
+return lldb::eByteOrderLittle;
+  }
 };
 
 } // namespace lldb_private
diff --git a/lldb/include/lldb/Expression/IRInterpreter.h 
b/lldb/include/lldb/Expression/IRInterpreter.h
index 9106f1b4d1c3d..1c0f10aabed21 100644
--- a/lldb/include/lldb/Expression/IRInterpreter.h
+++ b/lldb/include/lldb/Expression/IRInterpreter.h
@@ -37,7 +37,8 @@ class IRInterpreter {
 public:
   static bool CanInterpret(llvm::Module &module, llvm::Function &function,
lldb_private::Status &error,
-   const bool support_function_calls);
+   const bool support_function_calls,
+   lldb_private::ExecutionContext &exe_ctx);
 
   static bool Interpret(llvm::Module &module, llvm::Function &function,
 llvm::ArrayRef args,
diff --git a/lldb/source/Expression/IRInterpreter.cpp 
b/lldb/source/Expression/IRInterpreter.cpp
index 91404831aeb9b..261574321a74e 100644
--- a/lldb/source/Expression/IRInterpreter.cpp
+++ b/lldb/source/Expression/IRInterpreter.cpp
@@ -70,6 +70,18 @@ static std::string PrintType(const Type *type, bool truncate 
= false) {
   return s;
 }
 
+static bool
+MemoryMatchesIRElementOrder(lldb_private::ExecutionContext &exe_ctx) {
+  lldb::TargetSP target_sp = exe_ctx.GetTargetSP();
+  if (target_sp) {
+const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+if (arch_plugin) {
+  return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+}
+  }
+  return true; // Default to little-endian (matches IR)
+}
+
 static bool CanIgnoreCall(const CallInst *call) {
   const llvm::Function *called_function = call->getCalledFunction();
 
@@ -124,6 +136,17 @@ class InterpreterStackFrame {
 
   ~InterpreterStackFrame() = default;
 
+  bool MemoryMatchesIRElementOrder() {
+lldb::TargetSP target_sp = m_execution_unit.GetTarget();
+if (target_sp) {
+  const auto *arch_plugin = target_sp->GetArchitecturePlugin();
+  if (arch_plugin) {
+return arch_plugin->GetVectorElementOrder() == lldb::eByteOrderLittle;
+  }
+}
+return true;
+  }
+
   void Jump(const BasicBlock *bb) {
 m_prev_bb = m_bb;
 m_bb = bb;
@@ -36

[Lldb-commits] [lldb] [lldb] Fix assertion when opcodes are exactly the length of the buffer (PR #157196)

2025-09-08 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm closed 
https://github.com/llvm/llvm-project/pull/157196
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][NFC] Architecture plugins should report the vector element order (PR #157198)

2025-09-08 Thread Daniel Sanders via lldb-commits 

https://github.com/dsandersllvm edited 
https://github.com/llvm/llvm-project/pull/157198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][NFC] Architecture plugins should report the vector element order (PR #157198)

2025-09-08 Thread Daniel Sanders via lldb-commits 

dsandersllvm wrote:

> > Some targets like PowerPC store their
> 
> Is there some text missing here?

Oops, fixed it.

> Do we know what vector extension s390x/SystemZ has and what order it uses?

I don't know but I've found 
https://github.com/bytecodealliance/wasmtime/issues/4566 so @uweigand might be 
able to confirm. The first section seems to be describing the ARM/MIPS 
behaviour where the element order in the ISA remains the same regardless of the 
endianness of the elements themselves . I don't see any of the required 
shuffling bitcasts in lib/Target/SystemZ for that behaviour though. That thread 
goes on to mention implementing all four combinations so it might be 
configurable

https://github.com/llvm/llvm-project/pull/157198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits