date:20240920

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Assert correct values in APInt constructor (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits


https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/80309

>From 7467ecf67c706ffdfa79eaebdc9528002b74c5af Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Thu, 19 Sep 2024 17:27:13 +0200
Subject: [PATCH] apint only

---
 clang/lib/AST/ByteCode/IntegralAP.h   |  6 ++--
 clang/lib/CodeGen/CGVTT.cpp   |  5 +--
 clang/lib/CodeGen/ItaniumCXXABI.cpp   |  5 +--
 clang/lib/Parse/ParseInit.cpp |  4 ++-
 clang/lib/Sema/SemaExpr.cpp   |  7 ++--
 clang/lib/Sema/SemaOpenMP.cpp |  4 ++-
 lldb/source/Expression/DWARFExpression.cpp|  7 ++--
 llvm/include/llvm/ADT/APFixedPoint.h  |  4 ++-
 llvm/lib/Analysis/ConstantFolding.cpp |  3 +-
 llvm/lib/Analysis/Loads.cpp   |  6 ++--
 llvm/lib/Analysis/MemoryBuiltins.cpp  |  2 ++
 llvm/lib/Analysis/ScalarEvolution.cpp |  2 +-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp |  3 +-
 .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp |  5 ++-
 .../SelectionDAG/SelectionDAGBuilder.cpp  |  3 +-
 .../CodeGen/SelectionDAG/SelectionDAGISel.cpp |  8 +++--
 .../CodeGen/SelectionDAG/TargetLowering.cpp   |  8 +++--
 llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp  |  2 +-
 llvm/lib/IR/Constants.cpp |  4 ++-
 .../Target/AArch64/AArch64ISelLowering.cpp| 32 +--
 llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp |  2 +-
 .../AMDGPU/AMDGPUInstructionSelector.cpp  |  2 +-
 .../Disassembler/AMDGPUDisassembler.cpp   |  2 +-
 .../MCTargetDesc/AMDGPUMCTargetDesc.cpp   |  2 +-
 llvm/lib/Target/AMDGPU/SIInstrInfo.cpp| 17 +++---
 .../Target/AMDGPU/SIShrinkInstructions.cpp|  4 +--
 .../lib/Target/ARM/AsmParser/ARMAsmParser.cpp |  4 ++-
 .../Hexagon/HexagonConstPropagation.cpp   |  3 +-
 llvm/lib/Target/Hexagon/HexagonGenExtract.cpp |  2 +-
 llvm/lib/Target/RISCV/RISCVISelLowering.cpp   |  4 ++-
 llvm/lib/Target/X86/X86ISelLowering.cpp   |  6 ++--
 llvm/lib/Transforms/IPO/ArgumentPromotion.cpp |  3 +-
 llvm/lib/Transforms/Utils/SimplifyCFG.cpp |  2 +-
 llvm/unittests/ADT/APFixedPointTest.cpp   |  9 +++---
 mlir/include/mlir/IR/BuiltinAttributes.td |  4 ++-
 mlir/include/mlir/IR/OpImplementation.h   |  3 +-
 .../Conversion/TosaToArith/TosaToArith.cpp|  2 +-
 .../Dialect/ControlFlow/IR/ControlFlowOps.cpp |  2 +-
 mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp|  2 +-
 mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp  |  2 +-
 mlir/lib/IR/Builders.cpp  | 16 +++---
 .../SPIRV/Deserialization/Deserializer.cpp|  6 ++--
 .../Dialect/SPIRV/SerializationTest.cpp   |  2 +-
 43 files changed, 139 insertions(+), 82 deletions(-)

diff --git a/clang/lib/AST/ByteCode/IntegralAP.h 
b/clang/lib/AST/ByteCode/IntegralAP.h
index a4d656433344b7..6ab3d09ec85d5b 100644
--- a/clang/lib/AST/ByteCode/IntegralAP.h
+++ b/clang/lib/AST/ByteCode/IntegralAP.h
@@ -61,7 +61,7 @@ template  class IntegralAP final {
 
   IntegralAP(APInt V) : V(V) {}
   /// Arbitrary value for uninitialized variables.
-  IntegralAP() : IntegralAP(-1, 3) {}
+  IntegralAP() : IntegralAP(Signed ? -1 : 7, 3) {}
 
   IntegralAP operator-() const { return IntegralAP(-V); }
   IntegralAP operator-(const IntegralAP &Other) const {
@@ -112,7 +112,9 @@ template  class IntegralAP final {
 
   template 
   static IntegralAP from(Integral I, unsigned BitWidth) {
-APInt Copy = APInt(BitWidth, static_cast(I), InputSigned);
+// TODO: Avoid implicit trunc?
+APInt Copy = APInt(BitWidth, static_cast(I), InputSigned,
+   /*implicitTrunc=*/true);
 
 return IntegralAP(Copy);
   }
diff --git a/clang/lib/CodeGen/CGVTT.cpp b/clang/lib/CodeGen/CGVTT.cpp
index 20bd2c2fc2c642..989a07d09d50ee 100644
--- a/clang/lib/CodeGen/CGVTT.cpp
+++ b/clang/lib/CodeGen/CGVTT.cpp
@@ -85,8 +85,9 @@ CodeGenVTables::EmitVTTDefinition(llvm::GlobalVariable *VTT,
  cast(VTable->getValueType())
  ->getElementType(AddressPoint.VTableIndex));
  unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
- llvm::ConstantRange InRange(llvm::APInt(32, -Offset, true),
- llvm::APInt(32, VTableSize - Offset, true));
+ llvm::ConstantRange InRange(
+ llvm::APInt(32, (int)-Offset, true),
+ llvm::APInt(32, (int)(VTableSize - Offset), true));
  llvm::Constant *Init = llvm::ConstantExpr::getGetElementPtr(
  VTable->getValueType(), VTable, Idxs, /*InBounds=*/true, InRange);
 
diff --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index dcc35d5689831e..ff018fa22db866 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2099,8 +2099,9 @@ ItaniumCXXABI::getVTableAddressPoint(BaseSubobject Base,
   unsigned VTableSize =
   ComponentSize * Layout.getVTableSize(AddressPoint.VTableIndex);
   unsigned Offset = ComponentSize * AddressPoint.AddressPointInde

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fix bitwidth (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits


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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits


nikic wrote:

I think this is ready for review now. I've landed many parts of this PR 
separately already, and am happy to land this in parts (or split as needed).

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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Matt Arsenault via lldb-commits



@@ -4377,7 +4377,7 @@ 
AMDGPUInstructionSelector::selectGlobalSAddr(MachineOperand &Root) const {
 // instructions to perform VALU adds with immediates or inline 
literals.
 unsigned NumLiterals =
 !TII.isInlineConstant(APInt(32, ConstOffset & 0x)) +
-!TII.isInlineConstant(APInt(32, ConstOffset >> 32));
+!TII.isInlineConstant(APInt(32, uint64_t(ConstOffset) >> 32));

arsenm wrote:

These should probably just use Lo_32/Hi_32

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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Matt Arsenault via lldb-commits



@@ -1806,7 +1806,7 @@ bool AMDGPUDAGToDAGISel::SelectGlobalSAddr(SDNode *N,
   // instructions to perform VALU adds with immediates or inline literals.
   unsigned NumLiterals =
   !TII->isInlineConstant(APInt(32, COffsetVal & 0x)) +
-  !TII->isInlineConstant(APInt(32, COffsetVal >> 32));
+  !TII->isInlineConstant(APInt(32, uint64_t(COffsetVal) >> 32));

arsenm wrote:

These should probably just use Lo_32/Hi_32 

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

[Lldb-commits] [lldb] [lldb] gdb rsp file error pass fix (PR #106950)

2024-09-20 Thread via lldb-commits


github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 0f97b4824a8cf040bd3ce7b644dee9d60065ac61 
5588503e8b8f225d142681cdf21a2b7f8fc0a734 --extensions cpp -- 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
``





View the diff from clang-format here.


``diff
diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
index f425c4647b..f1450f6d10 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -497,14 +497,14 @@ GDBRemoteCommunicationServerCommon::Handle_qSpeedTest(
 }
 
 static GDBErrno system_errno_to_gdb(int err) {
-switch (err) {
+  switch (err) {
 #define HANDLE_ERRNO(name, value)  
\
-case name:   \
-  return GDB_##name;
+  case name:   
\
+return GDB_##name;
 #include "Plugins/Process/gdb-remote/GDBRemoteErrno.def"
-default:
-  return GDB_EUNKNOWN;
-}
+  default:
+return GDB_EUNKNOWN;
+  }
 }
 
 GDBRemoteCommunication::PacketResult

``




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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett approved this pull request.

Looks good to me.

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

[Lldb-commits] [lldb] [lldb] fix vFile:open, vFile:unlink error codes (PR #106950)

2024-09-20 Thread via lldb-commits


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

[Lldb-commits] [lldb] [lldb] fix vFile:open, vFile:unlink error codes (PR #106950)

2024-09-20 Thread via lldb-commits


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

[Lldb-commits] [lldb] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)

2024-09-20 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu` 
running on `linaro-lldb-aarch64-ubuntu` while building `lldb` at step 6 "test".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/59/builds/5268


Here is the relevant piece of the build log for the reference

```
Step 6 (test) failure: build (failure)
...
58.520 [121/9/130] Building CXX object 
tools/lldb/unittests/Process/Linux/CMakeFiles/ProcessLinuxTests.dir/ProcfsTests.cpp.o
59.534 [121/8/131] Building CXX object 
tools/lldb/unittests/Process/Utility/CMakeFiles/ProcessUtilityTests.dir/LinuxProcMapsTest.cpp.o
59.609 [121/7/132] Building CXX object 
tools/lldb/unittests/Process/Utility/CMakeFiles/ProcessUtilityTests.dir/CoreFileMemoryRangesTest.cpp.o
60.013 [117/10/133] Linking CXX executable 
tools/lldb/unittests/Process/Linux/ProcessLinuxTests
60.061 [116/10/134] Building CXX object 
tools/lldb/unittests/Process/gdb-remote/CMakeFiles/ProcessGdbRemoteTests.dir/PortMapTest.cpp.o
60.781 [116/9/135] Building CXX object 
tools/lldb/unittests/Process/minidump/CMakeFiles/LLDBMinidumpTests.dir/RegisterContextMinidumpTest.cpp.o
60.884 [116/8/136] Building CXX object 
tools/lldb/unittests/Process/Utility/CMakeFiles/ProcessUtilityTests.dir/MemoryTagManagerAArch64MTETest.cpp.o
61.133 [113/10/137] Linking CXX executable 
tools/lldb/unittests/Process/Utility/ProcessUtilityTests
61.625 [112/10/138] Linking CXX executable 
tools/lldb/unittests/Process/gdb-remote/ProcessGdbRemoteTests
61.682 [112/9/139] Building CXX object 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
FAILED: 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 
/usr/local/bin/c++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLLVM_BUILD_STATIC -D_DEBUG 
-D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/unittests/ScriptInterpreter/Python
 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/unittests/ScriptInterpreter/Python
 -I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/include 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/include 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/llvm/include 
-I/usr/include/python3.10 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/llvm/../clang/include
 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb/../clang/include
 -I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/source 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/unittests 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/third-party/unittest/googletest/include
 
-I/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/third-party/unittest/googlemock/include
 -isystem /usr/include/libxml2 -fPIC -fno-semantic-interposition 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
-Wno-vla-extension -O3 -DNDEBUG -std=c++17  -Wno-variadic-macros 
-Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -funwind-tables 
-fno-rtti -UNDEBUG -Wno-suggest-override -MD -MT 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 -MF 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o.d
 -o 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 -c 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
../llvm-project/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp:277:35:
 error: out-of-line definition of 'ToSWIGWrapper' does not match any 
declaration in 'lldb_private::python::SWIGBridge'
  277 | lldb_private::python::SWIGBridge::ToSWIGWrapper(const Status &status) {
  |   ^
../llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h:89:37:
 note: type of 1st parameter of member declaration does not match definition 
('Status' vs 'const Status &')
   89 |   static PythonObject ToSWIGWrapper(Status status);
  | ^
1 error gener

[Lldb-commits] [lldb] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)

2024-09-20 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-arm-ubuntu` running 
on `linaro-lldb-arm-ubuntu` while building `lldb` at step 6 "test".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/18/builds/4137


Here is the relevant piece of the build log for the reference

```
Step 6 (test) failure: build (failure)
...
5.951 [175/62/23] Building CXX object 
tools/lldb/unittests/Editline/CMakeFiles/EditlineTests.dir/EditlineTest.cpp.o
6.092 [175/61/24] Building CXX object 
tools/lldb/unittests/Core/CMakeFiles/LLDBCoreTests.dir/DumpRegisterInfoTest.cpp.o
6.102 [172/63/25] Linking CXX executable 
tools/lldb/unittests/Breakpoint/LLDBBreakpointTests
6.268 [169/65/26] Linking CXX executable 
tools/lldb/unittests/Editline/EditlineTests
6.430 [166/67/27] Building CXX object 
tools/lldb/unittests/Host/CMakeFiles/HostTests.dir/FileTest.cpp.o
6.439 [160/72/28] Building CXX object 
tools/lldb/unittests/Core/CMakeFiles/LLDBCoreTests.dir/FormatEntityTest.cpp.o
6.534 [160/71/29] Building CXX object 
tools/lldb/unittests/DataFormatter/CMakeFiles/LLDBFormatterTests.dir/StringPrinterTests.cpp.o
6.612 [160/70/30] Building CXX object 
tools/lldb/unittests/Core/CMakeFiles/LLDBCoreTests.dir/SourceLocationSpecTest.cpp.o
6.718 [160/69/31] Building CXX object 
tools/lldb/unittests/Expression/CMakeFiles/ExpressionTests.dir/DiagnosticManagerTest.cpp.o
7.063 [157/71/32] Building CXX object 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
FAILED: 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 
/usr/local/bin/c++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLLVM_BUILD_STATIC -D_DEBUG 
-D_FILE_OFFSET_BITS=64 -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D_LARGEFILE_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb/unittests/ScriptInterpreter/Python
 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/unittests/ScriptInterpreter/Python
 -I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/include 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb/include 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/include 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/llvm/include 
-I/usr/include/python3.10 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/llvm/../clang/include 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/tools/lldb/../clang/include 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/source 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/unittests 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/third-party/unittest/googletest/include
 
-I/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/third-party/unittest/googlemock/include
 -isystem /usr/include/libxml2 -fPIC -fno-semantic-interposition 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections -Wno-deprecated-declarations 
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register 
-Wno-vla-extension -O3 -DNDEBUG -std=c++17  -Wno-variadic-macros 
-Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -funwind-tables 
-fno-rtti -UNDEBUG -Wno-suggest-override -MD -MT 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 -MF 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o.d
 -o 
tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o
 -c 
/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
../llvm-project/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp:277:35:
 error: out-of-line definition of 'ToSWIGWrapper' does not match any 
declaration in 'lldb_private::python::SWIGBridge'
  277 | lldb_private::python::SWIGBridge::ToSWIGWrapper(const Status &status) {
  |   ^
../llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h:89:37:
 note: type of 1st parameter of member declaration does not match definition 
('Status' vs 'const Status &')
   89 |   static PythonObject ToSWIGWrapper(Status status);
  | ^
1 error generated.
7.584 [157/70/33] Building CXX object 
tools/lldb/unittests/Core/CMakeFiles/LLDBCoreTests.dir/DumpDataExtractorTest.cpp.o
7.77

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Pavel Labath via lldb-commits



@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
   m_fallback.GetFullyQualifiedType(context, callback);
 }
 
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+  auto maybe_dieoffset = entry.getDIEUnitOffset();
+  if (!maybe_dieoffset)
+return false;
+
+  // [Optimization] instead of parsing the entry from dwo file, we simply
+  // check if the query_name can point to an entry of the same DIE offset.
+  // This greatly reduced number of dwo file parsed and thus improved the
+  // performance.
+  for (const DebugNames::Entry &query_entry :
+   entry.getNameIndex()->equal_range(query_name)) {
+auto query_dieoffset = query_entry.getDIEUnitOffset();
+if (!query_dieoffset)
+  continue;
+
+if (*query_dieoffset == *maybe_dieoffset) {
+  return true;
+} else if (*query_dieoffset > *maybe_dieoffset) {
+  // The pool entries of the same name are sequentially cluttered together
+  // so if the query name from `query_name` is after the target entry, this
+  // is definitely not the correct one, we can stop searching.

labath wrote:

I think you're reading too much into the specification. That's definitely not 
how I would interpret those sections.

The whole of page 141 is devoted to describing the physical layout of the 
debug_names section, and that's the context in which I'd read that sentence. It 
just says that entries in the entry pool should follow one after the other -- 
i.e., with no intervening padding. It doesn't say anything about the debug info 
entries (in the debug_info) section which are referred to by the debug_names 
entries. In fact, at this point in the spec, it hasn't even been established 
how the index entries refer to DIEs -- that happens six pages later (somewhere 
around your second quote).

However, the second quote basically restates the same thing. There can be no 
gaps between entries for the same name (which makes sense, as you couldn't 
parse them otherwise -- you reach the next one by passing over the first one), 
but there *can* be gaps between different names (and that also makes sense -- 
you reach the first entry by following the pointer from the name table, so it 
does not have to be glued to the previous list).

The non-normative text after it confirms this theory:
```
For example, a producer/consumer combination may find it useful to maintain 
alignment.
```

The padding is there to (optionally) maintain alignment of the entries *in the 
debug_names section.* You can't maintain alignment by sorting entries.

In addition, this sorting of entries by die offset is very arbitrary and a 
remnant (introduced by me) from the apple tables. Since the DIE offset is 
relative to the CU start, it means that entries from different CUs would be 
interleaved just because they have interleaving relative offsets.

Bottom line: I'm certain that if the DWARF spec wanted to guarantee this 
sorting, it would use a much more obvious language, and I suspect that it would 
choose a different sorting key (e.g. group all entries from the same CU and 
*then* sort by offset).

I think this part of the patch should be split off to a separate PR.

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread Abhina Sree via lldb-commits



@@ -323,10 +325,11 @@ ErrorOr RealFileSystem::status(const Twine &Path) 
{
 }
 
 ErrorOr>
-RealFileSystem::openFileForRead(const Twine &Name) {
+RealFileSystem::openFileForRead(const Twine &Name, bool IsText) {
   SmallString<256> RealName, Storage;
   Expected FDOrErr = sys::fs::openNativeFileForRead(
-  adjustPath(Name, Storage), sys::fs::OF_None, &RealName);
+  adjustPath(Name, Storage), IsText ? sys::fs::OF_Text : sys::fs::OF_None,

abhina-sree wrote:

I will look into this and see if I hit any issues. I think if the file already 
exists, we can deduce it here, but in the case the file does not exist, we do 
not know whether the file is supposed to be text or binary without additional 
context

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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Pavel Labath via lldb-commits

labath wrote:

> Is it worth splitting this into two PRs (one for the type lookup and one for 
> namespaces)?

Maybe, but I think it may even be better to split it along the 
optimization-type axis (the die offset thingy vs. the parent chain).

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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Pavel Labath via lldb-commits


labath wrote:

> > I'm also not sure where's the " NameEntry> mapping 
> > table" you mention in the description. Could you point me to it?
> 
> @labath, that is the first prototype I tried, but benchmark shows it did not 
> improve any performance because the time to build this mapping offsets any 
> query gain later so this PR did not use it and uses the second idea by 
> searching parent entry's matching names which is implemented in this PR.

Okay, that explains why I couldn't find it, but then I guess the patch 
description is out of date, as it still contains this:

> The new implementation minimizes the need to touch DWO files by employing two 
> strategies:
> -Build a  NameEntry> mapping table (built lazily as 
> needed), allowing us to check the name of the parent entry.

Can you update it to reflect the current state of the patch (you may choose to 
keep this in some "alternatives considered" section, but I wouldn't say that's 
necessary)?

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

[Lldb-commits] [lldb] [lldb/Interpreter] Introduce `ScriptedStopHook{, Python}Interface` & make use of it (PR #105449)

2024-09-20 Thread David Spickett via lldb-commits



@@ -269,21 +274,7 @@ void 
*lldb_private::python::SWIGBridge::LLDBSWIGPython_GetDynamicSetting(
 }
 
 python::PythonObject
-lldb_private::python::SWIGBridge::LLDBSwigPythonCreateScriptedStopHook(
-lldb::TargetSP target_sp, const char *python_class_name,
-const char *session_dictionary_name, const StructuredDataImpl &args_impl,
-Status &error) {
-  return python::PythonObject();
-}
-
-bool lldb_private::python::SWIGBridge::LLDBSwigPythonStopHookCallHandleStop(
-void *implementor, lldb::ExecutionContextRefSP exc_ctx_sp,
-lldb::StreamSP stream) {
-  return false;
-}
-
-python::PythonObject
-lldb_private::python::SWIGBridge::ToSWIGWrapper(Status status) {

DavidSpickett wrote:

FYI 
https://github.com/llvm/llvm-project/commit/76b827bb4d5b4cc4d3229c4c6de2529e8b156810

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

[Lldb-commits] [lldb] 76b827b - [lldb] Fix SWIG wrapper compilation error

2024-09-20 Thread David Spickett via lldb-commits


Author: David Spickett
Date: 2024-09-20T09:41:07Z
New Revision: 76b827bb4d5b4cc4d3229c4c6de2529e8b156810

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

LOG: [lldb] Fix SWIG wrapper compilation error

Introduced by 1e131ddfa8f1d7b18c85c6e4079458be8b419421.

https://lab.llvm.org/buildbot/#/builders/59/builds/5272

Added: 


Modified: 
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Removed: 




diff  --git a/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp 
b/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
index ef9df053323aa5..a9e908ec4792c5 100644
--- a/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ b/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -274,7 +274,7 @@ void 
*lldb_private::python::SWIGBridge::LLDBSWIGPython_GetDynamicSetting(
 }
 
 python::PythonObject
-lldb_private::python::SWIGBridge::ToSWIGWrapper(const Status &status) {
+lldb_private::python::SWIGBridge::ToSWIGWrapper(Status status) {
   return python::PythonObject();
 }
 



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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits


https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/80309

>From 511445e35376c904be454ed987786cb6faa70a81 Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Thu, 19 Sep 2024 17:27:13 +0200
Subject: [PATCH] apint only

---
 clang/lib/AST/ByteCode/IntegralAP.h   |  6 ++--
 clang/lib/CodeGen/CGVTT.cpp   |  5 +--
 clang/lib/CodeGen/ItaniumCXXABI.cpp   |  5 +--
 clang/lib/Parse/ParseInit.cpp |  4 ++-
 clang/lib/Sema/SemaExpr.cpp   |  7 ++--
 clang/lib/Sema/SemaOpenMP.cpp |  4 ++-
 lldb/source/Expression/DWARFExpression.cpp|  7 ++--
 llvm/include/llvm/ADT/APFixedPoint.h  |  4 ++-
 llvm/lib/Analysis/ConstantFolding.cpp |  3 +-
 llvm/lib/Analysis/Loads.cpp   |  6 ++--
 llvm/lib/Analysis/MemoryBuiltins.cpp  |  2 ++
 llvm/lib/Analysis/ScalarEvolution.cpp |  2 +-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp |  3 +-
 .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp |  5 ++-
 .../SelectionDAG/SelectionDAGBuilder.cpp  |  3 +-
 .../CodeGen/SelectionDAG/SelectionDAGISel.cpp |  8 +++--
 .../CodeGen/SelectionDAG/TargetLowering.cpp   |  8 +++--
 llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp  |  2 +-
 llvm/lib/IR/Constants.cpp |  4 ++-
 .../Target/AArch64/AArch64ISelLowering.cpp| 32 +--
 .../Disassembler/AMDGPUDisassembler.cpp   |  2 +-
 .../MCTargetDesc/AMDGPUMCTargetDesc.cpp   |  2 +-
 llvm/lib/Target/AMDGPU/SIInstrInfo.cpp| 17 +++---
 .../Target/AMDGPU/SIShrinkInstructions.cpp|  4 +--
 .../lib/Target/ARM/AsmParser/ARMAsmParser.cpp |  4 ++-
 .../Hexagon/HexagonConstPropagation.cpp   |  3 +-
 llvm/lib/Target/Hexagon/HexagonGenExtract.cpp |  2 +-
 llvm/lib/Target/RISCV/RISCVISelLowering.cpp   |  4 ++-
 llvm/lib/Target/X86/X86ISelLowering.cpp   |  6 ++--
 llvm/lib/Transforms/IPO/ArgumentPromotion.cpp |  3 +-
 llvm/lib/Transforms/Utils/SimplifyCFG.cpp |  2 +-
 llvm/unittests/ADT/APFixedPointTest.cpp   |  9 +++---
 mlir/include/mlir/IR/BuiltinAttributes.td |  4 ++-
 mlir/include/mlir/IR/OpImplementation.h   |  3 +-
 .../Conversion/TosaToArith/TosaToArith.cpp|  2 +-
 .../Dialect/ControlFlow/IR/ControlFlowOps.cpp |  2 +-
 mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp|  2 +-
 mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp  |  2 +-
 mlir/lib/IR/Builders.cpp  | 16 +++---
 .../SPIRV/Deserialization/Deserializer.cpp|  6 ++--
 .../Dialect/SPIRV/SerializationTest.cpp   |  2 +-
 41 files changed, 137 insertions(+), 80 deletions(-)

diff --git a/clang/lib/AST/ByteCode/IntegralAP.h 
b/clang/lib/AST/ByteCode/IntegralAP.h
index a4d656433344b7..6ab3d09ec85d5b 100644
--- a/clang/lib/AST/ByteCode/IntegralAP.h
+++ b/clang/lib/AST/ByteCode/IntegralAP.h
@@ -61,7 +61,7 @@ template  class IntegralAP final {
 
   IntegralAP(APInt V) : V(V) {}
   /// Arbitrary value for uninitialized variables.
-  IntegralAP() : IntegralAP(-1, 3) {}
+  IntegralAP() : IntegralAP(Signed ? -1 : 7, 3) {}
 
   IntegralAP operator-() const { return IntegralAP(-V); }
   IntegralAP operator-(const IntegralAP &Other) const {
@@ -112,7 +112,9 @@ template  class IntegralAP final {
 
   template 
   static IntegralAP from(Integral I, unsigned BitWidth) {
-APInt Copy = APInt(BitWidth, static_cast(I), InputSigned);
+// TODO: Avoid implicit trunc?
+APInt Copy = APInt(BitWidth, static_cast(I), InputSigned,
+   /*implicitTrunc=*/true);
 
 return IntegralAP(Copy);
   }
diff --git a/clang/lib/CodeGen/CGVTT.cpp b/clang/lib/CodeGen/CGVTT.cpp
index 20bd2c2fc2c642..989a07d09d50ee 100644
--- a/clang/lib/CodeGen/CGVTT.cpp
+++ b/clang/lib/CodeGen/CGVTT.cpp
@@ -85,8 +85,9 @@ CodeGenVTables::EmitVTTDefinition(llvm::GlobalVariable *VTT,
  cast(VTable->getValueType())
  ->getElementType(AddressPoint.VTableIndex));
  unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
- llvm::ConstantRange InRange(llvm::APInt(32, -Offset, true),
- llvm::APInt(32, VTableSize - Offset, true));
+ llvm::ConstantRange InRange(
+ llvm::APInt(32, (int)-Offset, true),
+ llvm::APInt(32, (int)(VTableSize - Offset), true));
  llvm::Constant *Init = llvm::ConstantExpr::getGetElementPtr(
  VTable->getValueType(), VTable, Idxs, /*InBounds=*/true, InRange);
 
diff --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index dcc35d5689831e..ff018fa22db866 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2099,8 +2099,9 @@ ItaniumCXXABI::getVTableAddressPoint(BaseSubobject Base,
   unsigned VTableSize =
   ComponentSize * Layout.getVTableSize(AddressPoint.VTableIndex);
   unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
-  llvm::ConstantRange InRange(llvm::APInt(32, -Offset, true),
-  llvm::APInt(3

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/109219

>From c471c2fe615082fb9f9c5f39466bd47ec5b86bb0 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 18 Sep 2024 22:34:30 +
Subject: [PATCH 1/4] [lldb] Add support for disabling frame recognizers

Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.
---
 .../lldb/Target/StackFrameRecognizer.h|   7 +-
 lldb/source/Commands/CommandObjectFrame.cpp   | 144 +-
 lldb/source/Target/StackFrameRecognizer.cpp   |  29 +++-
 3 files changed, 131 insertions(+), 49 deletions(-)

diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 617b1617d404a1..0deb4d46454784 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -125,11 +125,13 @@ class StackFrameRecognizerManager {
  bool first_instruction_only = true);
 
   void ForEach(std::function<
-   void(uint32_t recognizer_id, std::string recognizer_name,
-std::string module, llvm::ArrayRef symbols,
+   void(uint32_t recognizer_id, bool enabled,
+std::string recognizer_name, std::string module,
+llvm::ArrayRef symbols,
 Mangled::NamePreference name_reference, bool regexp)> const
&callback);
 
+  bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
 
   void RemoveAllRecognizers();
@@ -155,6 +157,7 @@ class StackFrameRecognizerManager {
 lldb::RegularExpressionSP symbol_regexp;
 Mangled::NamePreference symbol_mangling;
 bool first_instruction_only;
+bool enabled;
   };
 
   std::deque m_recognizers;
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index d8091e8993fde1..86db334ddc677e 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -31,8 +31,10 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/Args.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 using namespace lldb;
@@ -930,10 +932,13 @@ class CommandObjectFrameRecognizerClear : public 
CommandObjectParsed {
 };
 
 static void
-PrintRecognizerDetails(Stream &strm, const std::string &name,
+PrintRecognizerDetails(Stream &strm, const std::string &name, bool enabled,
const std::string &module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
+  if (!enabled)
+strm << "[disabled] ";
+
   strm << name << ", ";
 
   if (!module.empty())
@@ -957,53 +962,43 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name,
   llvm::interleaveComma(symbols, strm);
 }
 
-class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
-public:
-  CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
-  : CommandObjectParsed(interpreter, "frame recognizer delete",
-"Delete an existing frame recognizer by id.",
-nullptr) {
-AddSimpleArgumentList(eArgTypeRecognizerID);
-  }
-
-  ~CommandObjectFrameRecognizerDelete() override = default;
+// Base class for commands which accept a single frame recognizer as an 
argument
+class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
+  public:
+CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+const char *name,
+const char *help = nullptr,
+const char *syntax = nullptr,
+uint32_t flags = 0)
+: CommandObjectParsed(interpreter, name, help, syntax, flags) {
+  AddSimpleArgumentList(eArgTypeRecognizerID);
+}
 
   void
   HandleArgumentCompletion(CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
+std::cerr << request.GetCursorIndex() << std::endl;
 if (request.GetCursorIndex() != 0)
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, std::string rname, std::string module,
+[&request](uint32_t rid, bool enabled, std::string rname, std::string 
module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
   StreamString strm;
   if (rname.empty())
 rname = "(internal)";
 
-  PrintRecognizerDetails(strm, rname, module, symbols, symbol_mangling,
- regexp);
+  PrintRecognizerDetails(strm

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

Sometimes you only want to temporarily disable a frame recognizer instead of 
deleting it. In particular, when dealing with one of the builtin frame 
recognizers, which cannot be restored after deletion.

To be able to write test cases for this functionality, I also changed 
`lldb/test/API/commands/frame/recognizer` to use normal C instead of Objective-C

---

Patch is 22.70 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/109219.diff


7 Files Affected:

- (modified) lldb/include/lldb/Target/StackFrameRecognizer.h (+9-6) 
- (modified) lldb/source/Commands/CommandObjectFrame.cpp (+110-38) 
- (modified) lldb/source/Target/StackFrameRecognizer.cpp (+26-12) 
- (modified) lldb/test/API/commands/frame/recognizer/Makefile (+1-1) 
- (modified) lldb/test/API/commands/frame/recognizer/TestFrameRecognizer.py 
(+136-10) 
- (removed) lldb/test/API/commands/frame/recognizer/categories (-1) 
- (renamed) lldb/test/API/commands/frame/recognizer/main.c (+1-1) 


``diff
diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 617b1617d404a1..6c67a7fb4f68dd 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -124,12 +124,14 @@ class StackFrameRecognizerManager {
  Mangled::NamePreference symbol_mangling,
  bool first_instruction_only = true);
 
-  void ForEach(std::function<
-   void(uint32_t recognizer_id, std::string recognizer_name,
-std::string module, llvm::ArrayRef symbols,
-Mangled::NamePreference name_reference, bool regexp)> const
-   &callback);
-
+  void
+  ForEach(std::function symbols,
+ Mangled::NamePreference name_preference,
+ bool regexp)> const &callback);
+
+  bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
 
   void RemoveAllRecognizers();
@@ -155,6 +157,7 @@ class StackFrameRecognizerManager {
 lldb::RegularExpressionSP symbol_regexp;
 Mangled::NamePreference symbol_mangling;
 bool first_instruction_only;
+bool enabled;
   };
 
   std::deque m_recognizers;
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index d8091e8993fde1..d42cbeaba15f22 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -31,8 +31,10 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/Args.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 using namespace lldb;
@@ -930,10 +932,13 @@ class CommandObjectFrameRecognizerClear : public 
CommandObjectParsed {
 };
 
 static void
-PrintRecognizerDetails(Stream &strm, const std::string &name,
+PrintRecognizerDetails(Stream &strm, const std::string &name, bool enabled,
const std::string &module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
+  if (!enabled)
+strm << "[disabled] ";
+
   strm << name << ", ";
 
   if (!module.empty())
@@ -957,53 +962,45 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name,
   llvm::interleaveComma(symbols, strm);
 }
 
-class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
+// Base class for commands which accept a single frame recognizer as an 
argument
+class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
 public:
-  CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
-  : CommandObjectParsed(interpreter, "frame recognizer delete",
-"Delete an existing frame recognizer by id.",
-nullptr) {
+  CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+  const char *name,
+  const char *help = nullptr,
+  const char *syntax = nullptr,
+  uint32_t flags = 0)
+  : CommandObjectParsed(interpreter, name, help, syntax, flags) {
 AddSimpleArgumentList(eArgTypeRecognizerID);
   }
 
-  ~CommandObjectFrameRecognizerDelete() override = default;
-
   void
   HandleArgumentCompletion(CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
+std::cerr << request.GetCursorIndex() << std::endl;
 if (request.GetCursorIndex() != 0)
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, std::string rname, std::string module,
+[&request](uint32_t rid, bool enabled, std::string rname,
+   std::string module,

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/109219

>From c471c2fe615082fb9f9c5f39466bd47ec5b86bb0 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 18 Sep 2024 22:34:30 +
Subject: [PATCH 1/5] [lldb] Add support for disabling frame recognizers

Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.
---
 .../lldb/Target/StackFrameRecognizer.h|   7 +-
 lldb/source/Commands/CommandObjectFrame.cpp   | 144 +-
 lldb/source/Target/StackFrameRecognizer.cpp   |  29 +++-
 3 files changed, 131 insertions(+), 49 deletions(-)

diff --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 617b1617d404a1..0deb4d46454784 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -125,11 +125,13 @@ class StackFrameRecognizerManager {
  bool first_instruction_only = true);
 
   void ForEach(std::function<
-   void(uint32_t recognizer_id, std::string recognizer_name,
-std::string module, llvm::ArrayRef symbols,
+   void(uint32_t recognizer_id, bool enabled,
+std::string recognizer_name, std::string module,
+llvm::ArrayRef symbols,
 Mangled::NamePreference name_reference, bool regexp)> const
&callback);
 
+  bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
 
   void RemoveAllRecognizers();
@@ -155,6 +157,7 @@ class StackFrameRecognizerManager {
 lldb::RegularExpressionSP symbol_regexp;
 Mangled::NamePreference symbol_mangling;
 bool first_instruction_only;
+bool enabled;
   };
 
   std::deque m_recognizers;
diff --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index d8091e8993fde1..86db334ddc677e 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -31,8 +31,10 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/Args.h"
 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 using namespace lldb;
@@ -930,10 +932,13 @@ class CommandObjectFrameRecognizerClear : public 
CommandObjectParsed {
 };
 
 static void
-PrintRecognizerDetails(Stream &strm, const std::string &name,
+PrintRecognizerDetails(Stream &strm, const std::string &name, bool enabled,
const std::string &module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
+  if (!enabled)
+strm << "[disabled] ";
+
   strm << name << ", ";
 
   if (!module.empty())
@@ -957,53 +962,43 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name,
   llvm::interleaveComma(symbols, strm);
 }
 
-class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
-public:
-  CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
-  : CommandObjectParsed(interpreter, "frame recognizer delete",
-"Delete an existing frame recognizer by id.",
-nullptr) {
-AddSimpleArgumentList(eArgTypeRecognizerID);
-  }
-
-  ~CommandObjectFrameRecognizerDelete() override = default;
+// Base class for commands which accept a single frame recognizer as an 
argument
+class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
+  public:
+CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+const char *name,
+const char *help = nullptr,
+const char *syntax = nullptr,
+uint32_t flags = 0)
+: CommandObjectParsed(interpreter, name, help, syntax, flags) {
+  AddSimpleArgumentList(eArgTypeRecognizerID);
+}
 
   void
   HandleArgumentCompletion(CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
+std::cerr << request.GetCursorIndex() << std::endl;
 if (request.GetCursorIndex() != 0)
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, std::string rname, std::string module,
+[&request](uint32_t rid, bool enabled, std::string rname, std::string 
module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
   StreamString strm;
   if (rname.empty())
 rname = "(internal)";
 
-  PrintRecognizerDetails(strm, rname, module, symbols, symbol_mangling,
- regexp);
+  PrintRecognizerDetails(strm

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits


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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits


https://github.com/kadircet commented:

hi sorry for missing this during the review time, i believe this change is 
changing some of the core support library interfaces in a way that's not 
justified.

this is an interface implemented by quite a lot of both upstream and downstream 
clients, but this change doesn't describe what the semantics around `IsText` 
is. so none of these implementations have a way to sustainably understand and 
maintain this new semantic.

Moreover reading the commit description, I also cannot see how callers can 
figure out what to pass into this parameter. You were probably fine with this 
during the implementation as they don't need to care, but this will create an 
unreasonable maintenance burden for the contributors in the future as no one 
can reason about semantics here.

Even further, the way this functionality is implemented today, relies on doing 
system calls to figure out `IsText`ness. This is against the very nature of a 
VFS, the behavior you're implementing here will not compose well with rest of 
the contractual guarantees we have via the VFS abstractions (surely there're 
cases where we violate that already today, but that isn't a reason to add more).

---

So in the light of all of these, I believe this change should've gotten 
approvals from an LLVM code-owner before submission. In that regard, I can see 
that you've been trying for the past 2 weeks to get attention, unfortunately 
community can be slow to respond at times, I'd like to ask you to a little bit 
more patient, or even start an RFC in discourse to get more visibility (as PRs 
are quite easy to miss).

I was also making some recommendations in `RealFileSystem::openFileForRead` 
about how this change might be contained. I think it'd be a lot better if you 
can keep the interfaces clean and introduce the change only into the parts in 
which these semantics are meaningful.

---

Up until these questions are settled (and I am more than happy to follow up on 
the discussion on my behalf), may I ask you to revert this change? As it's 
going to create some confusion both in the upstream and downstream users the 
more it stays around.

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits



@@ -121,8 +121,18 @@ ContentCache::getBufferOrNone(DiagnosticsEngine &Diag, 
FileManager &FM,
   // Start with the assumption that the buffer is invalid to simplify early
   // return paths.
   IsBufferInvalid = true;
-
-  auto BufferOrError = FM.getBufferForFile(*ContentsEntry, IsFileVolatile);
+  bool IsText = false;

kadircet wrote:

in all other code paths, `IsText` always defaults to true, but you're making it 
default to `false` here, is this intentional ?

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits



@@ -323,10 +325,11 @@ ErrorOr RealFileSystem::status(const Twine &Path) 
{
 }
 
 ErrorOr>
-RealFileSystem::openFileForRead(const Twine &Name) {
+RealFileSystem::openFileForRead(const Twine &Name, bool IsText) {
   SmallString<256> RealName, Storage;
   Expected FDOrErr = sys::fs::openNativeFileForRead(
-  adjustPath(Name, Storage), sys::fs::OF_None, &RealName);
+  adjustPath(Name, Storage), IsText ? sys::fs::OF_Text : sys::fs::OF_None,

kadircet wrote:

this seems like the only place that uses `IsText`. is there any reason why you 
can't deduce that signal from `Name` here directly? rather than propagating it 
all the way from the caller?

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {

dlav-sc wrote:

addressed

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits


kadircet wrote:

i've also just noticed 
https://github.com/llvm/llvm-project/commit/3b3accb598ec87a6a30b0e18ded06071030bb78f,
 which seem to be pushed without review and any tests, changing behavior more 
in a non-obvious way. Please not that logic you have in:
```
  Expected FDOrErr = sys::fs::openNativeFileForRead(
  adjustPath(Name, Storage), IsText ? sys::fs::OF_Text : sys::fs::OF_None,
  &RealName);
```

is affecting all, not just zOS, and by fiddling with the value passed by 
default, you're in turn changing the flags used by all the platforms.

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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits



@@ -1806,7 +1806,7 @@ bool AMDGPUDAGToDAGISel::SelectGlobalSAddr(SDNode *N,
   // instructions to perform VALU adds with immediates or inline literals.
   unsigned NumLiterals =
   !TII->isInlineConstant(APInt(32, COffsetVal & 0x)) +
-  !TII->isInlineConstant(APInt(32, COffsetVal >> 32));
+  !TII->isInlineConstant(APInt(32, uint64_t(COffsetVal) >> 32));

nikic wrote:

Good point. I created https://github.com/llvm/llvm-project/pull/109413 to 
adjust various places in the AMDGPU backend to use these helper. (A lot more 
places outside AMDGPU, but not going to do these right now...)

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread Abhina Sree via lldb-commits


abhina-sree wrote:

> 3b3accb

Hi, sure I will revert the two changes so we can discuss further. The OF_Text 
flag only affects the z/OS platform behaviour, the OF_TextWithCRLF will affect 
z/OS and Windows. On other platforms, the flag doesn't show any difference in 
behaviour that I'm aware of

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

[Lldb-commits] [lldb] efdb3ae - Revert "[SystemZ][z/OS] Propagate IsText parameter to open text files as text (#107906)"

2024-09-20 Thread Abhina Sreeskantharajan via lldb-commits


Author: Abhina Sreeskantharajan
Date: 2024-09-20T08:18:16-04:00
New Revision: efdb3ae23247850d3886e3708400f0d991ed59e1

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

LOG: Revert "[SystemZ][z/OS] Propagate IsText parameter to open text files as 
text (#107906)"

This reverts commit edf3b277a5f2ebe144827ed47463c22743cac5f9.

Added: 


Modified: 
clang-tools-extra/clangd/FS.cpp
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/support/ThreadsafeFS.cpp
clang-tools-extra/clangd/unittests/ClangdTests.cpp
clang/include/clang/Basic/FileManager.h

clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
clang/lib/Basic/FileManager.cpp
clang/lib/Basic/SourceManager.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
clang/unittests/Driver/DistroTest.cpp
clang/unittests/Driver/ToolChainTest.cpp
clang/unittests/Frontend/PCHPreambleTest.cpp
clang/unittests/Tooling/DependencyScanning/DependencyScannerTest.cpp
lldb/unittests/Host/FileSystemTest.cpp
lldb/unittests/Utility/MockSymlinkFileSystem.h
llvm/include/llvm/Support/AutoConvert.h
llvm/include/llvm/Support/VirtualFileSystem.h
llvm/lib/Support/AutoConvert.cpp
llvm/lib/Support/FileCollector.cpp
llvm/lib/Support/VirtualFileSystem.cpp
llvm/unittests/Support/VirtualFileSystemTest.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/FS.cpp b/clang-tools-extra/clangd/FS.cpp
index bd3c6440c24b0f..5729b9341d9d4b 100644
--- a/clang-tools-extra/clangd/FS.cpp
+++ b/clang-tools-extra/clangd/FS.cpp
@@ -64,8 +64,8 @@ PreambleFileStatusCache::getProducingFS(
 : ProxyFileSystem(std::move(FS)), StatCache(StatCache) {}
 
 llvm::ErrorOr>
-openFileForRead(const llvm::Twine &Path, bool IsText = true) override {
-  auto File = getUnderlyingFS().openFileForRead(Path, IsText);
+openFileForRead(const llvm::Twine &Path) override {
+  auto File = getUnderlyingFS().openFileForRead(Path);
   if (!File || !*File)
 return File;
   // Eagerly stat opened file, as the followup `status` call on the file

diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index 44c6acd3ed83aa..84e8fec342829c 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -479,9 +479,9 @@ class TimerFS : public llvm::vfs::ProxyFileSystem {
   : ProxyFileSystem(std::move(FS)) {}
 
   llvm::ErrorOr>
-  openFileForRead(const llvm::Twine &Path, bool IsText = true) override {
+  openFileForRead(const llvm::Twine &Path) override {
 WallTimerRegion T(Timer);
-auto FileOr = getUnderlyingFS().openFileForRead(Path, IsText);
+auto FileOr = getUnderlyingFS().openFileForRead(Path);
 if (!FileOr)
   return FileOr;
 return std::make_unique(Timer, std::move(FileOr.get()));

diff  --git a/clang-tools-extra/clangd/support/ThreadsafeFS.cpp 
b/clang-tools-extra/clangd/support/ThreadsafeFS.cpp
index bc0b984e577cb8..7398e4258527ba 100644
--- a/clang-tools-extra/clangd/support/ThreadsafeFS.cpp
+++ b/clang-tools-extra/clangd/support/ThreadsafeFS.cpp
@@ -29,7 +29,7 @@ class VolatileFileSystem : public llvm::vfs::ProxyFileSystem {
   : ProxyFileSystem(std::move(FS)) {}
 
   llvm::ErrorOr>
-  openFileForRead(const llvm::Twine &InPath, bool IsText = true) override {
+  openFileForRead(const llvm::Twine &InPath) override {
 llvm::SmallString<128> Path;
 InPath.toVector(Path);
 

diff  --git a/clang-tools-extra/clangd/unittests/ClangdTests.cpp 
b/clang-tools-extra/clangd/unittests/ClangdTests.cpp
index e86385c2072b34..643b8e9f12d751 100644
--- a/clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ b/clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -1010,7 +1010,7 @@ TEST(ClangdTests, PreambleVFSStatCache) {
 : ProxyFileSystem(std::move(FS)), CountStats(CountStats) {}
 
 llvm::ErrorOr>
-openFileForRead(const Twine &Path, bool IsText = true) override {
+openFileForRead(const Twine &Path) override {
   ++CountStats[llvm::sys::path::filename(Path.str())];
   return ProxyFileSystem::openFileForRead(Path);
 }

diff  --git a/clang/include/clang/Basic/FileManager.h 
b/clang/include/clang/Basic/FileManager.h
index 67a69fb79ccefe..527bbef24793ee 100644
--- a/clang/include/clang/Basic/FileManager.h
+++ b/clang/include/clang/Basic/FileManager.h
@@ -286,21 +286,21 @@ class FileManager : public RefCountedBase {
   /// MemoryBuffer if successful, otherwise returning null.
   llvm::ErrorOr>
   getBufferForFile(FileEntryRef Entry, bool isVolatile = false,
-   bool RequiresNullTerminator = true, bool IsText = true,
+

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  static FileSpec getRemoteFileSpec(PlatformSP platform, TargetSP target,
+ModuleSP module,
+const FileSpec &local_file) {
+FileSpec remote_file = module->GetRemoteInstallFileSpec();
+if (remote_file || !target->GetAutoInstallMainExecutable())
+  return remote_file;
+
+if (!local_file)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(local_file.GetFilename().GetCString());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 

dlav-sc wrote:

Yes, It's mostly an aesthetic preference, since I fill that introducing a 
dynamic polymorphism, given that we know all types in advance feels wrong: 
we'll need a dynamic allocation, std::unique_ptr instantiation, etc

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)

dlav-sc wrote:

addressed

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;
+
+private:
+  static FileSpec getRemoteFileSpec(PlatformSP platform, TargetSP target,
+ModuleSP module,
+const FileSpec &local_file) {
+FileSpec remote_file = module->GetRemoteInstallFileSpec();
+if (remote_file || !target->GetAutoInstallMainExecutable())
+  return remote_file;
+
+if (!local_file)
+  return {};
+
+remote_file = platform->GetRemoteWorkingDirectory();
+remote_file.AppendPathComponent(local_file.GetFilename().GetCString());
+
+return remote_file;
+  }
+};
+} // namespace
+
+template 
+static Status installExecutable(const Installer &installer) {
+  if (!installer.m_local_file || !installer.m_remote_file)
+return Status();

dlav-sc wrote:

> was it in the original code?

Nope, It looked strange for me too and I wanted to emit an error here, however 
I've decided to not change any execution logic.

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);
+m_platform->SetFilePermissions(m_remote_file, 0700 /*-rwx--*/);
+  }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+  ProcessLaunchInfo *m_launch_info;

dlav-sc wrote:

addressed. In essence, only `m_launch_info` can be private.

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,
+  ProcessLaunchInfo *launch_info)
+  : m_platform{platform},  m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{
+getRemoteFileSpec(m_platform, target, m_module, m_local_file)},
+m_launch_info{launch_info} {}
+
+  void setRemoteFile() const {
+m_module->SetPlatformFileSpec(m_remote_file);
+m_launch_info->SetExecutableFile(m_remote_file,
+ false /*add_exe_file_as_first_arg*/);

dlav-sc wrote:

addressed

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits



@@ -76,6 +76,79 @@
 using namespace lldb;
 using namespace lldb_private;
 
+namespace {
+
+struct ExecutableInstaller {
+
+  ExecutableInstaller(PlatformSP platform, ModuleSP module)
+  : m_platform{platform}, m_module{module},
+m_local_file{m_module->GetFileSpec()},
+m_remote_file{m_module->GetRemoteInstallFileSpec()} {}
+
+  void setRemoteFile() const { m_module->SetPlatformFileSpec(m_remote_file); }
+
+  PlatformSP m_platform;
+  ModuleSP m_module;
+  const FileSpec m_local_file;
+  const FileSpec m_remote_file;
+};
+
+struct MainExecutableInstaller {
+
+  MainExecutableInstaller(PlatformSP platform, TargetSP target, ModuleSP 
module,

dlav-sc wrote:

addressed

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread David Spickett via lldb-commits


DavidSpickett wrote:

Found by @tschuett on https://github.com/llvm/llvm-project/issues/109119.

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

This got deleted in e078c9507c3abb4d9bb2265c366b26557880a3e3, I presume 
accidentally, because it didn't have a corresponding rst file for it.

So I've brought it back and converted it into Markdown. The content remains 
accurate, from what I know at least.

It's a bit "now draw the rest of the owl" but if nothing else, it gives you a 
bunch of important classes to go and research as a starting point.

You can see the original content here:
https://github.com/llvm/llvm-project/blob/5d71fc5d7b5ffe2323418a09db6eddaf84d6c662/lldb/www/adding-language-support.html

---
Full diff: https://github.com/llvm/llvm-project/pull/109427.diff


2 Files Affected:

- (modified) lldb/docs/index.rst (+1) 
- (added) lldb/docs/resources/addinglanguagesupport.md (+95) 


``diff
diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index d9b8e589eb2ac0..dd44a8430add80 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -163,6 +163,7 @@ interesting areas to contribute to lldb.
resources/caveats
resources/projects
resources/lldbdap
+   resources/addinglanguagesupport
Public C++ API 
Private C++ API 
 
diff --git a/lldb/docs/resources/addinglanguagesupport.md 
b/lldb/docs/resources/addinglanguagesupport.md
new file mode 100644
index 00..d92104a0e5e6ec
--- /dev/null
+++ b/lldb/docs/resources/addinglanguagesupport.md
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a reference, and that's all 
you
+  need. At this stage, the pointer size is all you need.
+2. Layout info: You need the size of an instance of the type, but you still 
don't
+  need to know all the guts of the type.
+3. Full type inf

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread kadir çetinkaya via lldb-commits


kadircet wrote:

thanks a lot for the swift response!

I can see how none of these implementations are not using those flags _today_, 
but we're changing the observable behavior for them as well, and if some of 
those implementations decides to give meaning to these flags, it might be 
impossible to keep it working. Especially because we're not clearly defining 
the semantics around how callers are going to figure those bits out.

So I am wondering:
- if we can make these changes in a very limited way, e.g. just in 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Support/Unix/Path.inc#L972-L1118.
 We already have lots of `__MVS__` specific regions in there. that's also the 
"right" layer if you want to perform syscalls.
- if we need to make those changes in the VFS interfaces indeed, can you 
provide the rationale explaining that need and what the new semantics mean both 
for implementors of the interface and the callers of it?

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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
   m_fallback.GetFullyQualifiedType(context, callback);
 }
 
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+  auto maybe_dieoffset = entry.getDIEUnitOffset();
+  if (!maybe_dieoffset)
+return false;
+
+  // [Optimization] instead of parsing the entry from dwo file, we simply
+  // check if the query_name can point to an entry of the same DIE offset.
+  // This greatly reduced number of dwo file parsed and thus improved the
+  // performance.
+  for (const DebugNames::Entry &query_entry :
+   entry.getNameIndex()->equal_range(query_name)) {
+auto query_dieoffset = query_entry.getDIEUnitOffset();
+if (!query_dieoffset)
+  continue;
+
+if (*query_dieoffset == *maybe_dieoffset) {
+  return true;
+} else if (*query_dieoffset > *maybe_dieoffset) {
+  // The pool entries of the same name are sequentially cluttered together
+  // so if the query name from `query_name` is after the target entry, this
+  // is definitely not the correct one, we can stop searching.
+  return false;
+}
+  }
+  return false;
+}
+
 bool DebugNamesDWARFIndex::SameParentChain(
 llvm::ArrayRef parent_names,
 llvm::ArrayRef parent_entries) const {
-
   if (parent_entries.size() != parent_names.size())
 return false;
 
-  auto SameAsEntryATName = [this](llvm::StringRef name,
-  const DebugNames::Entry &entry) {
-// Peek at the AT_name of `entry` and test equality to `name`.
-auto maybe_dieoffset = entry.getDIEUnitOffset();
-if (!maybe_dieoffset)
-  return false;
-DWARFUnit *unit = GetNonSkeletonUnit(entry);
-if (!unit)
-  return false;
-return name == unit->PeekDIEName(unit->GetOffset() + *maybe_dieoffset);

felipepiovezan wrote:

> but the evaluation is very fast 293ms which I do not think it is slow enough 
> to measure perf. How do you get 5~6 seconds from this?

Oh, my bad, to get to 5s you would have to revert the original parent chain 
patch. It is still interesting that you are getting 0.2s for that experiment 
when I was getting 1.4s (after the parent chain patches). I have some time 
today and will try to repro this out of curiosity.

But I am glad this doesn't seem to regress perf!

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett created 
https://github.com/llvm/llvm-project/pull/109427

This got deleted in e078c9507c3abb4d9bb2265c366b26557880a3e3, I presume 
accidentally, because it didn't have a corresponding rst file for it.

So I've brought it back and converted it into Markdown. The content remains 
accurate, from what I know at least.

It's a bit "now draw the rest of the owl" but if nothing else, it gives you a 
bunch of important classes to go and research as a starting point.

You can see the original content here:
https://github.com/llvm/llvm-project/blob/5d71fc5d7b5ffe2323418a09db6eddaf84d6c662/lldb/www/adding-language-support.html

>From cc4032e58217a01ff414b8d03866a1631f492df8 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Fri, 20 Sep 2024 14:00:44 +0100
Subject: [PATCH] [lldb][docs] Resurrect the information on adding a new
 language

This got deleted in e078c9507c3abb4d9bb2265c366b26557880a3e3,
I presume accidentally, because it didn't have a corresponding rst
file for it.

So I've brought it back and converted it into Markdown. The content
remains accurate, from what I know at least.

It's a bit "now draw the rest of the owl" but if nothing else,
it gives you a bunch of important classes to go and research
as a starting point.

You can see the original content here:
https://github.com/llvm/llvm-project/blob/5d71fc5d7b5ffe2323418a09db6eddaf84d6c662/lldb/www/adding-language-support.html
---
 lldb/docs/index.rst  |  1 +
 lldb/docs/resources/addinglanguagesupport.md | 95 
 2 files changed, 96 insertions(+)
 create mode 100644 lldb/docs/resources/addinglanguagesupport.md

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index d9b8e589eb2ac0..dd44a8430add80 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -163,6 +163,7 @@ interesting areas to contribute to lldb.
resources/caveats
resources/projects
resources/lldbdap
+   resources/addinglanguagesupport
Public C++ API 
Private C++ API 
 
diff --git a/lldb/docs/resources/addinglanguagesupport.md 
b/lldb/docs/resources/addinglanguagesupport.md
new file mode 100644
index 00..d92104a0e5e6ec
--- /dev/null
+++ b/lldb/docs/resources/addinglanguagesupport.md
@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Thorsten Schütt via lldb-commits


tschuett wrote:

Thanks!

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

[Lldb-commits] [lldb] 1553714 - Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

2024-09-20 Thread David Spickett via lldb-commits


Author: David Spickett
Date: 2024-09-20T15:18:45+01:00
New Revision: 1553714b0093a8ef907faf3b3145c224caa7364a

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

LOG: Revert "[lldb] Change the implementation of Status to store an llvm::Error 
(NFC) (#106774)"

This reverts commit 104b249c236578d298384416c495ff7310b97f4d because
it has caused 2 test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/141/builds/2544

Failed Tests (2):
  lldb-api :: functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
  lldb-unit :: Utility/./UtilityTests.exe/StatusTest/ErrorWin32

I reckon the cause is the same, that we construct an error with the Win32
NO_ERROR value which means there was no error but we're assuming anything
with an error code is a failure.

Added: 


Modified: 
lldb/include/lldb/Utility/Status.h
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/source/Utility/Status.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/Status.h 
b/lldb/include/lldb/Utility/Status.h
index 084ce4afb8cefd..795c830b965173 100644
--- a/lldb/include/lldb/Utility/Status.h
+++ b/lldb/include/lldb/Utility/Status.h
@@ -28,67 +28,6 @@ namespace lldb_private {
 
 const char *ExpressionResultAsCString(lldb::ExpressionResults result);
 
-/// Going a bit against the spirit of llvm::Error,
-/// lldb_private::Status need to store errors long-term and sometimes
-/// copy them. This base class defines an interface for this
-/// operation.
-class CloneableError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  CloneableError() : ErrorInfo() {}
-  virtual std::unique_ptr Clone() const = 0;
-  static char ID;
-};
-
-/// Common base class for all error-code errors.
-class CloneableECError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  std::error_code convertToErrorCode() const override { return EC; }
-  void log(llvm::raw_ostream &OS) const override { OS << EC.message(); }
-  static char ID;
-
-protected:
-  CloneableECError() = delete;
-  CloneableECError(std::error_code ec) : ErrorInfo(), EC(ec) {}
-  std::error_code EC;
-};
-/// FIXME: Move these declarations closer to where they're used.
-class MachKernelError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  MachKernelError(std::error_code ec) : ErrorInfo(ec) {}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class Win32Error : public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  Win32Error(std::error_code ec, const llvm::Twine &msg = {}) : ErrorInfo(ec) 
{}
-  std::string message() const override;
-  std::unique_ptr Clone() const override;
-  static char ID;
-};
-
-class ExpressionError
-: public llvm::ErrorInfo {
-public:
-  using llvm::ErrorInfo::ErrorInfo;
-  ExpressionError(std::error_code ec, std::string msg = {})
-  : ErrorInfo(ec), m_string(msg) {}
-  std::unique_ptr Clone() const override;
-  std::string message() const override { return m_string; }
-  static char ID;
-
-protected:
-  std::string m_string;
-};
-
 /// \class Status Status.h "lldb/Utility/Status.h" An error handling class.
 ///
 /// This class is designed to be able to hold any error code that can be
@@ -161,7 +100,9 @@ class Status {
   }
 
   static Status FromExpressionError(lldb::ExpressionResults result,
-std::string msg);
+std::string msg) {
+return Status(result, lldb::eErrorTypeExpression, msg);
+  }
 
   /// Set the current error to errno.
   ///
@@ -174,7 +115,6 @@ class Status {
   const Status &operator=(Status &&);
   /// Avoid using this in new code. Migrate APIs to llvm::Expected instead.
   static Status FromError(llvm::Error error);
-
   /// FIXME: Replace this with a takeError() method.
   llvm::Error ToError() const;
   /// Don't call this function in new code. Instead, redesign the API
@@ -209,20 +149,12 @@ class Status {
 
   /// Access the error value.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error value.
   ValueType GetError() const;
 
   /// Access the error type.
   ///
-  /// If the internally stored \ref llvm::Error is an \ref
-  /// llvm::ErrorList then this returns the error value of the first
-  /// error.
-  ///
   /// \return
   /// The error type enumeration value.
   lldb::ErrorType GetType() const;
@@ -238,9 +170,12 @@ class Status {
   bool Success() const;
 
 protected:
-  Status(llvm::Error error) : m_error(std::move(error)) {}
-  llvm::Error m_error

[Lldb-commits] [lldb] [lldb] fix vFile:open, vFile:unlink error codes (PR #106950)

2024-09-20 Thread via lldb-commits



@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
 
 static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
   uint64_t fail_result, Status &error) 
{
+  // The packet is expected to have the following format:
+  // 'F,'
+
   response.SetFilePos(0);
   if (response.GetChar() != 'F')
 return fail_result;
+
   int32_t result = response.GetS32(-2, 16);
   if (result == -2)
 return fail_result;
-  if (response.GetChar() == ',') {
-int result_errno = gdb_errno_to_system(response.GetS32(-1, 16));
-if (result_errno != -1)
-  error = Status(result_errno, eErrorTypePOSIX);
-else
-  error = Status(-1, eErrorTypeGeneric);
-  } else
+
+  if (response.GetChar() != ',') {
 error.Clear();
+return result;
+  }
+
+  // Response packet should contain a error code at the end. This code
+  // corresponds either to the gdb IOFile error code, or to the posix errno.

dlav-sc wrote:

> I think this feature was only added to the gdb remote serial protocol in May 
> of this year?

Yeah, looks like you're right, I didn't notice this.

Thanks for your reply.

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

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-20 Thread David Spickett via lldb-commits


DavidSpickett wrote:

I've reverted this 
https://github.com/llvm/llvm-project/commit/1553714b0093a8ef907faf3b3145c224caa7364a.
 I feel like the solution isn't that complicated but it's close to end of the 
work day for me and I'd like to see the bot green again.

If you have a suggestion on how to handle this I can try it on Windows on 
Monday.

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

[Lldb-commits] [lldb] [lldb] Change the implementation of Status to store an llvm::Error (NFC) (PR #106774)

2024-09-20 Thread David Spickett via lldb-commits


DavidSpickett wrote:

Output from the 2 failures:
```
FAIL: test_file_fail 
(TestGDBRemotePlatformFile.TestGDBRemotePlatformFile.test_file_fail)

Test mocked failures of remote operations

--

Traceback (most recent call last):
  File 
"C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\gdb_remote_client\TestGDBRemotePlatformFile.py",
 line 53, in test_file_fail
self.match(
  File 
"C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py",
 line 2092, in match
self.assertTrue(
AssertionError: False is not true : 'platform file open /some/file.txt -v 0755' 
returned unexpected result, got 'error: function not supported'

Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe

--

 TEST 'lldb-unit :: Utility/./UtilityTests.exe/1/8' FAILED 

Script(shard):
--
GTEST_OUTPUT=json:C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Utility\.\UtilityTests.exe-lldb-unit-4868-1-8.json
 GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=8 GTEST_SHARD_INDEX=1 
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Utility\.\UtilityTests.exe
--

Script:
--
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\tools\lldb\unittests\Utility\.\UtilityTests.exe
 --gtest_filter=StatusTest.ErrorWin32
--
C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp(86):
 error: Expected equality of these values:
  0
Which is: NULL
  success.AsCString()
Which is: "The operation completed successfully. "

C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp(87):
 error: Value of: success.ToError()
  Actual: true
Expected: false

C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp(88):
 error: Value of: success.Success()
  Actual: false
Expected: true


C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp:86
Expected equality of these values:
  0
Which is: NULL
  success.AsCString()
Which is: "The operation completed successfully. "

C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp:87
Value of: success.ToError()
  Actual: true
Expected: false

C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\unittests\Utility\StatusTest.cpp:88
Value of: success.Success()
  Actual: false
Expected: true
```


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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -444,6 +492,98 @@ void DebugNamesDWARFIndex::GetNamespaces(
   m_fallback.GetNamespaces(name, callback);
 }
 
+void DebugNamesDWARFIndex::GetNamespacesWithParents(
+ConstString name, llvm::ArrayRef parent_names,
+llvm::function_ref callback) {
+  Progress progress("Get namespace from index for %s", name.GetCString());
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(name.GetStringRef())) {
+lldb_private::dwarf::Tag entry_tag = entry.tag();
+if (entry_tag == DW_TAG_namespace ||
+entry_tag == DW_TAG_imported_declaration) {
+  std::optional> parent_chain =
+  getParentChain(entry);
+  if (!parent_chain) {
+// Fallback: use the base class implementation.
+if (!ProcessEntry(entry, [&](DWARFDIE die) {
+  return ProcessDieMatchParentNames(name, parent_names, die, 
callback);
+}))
+  return;
+continue;
+  }
+
+  if (parent_chain->size() < parent_names.size())
+continue;
+  else if (parent_chain->size() == parent_names.size()) {

felipepiovezan wrote:

Yup, that's right! The reason for the suggestion is that this is mostly an 
optimization of the `WithinParentChain` method, so it makes sense to live in 
there (also removes some code duplication)

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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
   m_fallback.GetFullyQualifiedType(context, callback);
 }
 
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+  auto maybe_dieoffset = entry.getDIEUnitOffset();
+  if (!maybe_dieoffset)
+return false;
+
+  // [Optimization] instead of parsing the entry from dwo file, we simply
+  // check if the query_name can point to an entry of the same DIE offset.
+  // This greatly reduced number of dwo file parsed and thus improved the
+  // performance.
+  for (const DebugNames::Entry &query_entry :
+   entry.getNameIndex()->equal_range(query_name)) {
+auto query_dieoffset = query_entry.getDIEUnitOffset();
+if (!query_dieoffset)
+  continue;
+
+if (*query_dieoffset == *maybe_dieoffset) {
+  return true;
+} else if (*query_dieoffset > *maybe_dieoffset) {
+  // The pool entries of the same name are sequentially cluttered together
+  // so if the query name from `query_name` is after the target entry, this
+  // is definitely not the correct one, we can stop searching.

felipepiovezan wrote:

Yup, I agree with @labath interpretation of the spec here.

Here's what I would suggest:

1. Make a patch just changes the implementation of `SameAsEntryATName`. This 
will benefit your use case (dwo) by itself and we can measure the perf impact 
of not being able to relying on the sorting of entries in all cases.

Then we can branch the work into two parallel lines of investigation:

1.1. [If sorting entries turns out to be important] we can create a series of 
patches exploring the augmentation string idea from @labath 

1.2. One patch for `GetNamespacesWithParents`  and then one patch for 
`GetTypesWithParents`

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [llvm] [SystemZ][z/OS] Propagate IsText parameter to open text files as text (PR #107906)

2024-09-20 Thread Abhina Sree via lldb-commits


abhina-sree wrote:

> thanks a lot for the swift response!
> 
> I can see how none of these implementations are not using those flags 
> _today_, but we're changing the observable behavior for them as well, and if 
> some of those implementations decides to give meaning to these flags, it 
> might be impossible to keep it working. Especially because we're not clearly 
> defining the semantics around how callers are going to figure those bits out.
> 
> So I am wondering:
> 
> * if we can make these changes in a very limited way, e.g. just in 
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Support/Unix/Path.inc#L972-L1118.
>  We already have lots of `__MVS__` specific regions in there. that's also the 
> "right" layer if you want to perform syscalls.
> * if we need to make those changes in the VFS interfaces indeed, can you 
> provide the rationale explaining that need and what the new semantics mean 
> both for implementors of the interface and the callers of it?

So when we call this function sys::fs::openNativeFileForRead, there is an 
assumption that we already know whether the file is text or binary based on the 
OpenFlags that are passed to it. This function RealFileSystem::openFileForRead 
also assumes the file is binary by passing the OF_None flag. I'm not sure if 
there is a better way to determine whether the file is text or binary in this 
function without querying the file tag using a z/OS syscall in this function. 

I think I can limit it to the following change to avoid adding additional 
parameters to all the other functions which I agree is a much cleaner and less 
invasive solution. Please let me know your thoughts, thanks!

```
diff --git a/llvm/lib/Support/VirtualFileSystem.cpp 
b/llvm/lib/Support/VirtualFileSystem.cpp
index 928c0b5a24ed..7153560754d1 100644
--- a/llvm/lib/Support/VirtualFileSystem.cpp
+++ b/llvm/lib/Support/VirtualFileSystem.cpp
@@ -22,6 +22,7 @@
 #include "llvm/ADT/Twine.h"
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Config/llvm-config.h"
+#include "llvm/Support/AutoConvert.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/Chrono.h"
 #include "llvm/Support/Compiler.h"
@@ -325,8 +326,16 @@ ErrorOr RealFileSystem::status(const Twine &Path) {
 ErrorOr>
 RealFileSystem::openFileForRead(const Twine &Name) {
   SmallString<256> RealName, Storage;
+  bool IsText = true;
+#ifdef __MVS__
+  // If the file is tagged with a text ccsid, it may require autoconversion.
+  llvm::ErrorOr IsFileText =
+  llvm::iszOSTextFile(Name.str().c_str());
+  if (IsFileText)
+IsText = *IsFileText;
+#endif
   Expected FDOrErr = sys::fs::openNativeFileForRead(
-  adjustPath(Name, Storage), sys::fs::OF_None, &RealName);
+  adjustPath(Name, Storage), IsText ? sys::fs::OF_Text : sys::fs::OF_None, 
&RealName);
   if (!FDOrErr)
 return errorToErrorCode(FDOrErr.takeError());
   return std::unique_ptr(
```



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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Felipe de Azevedo Piovezan via lldb-commits


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

[Lldb-commits] [lldb] Improve type and namespace lookup using parent chain (PR #108907)

2024-09-20 Thread Felipe de Azevedo Piovezan via lldb-commits



@@ -402,6 +420,36 @@ bool DebugNamesDWARFIndex::SameParentChain(
   return true;
 }
 
+bool DebugNamesDWARFIndex::WithinParentChain(
+llvm::ArrayRef query_parent_names,
+llvm::ArrayRef parent_chain) const {
+  if (parent_chain.size() < query_parent_names.size())
+return false;
+
+  size_t query_idx = 0, chain_idx = 0;
+  while (query_idx < query_parent_names.size() &&
+ chain_idx < parent_chain.size()) {
+if (SameAsEntryATName(query_parent_names[query_idx],
+  parent_chain[chain_idx])) {
+  ++query_idx;
+  ++chain_idx;
+} else {
+  // Name does not match, try next parent_chain entry if the current entry
+  // is namespace because the current one can be an inline namespace.

felipepiovezan wrote:

Would that help? I don't see anything in the DIE that let's us identify inline 
namespaces...

https://godbolt.org/z/GT98Yfbqv

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Thorsten Schütt via lldb-commits


tschuett wrote:

LLDB docs seem to rst.

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

[Lldb-commits] [lldb] [lldb] refactor Target::Install function (PR #108996)

2024-09-20 Thread via lldb-commits


dlav-sc wrote:

> Looks good to me.

Thank you for the review. I haven't merge rights yet, so could you press the 
button, please.

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread David Spickett via lldb-commits


DavidSpickett wrote:

Mostly RST yes, but we have a few recent documents in Markdown which I enabled 
support for in https://github.com/llvm/llvm-project/pull/89716.

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

[Lldb-commits] [clang] [lldb] [llvm] [llvm][TargetParser] Return StringMap from getHostCPUFeatures (PR #97824)

2024-09-20 Thread via lldb-commits


satmandu wrote:

Worth noting that this affects mesa too: 
https://gitlab.freedesktop.org/mesa/mesa/-/issues/11896

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Thorsten Schütt via lldb-commits



@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the

tschuett wrote:

I am not convinced of using branches in the repo.

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

[Lldb-commits] [clang] [lldb] [llvm] [mlir] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-09-20 Thread Nikita Popov via lldb-commits


https://github.com/nikic updated https://github.com/llvm/llvm-project/pull/80309

>From 17ba7e8538a2a4cc7b17322d26e8ea83ce27d617 Mon Sep 17 00:00:00 2001
From: Nikita Popov 
Date: Thu, 19 Sep 2024 17:27:13 +0200
Subject: [PATCH] apint only

---
 clang/lib/AST/ByteCode/IntegralAP.h   |  6 ++--
 clang/lib/CodeGen/CGVTT.cpp   |  5 +--
 clang/lib/CodeGen/ItaniumCXXABI.cpp   |  5 +--
 clang/lib/Parse/ParseInit.cpp |  4 ++-
 clang/lib/Sema/SemaExpr.cpp   |  7 ++--
 clang/lib/Sema/SemaOpenMP.cpp |  4 ++-
 lldb/source/Expression/DWARFExpression.cpp|  7 ++--
 llvm/include/llvm/ADT/APFixedPoint.h  |  4 ++-
 llvm/lib/Analysis/ConstantFolding.cpp |  3 +-
 llvm/lib/Analysis/Loads.cpp   |  6 ++--
 llvm/lib/Analysis/MemoryBuiltins.cpp  |  2 ++
 llvm/lib/Analysis/ScalarEvolution.cpp |  2 +-
 llvm/lib/Bitcode/Reader/BitcodeReader.cpp |  3 +-
 .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp |  5 ++-
 .../SelectionDAG/SelectionDAGBuilder.cpp  |  3 +-
 .../CodeGen/SelectionDAG/SelectionDAGISel.cpp |  8 +++--
 .../CodeGen/SelectionDAG/TargetLowering.cpp   |  8 +++--
 llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp  |  2 +-
 llvm/lib/IR/Constants.cpp |  4 ++-
 .../Target/AArch64/AArch64ISelLowering.cpp| 32 +--
 llvm/lib/Target/AMDGPU/SIInstrInfo.cpp|  3 +-
 .../Target/AMDGPU/SIShrinkInstructions.cpp|  4 +--
 .../lib/Target/ARM/AsmParser/ARMAsmParser.cpp |  4 ++-
 .../Hexagon/HexagonConstPropagation.cpp   |  3 +-
 llvm/lib/Target/Hexagon/HexagonGenExtract.cpp |  2 +-
 llvm/lib/Target/RISCV/RISCVISelLowering.cpp   |  4 ++-
 llvm/lib/Target/X86/X86ISelLowering.cpp   |  6 ++--
 llvm/lib/Transforms/IPO/ArgumentPromotion.cpp |  3 +-
 llvm/lib/Transforms/Utils/SimplifyCFG.cpp |  2 +-
 llvm/unittests/ADT/APFixedPointTest.cpp   |  9 +++---
 mlir/include/mlir/IR/BuiltinAttributes.td |  4 ++-
 mlir/include/mlir/IR/OpImplementation.h   |  3 +-
 .../Conversion/TosaToArith/TosaToArith.cpp|  2 +-
 .../Dialect/ControlFlow/IR/ControlFlowOps.cpp |  2 +-
 mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp|  2 +-
 mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp  |  2 +-
 mlir/lib/IR/Builders.cpp  | 16 +++---
 .../SPIRV/Deserialization/Deserializer.cpp|  6 ++--
 .../Dialect/SPIRV/SerializationTest.cpp   |  2 +-
 39 files changed, 125 insertions(+), 74 deletions(-)

diff --git a/clang/lib/AST/ByteCode/IntegralAP.h 
b/clang/lib/AST/ByteCode/IntegralAP.h
index a4d656433344b7..6ab3d09ec85d5b 100644
--- a/clang/lib/AST/ByteCode/IntegralAP.h
+++ b/clang/lib/AST/ByteCode/IntegralAP.h
@@ -61,7 +61,7 @@ template  class IntegralAP final {
 
   IntegralAP(APInt V) : V(V) {}
   /// Arbitrary value for uninitialized variables.
-  IntegralAP() : IntegralAP(-1, 3) {}
+  IntegralAP() : IntegralAP(Signed ? -1 : 7, 3) {}
 
   IntegralAP operator-() const { return IntegralAP(-V); }
   IntegralAP operator-(const IntegralAP &Other) const {
@@ -112,7 +112,9 @@ template  class IntegralAP final {
 
   template 
   static IntegralAP from(Integral I, unsigned BitWidth) {
-APInt Copy = APInt(BitWidth, static_cast(I), InputSigned);
+// TODO: Avoid implicit trunc?
+APInt Copy = APInt(BitWidth, static_cast(I), InputSigned,
+   /*implicitTrunc=*/true);
 
 return IntegralAP(Copy);
   }
diff --git a/clang/lib/CodeGen/CGVTT.cpp b/clang/lib/CodeGen/CGVTT.cpp
index 20bd2c2fc2c642..989a07d09d50ee 100644
--- a/clang/lib/CodeGen/CGVTT.cpp
+++ b/clang/lib/CodeGen/CGVTT.cpp
@@ -85,8 +85,9 @@ CodeGenVTables::EmitVTTDefinition(llvm::GlobalVariable *VTT,
  cast(VTable->getValueType())
  ->getElementType(AddressPoint.VTableIndex));
  unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
- llvm::ConstantRange InRange(llvm::APInt(32, -Offset, true),
- llvm::APInt(32, VTableSize - Offset, true));
+ llvm::ConstantRange InRange(
+ llvm::APInt(32, (int)-Offset, true),
+ llvm::APInt(32, (int)(VTableSize - Offset), true));
  llvm::Constant *Init = llvm::ConstantExpr::getGetElementPtr(
  VTable->getValueType(), VTable, Idxs, /*InBounds=*/true, InRange);
 
diff --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index dcc35d5689831e..ff018fa22db866 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2099,8 +2099,9 @@ ItaniumCXXABI::getVTableAddressPoint(BaseSubobject Base,
   unsigned VTableSize =
   ComponentSize * Layout.getVTableSize(AddressPoint.VTableIndex);
   unsigned Offset = ComponentSize * AddressPoint.AddressPointIndex;
-  llvm::ConstantRange InRange(llvm::APInt(32, -Offset, true),
-  llvm::APInt(32, VTableSize - Offset, true));
+  llvm::ConstantRange InRange(
+  llvm::APInt(32, (int)-Offset, true),
+  llv

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits



@@ -1 +0,0 @@
-objc

vogelsgesang wrote:

The intended test coverage of this test case seems to be to test the frame 
recognizers as indicated by the file path.
Making making it run also on non-Mac platforms, we are hence gaining test 
coverage on other systems.

There is no comment I could find which states that frame recognizers work 
differently for Objective-C. As such, I would expect any test coverage for 
Objective-C to be incidental, and would expect the Objective-C support to be 
tested in-depth by some other test cases.

I am used to the guideline "It's ok to remove incidental test coverage. If the 
test coverage was worthwhile, there should have been a comment added as part of 
adding the test" from other projects. But that's based on my experience with 
how other projects treat their test suites. Not sure if this also applies to 
LLDB? 

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread John Harrison via lldb-commits



@@ -204,12 +171,67 @@ The default hostname being used `localhost`.
 }
 ```
 
-## Custom debugger commands
+### Configuration Settings Reference
+
+For both launch and attach configurations, lldb-dap accepts the following 
`lldb-dap`
+specific key/value pairs:
+
+|parameter  |type|req | |

ashgti wrote:

`enableDisplayExtendedBacktrace`, `enableDisplayExtendedBacktrace` and 
`enableSyntheticChildDebugging` are missing, see

https://github.com/llvm/llvm-project/blob/main/lldb/tools/lldb-dap/README.md?plain=1#L39C1-L42C1



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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread John Harrison via lldb-commits



@@ -204,12 +171,67 @@ The default hostname being used `localhost`.
 }
 ```
 
-## Custom debugger commands
+### Configuration Settings Reference
+
+For both launch and attach configurations, lldb-dap accepts the following 
`lldb-dap`
+specific key/value pairs:
+
+|parameter  |type|req | |
+|---||:--:|-|
+|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
+|**type**   |string|Y| Must be "lldb-dap".
+|**request**|string|Y| Must be "launch" or "attach".
+|**program**|string|Y| Path to the executable to launch.
+|**sourcePath** |string| | Specify a source path to remap \"./\" to allow 
full paths to be used when setting breakpoints in binaries that have relative 
source paths.
+|**sourceMap**  |[string[2]]| | Specify an array of path re-mappings. Each 
element in the array must be a two element array containing a source and 
destination pathname. Overrides sourcePath.
+|**debuggerRoot**   | string| |Specify a working directory to use when 
launching lldb-dap. If the debug information in your executable contains 
relative paths, this option can be used so that `lldb-dap` can find source 
files and object files that have relative paths.
+|**commandEscapePrefix** | string | | The escape prefix to use for executing 
regular LLDB commands in the Debug Console, instead of printing variables. 
Defaults to a back-tick (`\``). If it's an empty string, then all expression in 
the Debug Console are treated as regular LLDB commands.
+|**customFrameFormat** | string | | If non-empty, stack frames will have 
descriptions generated based on the provided format. See 
https://lldb.llvm.org/use/formatting.html for an explanation on format strings 
for frames. If the format string contains errors, an error message will be 
displayed on the Debug Console and the default frame names will be used. This 
might come with a performance cost because debug information might need to be 
processed to generate the description.
+|**customThreadFormat** | string | | Same as `customFrameFormat`, but for 
threads instead of stack frames.
+|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target.
+|**preRunCommands** |[string]| | LLDB commands executed just before 
launching/attaching, after the LLDB target has been created.
+|**stopCommands**   |[string]| | LLDB commands executed just after each stop.
+|**exitCommands**   |[string]| | LLDB commands executed when the program exits.
+|**terminateCommands** |[string]| | LLDB commands executed when the debugging 
session ends.
+
+All commands and command outputs will be sent to the debugger console when 
they are executed.
+
+For JSON configurations of `"type": "launch"`, the JSON configuration can 
additionally
+contain the following key/value pairs:
+
+|parameter  |type|req | |
+|---||:--:|-|
+|**program**|string|Y| Path to the executable to launch.
+|**args**   |[string]|| An array of command line argument strings to 
be passed to the program being launched.
+|**cwd**|string| | The program working directory.
+|**env**|dictionary| | Environment variables to set when launching 
the program. The format of each environment variable string is "VAR=VALUE" for 
environment variables with values or just "VAR" for environment variables with 
no values.
+|**stopOnEntry**|boolean| | Whether to stop program immediately after 
launching.
+|**runInTerminal**  |boolean| | Launch the program inside an integrated 
terminal in the IDE. Useful for debugging interactive command line programs.
+|**launchCommands** |[string]| | LLDB commands executed to launch the program.
+
+For JSON configurations of `"type": "attach"`, the JSON configuration can 
contain
+the following `lldb-dap` specific key/value pairs:
+
+|parameter  |type|req | |
+|---||:--:|-|
+|**program**|string  | | Path to the executable to attach to. This 
value is optional but can help to resolve breakpoints prior the attaching to 
the program.
+|**pid**|number  | | The process id of the process you wish to 
attach to. If **pid** is omitted, the debugger will attempt to attach to the 
program by finding a process whose file name matches the file name from 
**porgram**. Setting this value to `${command:pickMyProcess}` will allow 
interactive process selection in the IDE.
+|**waitFor**|boolean | | Wait for the process to launch.
+|**attachCommands** |[string]| | LLDB commands that will be executed after 
**preRunCommands** which take place of the code that normally does the attach. 
The commands can create a new target and attach or launch it however desired. 
This allows custom launch and attach configurations. Core files can use `target 
create --core /path/to/core` to attach to core files.
+
+## Debug Co

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread John Harrison via lldb-commits



@@ -204,12 +171,67 @@ The default hostname being used `localhost`.
 }
 ```
 
-## Custom debugger commands
+### Configuration Settings Reference
+
+For both launch and attach configurations, lldb-dap accepts the following 
`lldb-dap`
+specific key/value pairs:
+
+|parameter  |type|req | |
+|---||:--:|-|
+|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
+|**type**   |string|Y| Must be "lldb-dap".
+|**request**|string|Y| Must be "launch" or "attach".
+|**program**|string|Y| Path to the executable to launch.
+|**sourcePath** |string| | Specify a source path to remap \"./\" to allow 
full paths to be used when setting breakpoints in binaries that have relative 
source paths.
+|**sourceMap**  |[string[2]]| | Specify an array of path re-mappings. Each 
element in the array must be a two element array containing a source and 
destination pathname. Overrides sourcePath.
+|**debuggerRoot**   | string| |Specify a working directory to use when 
launching lldb-dap. If the debug information in your executable contains 
relative paths, this option can be used so that `lldb-dap` can find source 
files and object files that have relative paths.
+|**commandEscapePrefix** | string | | The escape prefix to use for executing 
regular LLDB commands in the Debug Console, instead of printing variables. 
Defaults to a back-tick (`\``). If it's an empty string, then all expression in 
the Debug Console are treated as regular LLDB commands.
+|**customFrameFormat** | string | | If non-empty, stack frames will have 
descriptions generated based on the provided format. See 
https://lldb.llvm.org/use/formatting.html for an explanation on format strings 
for frames. If the format string contains errors, an error message will be 
displayed on the Debug Console and the default frame names will be used. This 
might come with a performance cost because debug information might need to be 
processed to generate the description.
+|**customThreadFormat** | string | | Same as `customFrameFormat`, but for 
threads instead of stack frames.
+|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target.

ashgti wrote:

One feature that isn't document here is that commands can use a `!` 
(https://github.com/llvm/llvm-project/blob/main/lldb/tools/lldb-dap/LLDBUtils.cpp#L34)
 or `?` 
(https://github.com/llvm/llvm-project/blob/main/lldb/tools/lldb-dap/LLDBUtils.cpp#L31)
 prefix that adjusts command behavior slightly. 

`?` is quiet on success, i.e. the if the command succeeds then nothing is 
written to stdout.

`!` is to check for an error and stop running the commands if it fails, so if 
one of the commands depends on another this will stop the chain of commands.

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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits


https://github.com/Michael137 approved this pull request.

Module test comments, LGTM

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits



@@ -0,0 +1,95 @@
+# Adding Programming Language Support
+
+LLDB has been architected to make it straightforward to add support for a
+programming language. Only a small enum in core LLDB needs to be modified to
+make LLDB aware of a new programming language. Everything else can be supplied
+in derived classes that need not even be present in the core LLDB repository.
+This makes it convenient for developers adding language support either in
+branches or downstream repositories since it practically eliminates the
+potential for merge conflicts.
+
+The basic steps are:
+* Add the language to the `LanguageType` enum.
+* Add a `TypeSystem` for the language.
+* Add expression evaluation support.
+
+Additionally, you may want to create a `Language` and `LanguageRuntime` plugin
+for your language, which enables support for advanced features like dynamic
+typing and data formatting.
+
+## Add the Language to the LanguageType enum
+
+The `LanguageType` enum
+(see 
[lldb-enumerations.h](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/lldb-enumerations.h))
+contains a list of every language known to LLDB. It is the one place where
+support for a language must live that will need to merge cleanly with upstream
+LLDB if you are developing your language support in a separate branch. When
+adding support for a language previously unknown to LLDB, start by adding an
+enumeration entry to `LanguageType`.
+
+## Add a TypeSystem for the Language
+
+Both 
[Module](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Core/Module.h)
+and 
[Target](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Target/Target.h)
+support the retrieval of a `TypeSystem` instance via 
`GetTypeSystemForLanguage()`.
+For `Module`, this method is directly on the `Module` instance. For `Target`,
+this is retrieved indirectly via the `TypeSystemMap` for the `Target` instance.
+
+The `TypeSystem` instance returned by the `Target` is expected to be capable of
+evaluating expressions, while the `TypeSystem` instance returned by the 
`Module`
+is not. If want to support expression evaluation for your language, you could
+consider one of the following approaches:
+* Implement a single `TypeSystem` class that supports evaluation when given an
+  optional `Target`, implementing all the expression evaluation methods on the
+  `TypeSystem`.
+* Create multiple `TypeSystem` classes, one for evaluation and one for static
+  `Module` usage.
+
+For clang and Swift, the latter approach was chosen. Primarily to make it
+clearer that evaluation with the static `Module`-returned `TypeSystem` 
instances
+make no sense, and have them error out on those calls. But either approach is
+fine.
+
+# Add Expression Evaluation Support
+
+Expression Evaluation support is enabled by implementing the relevant methods 
on
+a `TypeSystem`-derived class. Search for `Expression` in the
+[TypeSystem 
header](https://github.com/llvm/llvm-project/blob/main/lldb/include/lldb/Symbol/TypeSystem.h)
+to find the methods to implement.
+
+# Type Completion
+
+There are three levels of type completion, each requiring more type 
information:
+1. Pointer size: When you have a forward decl or a reference, and that's all 
you
+  need. At this stage, the pointer size is all you need.
+2. Layout info: You need the size of an instance of the type, but you still 
don't
+  need to know all the guts of the type.
+3. Full type info: Here you need everything, because you're playing with
+  internals of it, such as modifying a member variable.
+
+Ensure you never complete more of a type than is needed for a given situation.
+This will keep your type system from doing more work than necessary.
+
+# Creating Types
+
+Your `TypeSystem` will need an approach for creating types based on a set of
+`Module`s. If your type info is going to come from DWARF info, you will want to
+subclass 
[DWARFASTParser](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h).
+
+# Language and LanguageRuntime Plugins
+
+If you followed the steps outlined above, you already have taught LLDB a great
+deal about your language. If your language's runtime model and fundamental data
+types don't differ much from the C model, you are pretty much done.
+
+However it is likely that your language offers its own data types for things
+like strings and arrays, and probably has a notion of dynamic types, where the
+effective type of a variable can only be known at runtime.
+
+These tasks are covered by two plugins:
+* a `LanguageRuntime` plugin, which provides LLDB with a dynamic view of your
+  language; this plugin answers questions that require a live process to 
acquire
+  information (for example dynamic type resolution).
+* a `Language plugin`, which provides LLDB with a static view of your language;
+  questions that are statically knoawble and do not require a process are

vogelsgesang wrote:

```suggestion
  ques

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang approved this pull request.


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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits



@@ -395,6 +389,138 @@ def 
test_frame_recognizer_not_only_first_instruction(self):
 variables.GetValueAtIndex(1).GetValueType(), 
lldb.eValueTypeVariableArgument
 )
 
+def test_frame_recognizer_disable(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+target, process, thread, _ = lldbutil.run_to_name_breakpoint(
+self, "foo", exe_name=exe
+)
+
+# Clear internal & plugins recognizers that get initialized at launch.
+self.runCmd("frame recognizer clear")
+
+self.runCmd(
+"command script import "
++ os.path.join(self.getSourceDir(), "recognizer.py")
+)
+
+# Add a frame recognizer in that target.
+self.runCmd(
+"frame recognizer add -l recognizer.MyFrameRecognizer -s a.out -n 
foo -n bar"
+)
+
+# The frame is recognized
+self.expect(
+"frame recognizer info 0",
+substrs=["frame 0 is recognized by recognizer.MyFrameRecognizer"],
+)
+
+# Disable the recognizer
+self.runCmd("frame recognizer disable 0")
+
+self.expect(
+"frame recognizer list",
+substrs=[
+"0: [disabled] recognizer.MyFrameRecognizer, module a.out, 
demangled symbol foo"
+],
+)
+
+self.expect(
+"frame recognizer info 0",
+substrs=["frame 0 not recognized by any recognizer"],
+)
+
+# Re-enable the recognizer
+self.runCmd("frame recognizer enable 0")
+
+self.expect(
+"frame recognizer list",
+substrs=[
+"0: recognizer.MyFrameRecognizer, module a.out, demangled 
symbol foo"
+],
+)
+
+self.expect(
+"frame recognizer info 0",
+substrs=["frame 0 is recognized by recognizer.MyFrameRecognizer"],
+)
+
+def test_frame_recognizer_disable(self):

Michael137 wrote:

FYI, duplicate test-names will result in only the last declared one being run 
(see https://github.com/llvm/llvm-project/pull/97043)

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits



@@ -1,77 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 

vogelsgesang wrote:

Fixed.

> It leaves the impression that that might change in the future 

I got ahead of myself while typing this...
See the RFC to also distribute/auto-download the `lldb-dap` binary here: 
https://discourse.llvm.org/t/rfc-automatically-download-lldb-dap/81322

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Jonas Devlieghere via lldb-commits



@@ -1,77 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 

JDevlieghere wrote:

Ah, I had missed that!

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere approved this pull request.

Thanks! 

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Jonas Devlieghere via lldb-commits



@@ -1,77 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not packaged with the VS Code extension.
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* use the binary provided by your toolchain (for example `xcrun -f lldb-dap` 
on macOS) or contact your toolchain vendor to include it

JDevlieghere wrote:

Missing period.

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Jonas Devlieghere via lldb-commits


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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/109266

>From 006f7cbe4aa1621b9490ae534ea6e17f56e3f6af Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Thu, 19 Sep 2024 11:45:29 +0200
Subject: [PATCH 1/8] [lldb-dap][docs] Improve README

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
   * Show the examples before the reference. Most new users just want to
 get going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
   * Remove the `stopOnEntry` setting from "attach", since this is a
 launch-only setting
   * Document the previously undocumented settings `sourcePath`,
 `commandEscapePrefix`, `custom{Frame,Thread}Format`,
 `runInTerminal`
   * Add the settings `debuggerRoot` and `sourceMap` to the common
 section. So far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by
  default and that LLDB commands need to be escaped.
---
 lldb/tools/lldb-dap/README.md | 150 +++---
 1 file changed, 86 insertions(+), 64 deletions(-)

diff --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index 11a14d29ab51e2..f757c25fa3ab2c 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -1,71 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not currently packaged with the VS-Code extension. 
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* contact your toolchain vendor
 
-Launching to attaching require you to create a [launch 
configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
-This file defines arguments that get passed to `lldb-dap` and the 
configuration settings control how the launch or attach happens.
-
-### Launch Configuration Settings
-
-When you launch a program with Visual Studio Code you will need to create a 
[launch.json](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations)
-file that defines how your program will be run. The JSON configuration file 
can contain the following `lldb-dap` specific launch key/value pairs:
-
-|parameter  |type|req | |
-|---||:--:|-|
-|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
-|**type**   |string|Y| Must be "lldb-dap".
-|**request**|string|Y| Must be "launch".
-|**program**|string|Y| Path to the executable to launch.
-|**args**   |[string]|| An array of command line argument strings to 
be passed to the program being launched.
-|**cwd**|string| | The program working directory.
-|**env**|dictionary| | Environment variables to set when launching 
the program. The format of each environment variable string is "VAR=VALUE" for 
environment variables with values or just "VAR" for environment variables with 
no values.
-|**stopOnEntry**|boolean| | Whether to stop program immediately after 
launching.
-|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target. Commands and command output will be sent to 
the debugger console when they are executed.
-|**preRunCommands** |[string]| | LLDB commands executed just before launching 
after the LLDB target has been created. Commands and command output will be 
sent to the debugger console when they are executed.
-|**stopCommands**   |[string]| | LLDB commands executed just after each stop. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**launchCommands** |[string]| | LLDB commands executed to launch the program. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**exitCommands**   |[string]| | LLDB commands executed when the program 
exits. Commands and command output will be sent to the debugger console when 
they are executed.
-|**terminateCommands** |

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Jonas Devlieghere via lldb-commits


JDevlieghere wrote:

I think this page leaves a lot to be desired but it's a good start.

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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Jonas Devlieghere via lldb-commits


https://github.com/JDevlieghere approved this pull request.


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

[Lldb-commits] [lldb] [lldb][docs] Resurrect the information on adding a new language (PR #109427)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

I can't really say if the content is correct, but this was definitely an 
informative read

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

[Lldb-commits] [lldb] [lldb/Interpreter] Propagate `script` output back to command return object (PR #109440)

2024-09-20 Thread Med Ismail Bennani via lldb-commits


https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/109440

When running a oneliner script expression, if the script interpreter returned a 
value, that value would be printed to the debugger standard output straight 
from the interpreter instead of being propagated back to the command return 
object, which would then forward it to its output stream.

This implies that when evaluating a oneliner script expression (with 
`SBCommandInterpreter::HandleCommand`), the return value would get printed to 
stdout, but we would not be able to fetch it from the command return object.

This patch solves this issue by extending the default Python 
`InteractiveConsole` class to keep track of the return value, before include it 
to the command return object.

rdar://132420488

>From 77d1924a105ef60bf2328f7f67302b9d8f026c7a Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 19 Aug 2024 21:11:18 -0700
Subject: [PATCH] [lldb/Interpreter] Propagate `script` output back to command
 return object

When running a oneliner script expression, if the script interpreter
returned a value, that value would be printed to the debugger standard
output straight from the interpreter instead of being propagated back to
the command return object, which would then forward it to its output stream.

This implies that when evaluating a oneliner script expression (with
`SBCommandInterpreter::HandleCommand`), the return value would get
printed to stdout, but we would not be able to fetch it from the command
return object.

This patch solves this issue by extending the default Python
`InteractiveConsole` class to keep track of the return value, before
include it to the command return object.

rdar://132420488

Signed-off-by: Med Ismail Bennani 
---
 .../Interpreter/embedded_interpreter.py   | 39 +--
 .../Python/ScriptInterpreterPython.cpp|  7 +++-
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/lldb/source/Interpreter/embedded_interpreter.py 
b/lldb/source/Interpreter/embedded_interpreter.py
index a487592ef1aee5..fd5c44d0121fbd 100644
--- a/lldb/source/Interpreter/embedded_interpreter.py
+++ b/lldb/source/Interpreter/embedded_interpreter.py
@@ -8,6 +8,8 @@
 import lldb
 import traceback
 
+from io import StringIO
+
 try:
 import readline
 import rlcompleter
@@ -116,19 +118,50 @@ def run_python_interpreter(local_dict):
 print("Script exited with code %s" % e.code)
 
 
+class LLDBInteractiveConsole(code.InteractiveConsole):
+def __init__(self, locals=None):
+super().__init__(locals)
+self.result_output = None
+
+### Implementation detail:
+### 
https://docs.python.org/3/library/code.html#code.InteractiveInterpreter.runsource
+def runsource(self, source, filename="", symbol="single"):
+# Redirect stdout to capture print statements
+old_stdout = sys.stdout
+sys.stdout = result_output = StringIO()
+
+try:
+compiled_code = self.compile(source, filename, symbol)
+if compiled_code is None:
+return False
+
+exec(compiled_code, self.locals)
+return True
+except Exception as e:
+self.showsyntaxerror(filename)
+return False
+finally:
+self.result_output = result_output
+sys.stdout = old_stdout
+
+def get_last_result(self):
+return self.result_output.getvalue()
+
 def run_one_line(local_dict, input_string):
 global g_run_one_line_str
 try:
 input_string = strip_and_check_exit(input_string)
-repl = code.InteractiveConsole(local_dict)
+repl = LLDBInteractiveConsole(local_dict)
 if input_string:
 # A newline is appended to support one-line statements containing
 # control flow. For example "if True: print(1)" silently does
 # nothing, but works with a newline: "if True: print(1)\n".
 input_string += "\n"
-repl.runsource(input_string)
+if repl.runsource(input_string):
+return repl.get_last_result()
 elif g_run_one_line_str:
-repl.runsource(g_run_one_line_str)
+if repl.runsource(g_run_one_line_str):
+return repl.get_last_result()
 except LLDBExit:
 pass
 except SystemExit as e:
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 63691d24f0dadb..30b67ce48a4be9 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -884,9 +884,12 @@ bool ScriptInterpreterPythonImpl::ExecuteOneLine(
   PyRefType::Owned,
   PyObject_CallObject(m_run_one_line_function.get(),
   pargs.get()));
-

[Lldb-commits] [lldb] [lldb/Interpreter] Propagate `script` output back to command return object (PR #109440)

2024-09-20 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Med Ismail Bennani (medismailben)


Changes

When running a oneliner script expression, if the script interpreter returned a 
value, that value would be printed to the debugger standard output straight 
from the interpreter instead of being propagated back to the command return 
object, which would then forward it to its output stream.

This implies that when evaluating a oneliner script expression (with 
`SBCommandInterpreter::HandleCommand`), the return value would get printed to 
stdout, but we would not be able to fetch it from the command return object.

This patch solves this issue by extending the default Python 
`InteractiveConsole` class to keep track of the return value, before include it 
to the command return object.

rdar://132420488

---
Full diff: https://github.com/llvm/llvm-project/pull/109440.diff


2 Files Affected:

- (modified) lldb/source/Interpreter/embedded_interpreter.py (+36-3) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp (+5-2) 


``diff
diff --git a/lldb/source/Interpreter/embedded_interpreter.py 
b/lldb/source/Interpreter/embedded_interpreter.py
index a487592ef1aee5..fd5c44d0121fbd 100644
--- a/lldb/source/Interpreter/embedded_interpreter.py
+++ b/lldb/source/Interpreter/embedded_interpreter.py
@@ -8,6 +8,8 @@
 import lldb
 import traceback
 
+from io import StringIO
+
 try:
 import readline
 import rlcompleter
@@ -116,19 +118,50 @@ def run_python_interpreter(local_dict):
 print("Script exited with code %s" % e.code)
 
 
+class LLDBInteractiveConsole(code.InteractiveConsole):
+def __init__(self, locals=None):
+super().__init__(locals)
+self.result_output = None
+
+### Implementation detail:
+### 
https://docs.python.org/3/library/code.html#code.InteractiveInterpreter.runsource
+def runsource(self, source, filename="", symbol="single"):
+# Redirect stdout to capture print statements
+old_stdout = sys.stdout
+sys.stdout = result_output = StringIO()
+
+try:
+compiled_code = self.compile(source, filename, symbol)
+if compiled_code is None:
+return False
+
+exec(compiled_code, self.locals)
+return True
+except Exception as e:
+self.showsyntaxerror(filename)
+return False
+finally:
+self.result_output = result_output
+sys.stdout = old_stdout
+
+def get_last_result(self):
+return self.result_output.getvalue()
+
 def run_one_line(local_dict, input_string):
 global g_run_one_line_str
 try:
 input_string = strip_and_check_exit(input_string)
-repl = code.InteractiveConsole(local_dict)
+repl = LLDBInteractiveConsole(local_dict)
 if input_string:
 # A newline is appended to support one-line statements containing
 # control flow. For example "if True: print(1)" silently does
 # nothing, but works with a newline: "if True: print(1)\n".
 input_string += "\n"
-repl.runsource(input_string)
+if repl.runsource(input_string):
+return repl.get_last_result()
 elif g_run_one_line_str:
-repl.runsource(g_run_one_line_str)
+if repl.runsource(g_run_one_line_str):
+return repl.get_last_result()
 except LLDBExit:
 pass
 except SystemExit as e:
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 63691d24f0dadb..30b67ce48a4be9 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -884,9 +884,12 @@ bool ScriptInterpreterPythonImpl::ExecuteOneLine(
   PyRefType::Owned,
   PyObject_CallObject(m_run_one_line_function.get(),
   pargs.get()));
-  if (return_value.IsValid())
+  if (return_value.IsValid()) {
 success = true;
-  else if (options.GetMaskoutErrors() && PyErr_Occurred()) {
+PythonString repr = return_value.Repr();
+if (repr && repr.GetSize())
+  result->AppendMessage(repr.GetString());
+  } else if (options.GetMaskoutErrors() && PyErr_Occurred()) {
 PyErr_Print();
 PyErr_Clear();
   }

``




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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits



@@ -204,12 +171,67 @@ The default hostname being used `localhost`.
 }
 ```
 
-## Custom debugger commands
+### Configuration Settings Reference
+
+For both launch and attach configurations, lldb-dap accepts the following 
`lldb-dap`
+specific key/value pairs:
+
+|parameter  |type|req | |

vogelsgesang wrote:

For `enableSyntheticChildDebugging`, this is on purpose. I am considering to 
rename it, because it not only useful for debugging the synthetic child 
providers, but also to debug memory corruptions

For `enableDisplayExtendedBacktrace` and `enableDisplayExtendedBacktrace `, I 
was considering to rename it and remove the `enable` prefix. The `enable` seems 
to be a filler word which adds no additional information. I didn't want to d 
those changes in this commit, though, since I wanted to keep this commit as a 
NFC

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

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits



@@ -1 +0,0 @@
-objc

Michael137 wrote:

Yea that's fair, there doesn't seem to be anything objc specific here, so seems 
ok to turn it into C and enable it on all platforms.

The original change that introduced these did mention Objective-C as one of the 
motivators: https://reviews.llvm.org/D44603. And there seems to have been 
changes made to `AppleObjCStackFrameRecognizer.cpp` in early version of the 
revision (though Phabricator doesn't allow me to view those).

So overall I'm ok with this

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

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Michael Buch via lldb-commits


https://github.com/Michael137 approved this pull request.


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

[Lldb-commits] [lldb] 65c5706 - [lldb-dap][docs] Improve README (#109266)

2024-09-20 Thread via lldb-commits


Author: Adrian Vogelsgesang
Date: 2024-09-20T22:18:19+02:00
New Revision: 65c57066e099fe7f1357485cd6c4fb068bc82323

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

LOG: [lldb-dap][docs] Improve README (#109266)

* Document how to procure and configure the `lldb-dap` binary
* Improve documentation for `launch.json`:
* Show the examples before the reference. Most new users just want to
get going, and will only need the reference later on
   * Deduplicate the list of "launch" and "attach" config settings
* Remove the `stopOnEntry` setting from "attach", since this is a
launch-only setting
* Document the previously undocumented settings `sourcePath`,
`commandEscapePrefix`, `custom{Frame,Thread}Format`, `runInTerminal`
* Add the settings `debuggerRoot` and `sourceMap` to the common section.
So far they were documented as launch-only settings.
* Document that the Debug Console prints variables / expressions by
default and that LLDB commands need to be escaped.

Added: 


Modified: 
lldb/tools/lldb-dap/README.md

Removed: 




diff  --git a/lldb/tools/lldb-dap/README.md b/lldb/tools/lldb-dap/README.md
index ddc2017e843dc2..a51ee95dc83c69 100644
--- a/lldb/tools/lldb-dap/README.md
+++ b/lldb/tools/lldb-dap/README.md
@@ -1,77 +1,30 @@
 # LLDB DAP
 
-## `lldb-dap` Configurations
+## Procuring the `lldb-dap` binary
 
-The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary. It is a
-command line tool that implements the [Debug Adapter
-Protocol](https://microsoft.github.io/debug-adapter-protocol/). It is used to 
power the Visual Studio Code extension but can also be used with other IDEs and 
editors that support DAP.
-The protocol is easy to run remotely and also can allow other tools and IDEs to
-get a full featured debugger with a well defined protocol.
+The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
+This binary is not packaged with the VS Code extension.
 
-## Launching & Attaching Configuration
+There are multiple ways to obtain this binary:
+* build it from source (see [LLDB's build 
instructions](https://lldb.llvm.org/resources/build.html))
+* download it one of the relase packages from the [LLVM release 
page](https://github.com/llvm/llvm-project/releases/). The 
`LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` 
binary.
+* use the binary provided by your toolchain (for example `xcrun -f lldb-dap` 
on macOS) or contact your toolchain vendor to include it.
 
-Launching to attaching require you to create a [launch 
configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
-This file defines arguments that get passed to `lldb-dap` and the 
configuration settings control how the launch or attach happens.
-
-### Launch Configuration Settings
-
-When you launch a program with Visual Studio Code you will need to create a 
[launch.json](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations)
-file that defines how your program will be run. The JSON configuration file 
can contain the following `lldb-dap` specific launch key/value pairs:
-
-|parameter  |type|req | |
-|---||:--:|-|
-|**name**   |string|Y| A configuration name that will be displayed in 
the IDE.
-|**type**   |string|Y| Must be "lldb-dap".
-|**request**|string|Y| Must be "launch".
-|**program**|string|Y| Path to the executable to launch.
-|**args**   |[string]|| An array of command line argument strings to 
be passed to the program being launched.
-|**cwd**|string| | The program working directory.
-|**env**|dictionary| | Environment variables to set when launching 
the program. The format of each environment variable string is "VAR=VALUE" for 
environment variables with values or just "VAR" for environment variables with 
no values.
-|**stopOnEntry**|boolean| | Whether to stop program immediately after 
launching.
-|**initCommands**   |[string]| | LLDB commands executed upon debugger startup 
prior to creating the LLDB target. Commands and command output will be sent to 
the debugger console when they are executed.
-|**preRunCommands** |[string]| | LLDB commands executed just before launching 
after the LLDB target has been created. Commands and command output will be 
sent to the debugger console when they are executed.
-|**stopCommands**   |[string]| | LLDB commands executed just after each stop. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**launchCommands** |[string]| | LLDB commands executed to launch the program. 
Commands and command output will be sent to the debugger console when they are 
executed.
-|**exitCommands**   |[string]| | LLDB c

[Lldb-commits] [lldb] [lldb] Add support for disabling frame recognizers (PR #109219)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] d8d252f - [lldb] Add support for disabling frame recognizers (#109219)

2024-09-20 Thread via lldb-commits


Author: Adrian Vogelsgesang
Date: 2024-09-20T22:17:42+02:00
New Revision: d8d252fe96877f9fdbf6b0b6c19da543e796bb84

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

LOG: [lldb] Add support for disabling frame recognizers (#109219)

Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.

To be able to write test cases for this functionality, I also changed
`lldb/test/API/commands/frame/recognizer` to use normal C instead of
Objective-C

Added: 
lldb/test/API/commands/frame/recognizer/main.c

Modified: 
lldb/include/lldb/Target/StackFrameRecognizer.h
lldb/source/Commands/CommandObjectFrame.cpp
lldb/source/Target/StackFrameRecognizer.cpp
lldb/test/API/commands/frame/recognizer/Makefile
lldb/test/API/commands/frame/recognizer/TestFrameRecognizer.py
lldb/unittests/Target/StackFrameRecognizerTest.cpp

Removed: 
lldb/test/API/commands/frame/recognizer/categories
lldb/test/API/commands/frame/recognizer/main.m



diff  --git a/lldb/include/lldb/Target/StackFrameRecognizer.h 
b/lldb/include/lldb/Target/StackFrameRecognizer.h
index 617b1617d404a1..6c67a7fb4f68dd 100644
--- a/lldb/include/lldb/Target/StackFrameRecognizer.h
+++ b/lldb/include/lldb/Target/StackFrameRecognizer.h
@@ -124,12 +124,14 @@ class StackFrameRecognizerManager {
  Mangled::NamePreference symbol_mangling,
  bool first_instruction_only = true);
 
-  void ForEach(std::function<
-   void(uint32_t recognizer_id, std::string recognizer_name,
-std::string module, llvm::ArrayRef symbols,
-Mangled::NamePreference name_reference, bool regexp)> const
-   &callback);
-
+  void
+  ForEach(std::function symbols,
+ Mangled::NamePreference name_preference,
+ bool regexp)> const &callback);
+
+  bool SetEnabledForID(uint32_t recognizer_id, bool enabled);
   bool RemoveRecognizerWithID(uint32_t recognizer_id);
 
   void RemoveAllRecognizers();
@@ -155,6 +157,7 @@ class StackFrameRecognizerManager {
 lldb::RegularExpressionSP symbol_regexp;
 Mangled::NamePreference symbol_mangling;
 bool first_instruction_only;
+bool enabled;
   };
 
   std::deque m_recognizers;

diff  --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index d8091e8993fde1..142f96946ed3d7 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -930,10 +930,13 @@ class CommandObjectFrameRecognizerClear : public 
CommandObjectParsed {
 };
 
 static void
-PrintRecognizerDetails(Stream &strm, const std::string &name,
+PrintRecognizerDetails(Stream &strm, const std::string &name, bool enabled,
const std::string &module,
llvm::ArrayRef symbols,
Mangled::NamePreference symbol_mangling, bool regexp) {
+  if (!enabled)
+strm << "[disabled] ";
+
   strm << name << ", ";
 
   if (!module.empty())
@@ -957,17 +960,18 @@ PrintRecognizerDetails(Stream &strm, const std::string 
&name,
   llvm::interleaveComma(symbols, strm);
 }
 
-class CommandObjectFrameRecognizerDelete : public CommandObjectParsed {
+// Base class for commands which accept a single frame recognizer as an 
argument
+class CommandObjectWithFrameRecognizerArg : public CommandObjectParsed {
 public:
-  CommandObjectFrameRecognizerDelete(CommandInterpreter &interpreter)
-  : CommandObjectParsed(interpreter, "frame recognizer delete",
-"Delete an existing frame recognizer by id.",
-nullptr) {
+  CommandObjectWithFrameRecognizerArg(CommandInterpreter &interpreter,
+  const char *name,
+  const char *help = nullptr,
+  const char *syntax = nullptr,
+  uint32_t flags = 0)
+  : CommandObjectParsed(interpreter, name, help, syntax, flags) {
 AddSimpleArgumentList(eArgTypeRecognizerID);
   }
 
-  ~CommandObjectFrameRecognizerDelete() override = default;
-
   void
   HandleArgumentCompletion(CompletionRequest &request,
OptionElementVector &opt_element_vector) override {
@@ -975,52 +979,105 @@ class CommandObjectFrameRecognizerDelete : public 
CommandObjectParsed {
   return;
 
 GetTarget().GetFrameRecognizerManager().ForEach(
-[&request](uint32_t rid, std::string rname, std::string module,
+[&request](uint32_t rid, bool enabled, std::string rname,
+

[Lldb-commits] [lldb] [lldb-dap][docs] Improve README (PR #109266)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


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

[Lldb-commits] [lldb] [lldb-dap] Implement value locations for function pointers (PR #104589)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang updated 
https://github.com/llvm/llvm-project/pull/104589

>From a7876a20b5caa53dace056c84a1b7f1e798088f0 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Mon, 12 Aug 2024 14:53:31 +
Subject: [PATCH 1/3] [lldb-dap] Implement value locations for function
 pointers

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to the
pointed-to function from within the "variables" pane.

In general, it would be useful to also a similar location references
also to member function pointers, `std::source_location`,
`std::function`,  and many more. Doing so would require extending the
formatters to provide such a source code location.

There were two RFCs about this a while ago:
https://discourse.llvm.org/t/rfc-extending-formatters-with-a-source-code-reference/68375
https://discourse.llvm.org/t/rfc-sbvalue-metadata-provider/68377/26

However, both RFCs ended without a conclusion. As such, this commit now
solve the lowest-hanging fruit, i.e. function pointers. If people find
it useful, I will revive the RFC afterwards.
---
 .../API/tools/lldb-dap/locations/Makefile |   2 +-
 .../lldb-dap/locations/TestDAP_locations.py   |  49 +++-
 lldb/test/API/tools/lldb-dap/locations/main.c |   5 -
 .../API/tools/lldb-dap/locations/main.cpp |  11 ++
 lldb/tools/lldb-dap/JSONUtils.cpp |  33 -
 lldb/tools/lldb-dap/JSONUtils.h   |   3 +
 lldb/tools/lldb-dap/lldb-dap.cpp  | 113 +-
 7 files changed, 176 insertions(+), 40 deletions(-)
 delete mode 100644 lldb/test/API/tools/lldb-dap/locations/main.c
 create mode 100644 lldb/test/API/tools/lldb-dap/locations/main.cpp

diff --git a/lldb/test/API/tools/lldb-dap/locations/Makefile 
b/lldb/test/API/tools/lldb-dap/locations/Makefile
index 10495940055b63..8b20bcb050 100644
--- a/lldb/test/API/tools/lldb-dap/locations/Makefile
+++ b/lldb/test/API/tools/lldb-dap/locations/Makefile
@@ -1,3 +1,3 @@
-C_SOURCES := main.c
+CXX_SOURCES := main.cpp
 
 include Makefile.rules
diff --git a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py 
b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
index 76d938d3908492..45f836a2fa3c39 100644
--- a/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
+++ b/lldb/test/API/tools/lldb-dap/locations/TestDAP_locations.py
@@ -19,11 +19,11 @@ def test_locations(self):
 """
 program = self.getBuildArtifact("a.out")
 self.build_and_launch(program)
-source = "main.c"
+source = "main.cpp"
 self.source_path = os.path.join(os.getcwd(), source)
 self.set_source_breakpoints(
 source,
-[line_number(source, "// BREAK HERE")],
+[line_number(source, "break here")],
 )
 self.continue_to_next_stop()
 
@@ -36,5 +36,46 @@ def test_locations(self):
 locals["var1"]["declarationLocationReference"]
 )
 self.assertTrue(loc_var1["success"])
-self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.c"))
-self.assertEqual(loc_var1["body"]["line"], 2)
+
self.assertTrue(loc_var1["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(loc_var1["body"]["line"], 6)
+
+# func_ptr has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ptr"].keys())
+self.assertIn("valueLocationReference", locals["func_ptr"].keys())
+decl_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ptr["success"])
+self.assertTrue(
+decl_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ptr["body"]["line"], 7)
+val_loc_func_ptr = self.dap_server.request_locations(
+locals["func_ptr"]["valueLocationReference"]
+)
+self.assertTrue(val_loc_func_ptr["success"])
+
self.assertTrue(val_loc_func_ptr["body"]["source"]["path"].endswith("main.cpp"))
+self.assertEqual(val_loc_func_ptr["body"]["line"], 3)
+
+# func_ref has both a declaration and a valueLocation
+self.assertIn("declarationLocationReference", 
locals["func_ref"].keys())
+self.assertIn("valueLocationReference", locals["func_ref"].keys())
+decl_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["declarationLocationReference"]
+)
+self.assertTrue(decl_loc_func_ref["success"])
+self.assertTrue(
+decl_loc_func_ref["body"]["source"]["path"].endswith("main.cpp")
+)
+self.assertEqual(decl_loc_func_ref["body"]["line"], 8)
+val_loc_func_ref = self.dap_server.request_locations(
+locals["func_ref"]["valueLocationReference"]
+)
+s

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

2024-09-20 Thread Jacob Lalonde via lldb-commits


https://github.com/Jlalond created 
https://github.com/llvm/llvm-project/pull/109477

This patch adds the support to `Process.cpp` to automatically save off TLS 
sections, either via loading the memory region for the module, or via reading 
`fs_base` via generic register. Then when Minidumps are loaded, we now specify 
we want the dynamic loader to be the `POSIXDYLD` so we can leverage the same 
TLS accessor code as `ProcessELFCore`. Being able to access TLS Data is an 
important step for LLDB generated minidumps to have feature parity with ELF 
Core dumps.

>From 424b200b296df80071adad2c5ed52c93eaa05807 Mon Sep 17 00:00:00 2001
From: Jacob Lalonde 
Date: Mon, 16 Sep 2024 13:02:59 -0700
Subject: [PATCH 1/5] Add Process code to get the fs_base region and the .tdata
 sections. Plus a test

---
 lldb/source/Target/Process.cpp| 67 ++-
 .../TestProcessSaveCoreMinidump.py| 42 
 2 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index aca08972811470..c66103b9443444 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -6528,6 +6528,63 @@ static void AddRegion(const MemoryRegionInfo ®ion, 
bool try_dirty_pages,
 CreateCoreFileMemoryRange(region));
 }
 
+static void AddRegisterSections(Process &process, ThreadSP &thread_sp, 
CoreFileMemoryRanges &ranges, lldb::addr_t range_end) {
+  lldb::RegisterContextSP reg_ctx = thread_sp->GetRegisterContext();
+  if (!reg_ctx)
+return;
+
+  const RegisterInfo *reg_info = 
reg_ctx->GetRegisterInfo(lldb::RegisterKind::eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_TP);
+  if (!reg_info)
+return;
+
+  lldb_private::RegisterValue reg_value;
+  bool success = reg_ctx->ReadRegister(reg_info, reg_value);
+  if (!success)
+return;
+
+  const uint64_t fail_value = UINT64_MAX;
+  bool readSuccess = true;
+  const lldb::addr_t reg_value_addr = reg_value.GetAsUInt64(fail_value, 
&readSuccess);
+  if (!readSuccess || reg_value_addr == fail_value)
+return;
+  
+  MemoryRegionInfo register_region;
+  Status err = process.GetMemoryRegionInfo(reg_value_addr, register_region);
+  if (err.Fail())
+return;
+
+  // We already saved off this truncated stack range.
+  if (register_region.GetRange().GetRangeEnd() == range_end)
+return;
+
+  // We don't need to worry about duplication because the CoreFileMemoryRanges
+  // will unique them
+  AddRegion(register_region, true, ranges);
+}
+
+static void AddModuleThreadLocalSections(Process &process, ThreadSP 
&thread_sp, CoreFileMemoryRanges &ranges, lldb::addr_t range_end) {
+  ModuleList &module_list = process.GetTarget().GetImages();
+  for (size_t idx = 0; idx < module_list.GetSize(); idx++) {
+ModuleSP module_sp = module_list.GetModuleAtIndex(idx);
+if (!module_sp)
+  continue;
+// We want the entire section, so the offset is 0.
+const lldb::addr_t tls_storage_addr = 
thread_sp->GetThreadLocalData(module_sp, 0);
+if (tls_storage_addr == LLDB_INVALID_ADDRESS)
+  continue;
+MemoryRegionInfo tls_storage_region;
+Status err = process.GetMemoryRegionInfo(tls_storage_addr, 
tls_storage_region);
+if (err.Fail())
+  continue;
+
+// We already saved off this truncated stack range.
+if (tls_storage_region.GetRange().GetRangeEnd() == range_end)
+  continue;
+
+AddRegion(tls_storage_region, true, ranges);
+  }
+}
+
 static void SaveOffRegionsWithStackPointers(Process &process,
 const SaveCoreOptions 
&core_options,
 const MemoryRegionInfos ®ions,
@@ -6559,11 +6616,17 @@ static void SaveOffRegionsWithStackPointers(Process 
&process,
   // off in other calls
   sp_region.GetRange().SetRangeBase(stack_head);
   sp_region.GetRange().SetByteSize(stack_size);
-  stack_ends.insert(sp_region.GetRange().GetRangeEnd());
+  const addr_t range_end = sp_region.GetRange().GetRangeEnd();
+  stack_ends.insert(range_end);
   // This will return true if the threadlist the user specified is empty,
   // or contains the thread id from thread_sp.
-  if (core_options.ShouldThreadBeSaved(thread_sp->GetID()))
+  if (core_options.ShouldThreadBeSaved(thread_sp->GetID())) {
 AddRegion(sp_region, try_dirty_pages, ranges);
+// Add the register section if x86_64 and add the module tls data
+// only if the range isn't the same as this truncated stack range.
+AddRegisterSections(process, thread_sp, ranges, range_end);
+AddModuleThreadLocalSections(process, thread_sp, ranges, range_end);
+  }
 }
   }
 }
diff --git 
a/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 
b/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
index ccdb6653cf16f8..454ce8bf387cc5 100644
--- 
a/lldb/test/API/functi

[Lldb-commits] [lldb] 2011cbc - [lldb-dap] Add feature to remember last non-empty expression. (#107485)

2024-09-20 Thread via lldb-commits


Author: cmtice
Date: 2024-09-20T14:04:44-07:00
New Revision: 2011cbcd84102236dd6d58e2079ac676a3403f25

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

LOG: [lldb-dap] Add feature to remember last non-empty expression. (#107485)

Update lldb-dap so if the user just presses return, which sends an empty
expression, it re-evaluates the most recent non-empty
expression/command. Also udpated test to test this case.

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
lldb/test/API/tools/lldb-dap/evaluate/main.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/LLDBUtils.cpp
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py 
b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
index 29548a835c6919..0126d40d86fca2 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
+++ b/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py
@@ -54,13 +54,22 @@ def run_test_evaluate_expressions(
 line_number(source, "// breakpoint 5"),
 line_number(source, "// breakpoint 6"),
 line_number(source, "// breakpoint 7"),
+line_number(source, "// breakpoint 8"),
 ],
 )
 self.continue_to_next_stop()
 
 # Expressions at breakpoint 1, which is in main
 self.assertEvaluate("var1", "20")
+# Empty expression should equate to the previous expression.
+if context == "repl":
+self.assertEvaluate("", "20")
+else:
+self.assertEvaluateFailure("")
 self.assertEvaluate("var2", "21")
+if context == "repl":
+self.assertEvaluate("", "21")
+self.assertEvaluate("", "21")
 self.assertEvaluate("static_int", "42")
 self.assertEvaluate("non_static_int", "43")
 self.assertEvaluate("struct1.foo", "15")
@@ -191,6 +200,15 @@ def run_test_evaluate_expressions(
 self.continue_to_next_stop()
 self.assertEvaluate("my_bool_vec", "size=2")
 
+# Test memory read, especially with 'empty' repeat commands.
+if context == "repl":
+self.continue_to_next_stop()
+self.assertEvaluate("memory read -c 1 &my_ints", ".* 05 .*\n")
+self.assertEvaluate("", ".* 0a .*\n")
+self.assertEvaluate("", ".* 0f .*\n")
+self.assertEvaluate("", ".* 14 .*\n")
+self.assertEvaluate("", ".* 19 .*\n")
+
 @skipIfWindows
 def test_generic_evaluate_expressions(self):
 # Tests context-less expression evaluations

diff  --git a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
index ca27b5ba5ca19d..1c68716e3a6e11 100644
--- a/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-dap/evaluate/main.cpp
@@ -1,5 +1,6 @@
 #include "foo.h"
 
+#include 
 #include 
 #include 
 
@@ -45,5 +46,6 @@ int main(int argc, char const *argv[]) {
   my_bool_vec.push_back(false); // breakpoint 6
   my_bool_vec.push_back(true);  // breakpoint 7
 
-  return 0;
+  uint8_t my_ints[] = {5, 10, 15, 20, 25, 30};
+  return 0; // breakpoint 8
 }

diff  --git a/lldb/tools/lldb-dap/DAP.h b/lldb/tools/lldb-dap/DAP.h
index e28fd593ed74ce..bc2c055e2c56d5 100644
--- a/lldb/tools/lldb-dap/DAP.h
+++ b/lldb/tools/lldb-dap/DAP.h
@@ -205,6 +205,12 @@ struct DAP {
   std::string command_escape_prefix = "`";
   lldb::SBFormat frame_format;
   lldb::SBFormat thread_format;
+  // This is used to allow request_evaluate to handle empty expressions
+  // (ie the user pressed 'return' and expects the previous expression to
+  // repeat). If the previous expression was a command, this string will be
+  // empty; if the previous expression was a variable expression, this string
+  // will contain that expression.
+  std::string last_nonempty_var_expression;
 
   DAP();
   ~DAP();

diff  --git a/lldb/tools/lldb-dap/LLDBUtils.cpp 
b/lldb/tools/lldb-dap/LLDBUtils.cpp
index ff6bea1b23eee8..a74b32609a167b 100644
--- a/lldb/tools/lldb-dap/LLDBUtils.cpp
+++ b/lldb/tools/lldb-dap/LLDBUtils.cpp
@@ -45,7 +45,8 @@ bool RunLLDBCommands(llvm::StringRef prefix,
   // RunTerminateCommands.
   static std::mutex handle_command_mutex;
   std::lock_guard locker(handle_command_mutex);
-  interp.HandleCommand(command.str().c_str(), result);
+  interp.HandleCommand(command.str().c_str(), result,
+   /*add_to_history=*/true);
 }
 
 const bool got_error = !result.Succeeded();

diff  --git a/lldb/tools/lldb-dap/lldb-dap.cpp 
b/lldb/tools/lldb-dap/lldb-dap.cpp
index 2fb86f675b4516..93676d7add239d 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/

[Lldb-commits] [lldb] [lldb-dap] Add feature to remember last non-empty expression. (PR #107485)

2024-09-20 Thread via lldb-commits


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

[Lldb-commits] [lldb] [LLDB][Minidump] Have Minidumps save off and properly read TLS data (PR #109477)

2024-09-20 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)


Changes

This patch adds the support to `Process.cpp` to automatically save off TLS 
sections, either via loading the memory region for the module, or via reading 
`fs_base` via generic register. Then when Minidumps are loaded, we now specify 
we want the dynamic loader to be the `POSIXDYLD` so we can leverage the same 
TLS accessor code as `ProcessELFCore`. Being able to access TLS Data is an 
important step for LLDB generated minidumps to have feature parity with ELF 
Core dumps.

---
Full diff: https://github.com/llvm/llvm-project/pull/109477.diff


7 Files Affected:

- (modified) 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp (+3-2) 
- (modified) lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp (+19) 
- (modified) lldb/source/Plugins/Process/minidump/ProcessMinidump.h (+4-3) 
- (modified) 
lldb/source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.cpp (+16-4) 
- (modified) lldb/source/Target/Process.cpp (+78-3) 
- (modified) 
lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py
 (+74) 
- (modified) lldb/test/API/functionalities/process_save_core_minidump/main.cpp 
(+1) 


``diff
diff --git 
a/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp 
b/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
index 51e4b3e6728f23..38e9a61817ab55 100644
--- a/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
+++ b/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
@@ -115,7 +115,8 @@ void DynamicLoaderPOSIXDYLD::DidAttach() {
   // don't rebase if the module already has a load address
   Target &target = m_process->GetTarget();
   Address addr = obj->GetImageInfoAddress(&target);
-  if (addr.GetLoadAddress(&target) != LLDB_INVALID_ADDRESS)
+  addr_t load_addr = addr.GetLoadAddress(&target);
+  if (load_addr != LLDB_INVALID_ADDRESS)
 rebase_exec = false;
 }
   } else {
@@ -124,7 +125,7 @@ void DynamicLoaderPOSIXDYLD::DidAttach() {
   }
 
   // if the target executable should be re-based
-  if (rebase_exec) {
+  if (rebase_exec || IsCoreFile()) {
 ModuleList module_list;
 
 module_list.Append(executable_sp);
diff --git a/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp 
b/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
index 32ffba763c08e3..2a8f9fe9b9d93d 100644
--- a/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
+++ b/lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
@@ -21,6 +21,7 @@
 #include "lldb/Interpreter/CommandReturnObject.h"
 #include "lldb/Interpreter/OptionArgParser.h"
 #include "lldb/Interpreter/OptionGroupBoolean.h"
+#include "lldb/Target/DynamicLoader.h"
 #include "lldb/Target/JITLoaderList.h"
 #include "lldb/Target/MemoryRegionInfo.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -34,6 +35,7 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Threading.h"
 
+#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
 #include "Plugins/ObjectFile/Placeholder/ObjectFilePlaceholder.h"
 #include "Plugins/Process/Utility/StopInfoMachException.h"
 
@@ -333,6 +335,23 @@ ArchSpec ProcessMinidump::GetArchitecture() {
   return ArchSpec(triple);
 }
 
+DynamicLoader *ProcessMinidump::GetDynamicLoader() {
+  if (m_dyld_up.get() == nullptr)
+m_dyld_up.reset(DynamicLoader::FindPlugin(
+this, DynamicLoaderPOSIXDYLD::GetPluginNameStatic()));
+  return m_dyld_up.get();
+}
+
+DataExtractor ProcessMinidump::GetAuxvData() {
+  std::optional> auxv =
+  m_minidump_parser->GetStream(StreamType::LinuxAuxv);
+  if (!auxv)
+return DataExtractor();
+
+  return DataExtractor(auxv->data(), auxv->size(), ByteOrder::eByteOrderLittle,
+   GetAddressByteSize(), GetAddressByteSize());
+}
+
 void ProcessMinidump::BuildMemoryRegions() {
   if (m_memory_regions)
 return;
diff --git a/lldb/source/Plugins/Process/minidump/ProcessMinidump.h 
b/lldb/source/Plugins/Process/minidump/ProcessMinidump.h
index f2ea0a2b61d14e..332e2637cc7ee7 100644
--- a/lldb/source/Plugins/Process/minidump/ProcessMinidump.h
+++ b/lldb/source/Plugins/Process/minidump/ProcessMinidump.h
@@ -53,11 +53,12 @@ class ProcessMinidump : public PostMortemProcess {
 
   Status DoLoadCore() override;
 
-  DynamicLoader *GetDynamicLoader() override { return nullptr; }
+  // Returns AUXV structure found in the core file
+  lldb_private::DataExtractor GetAuxvData() override;
 
-  llvm::StringRef GetPluginName() override { return GetPluginNameStatic(); }
+  DynamicLoader *GetDynamicLoader() override;
 
-  SystemRuntime *GetSystemRuntime() override { return nullptr; }
+  llvm::StringRef GetPluginName() override { return GetPluginNameStatic(); }
 
   Status DoDestroy() override;
 
diff --git 
a/lldb/source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.cpp 
b/lldb/source/Plugins/Proc

[Lldb-commits] [lldb] [lldb/Interpreter] Propagate `script` output back to command return object (PR #109440)

2024-09-20 Thread Med Ismail Bennani via lldb-commits


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

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


https://github.com/vogelsgesang created 
https://github.com/llvm/llvm-project/pull/109485

The `readMemory` request used the `MemoryRegionInfo` so it could also support 
short reads. Since #106532, this is no longer necessary, as mentioned by 
@labath in a comment on #104317.

We no longer set the `unreadableBytes` in the result. But this is optional, 
anyway, and afaik the VS Code UI would not yet make good use of 
`unreadableBytes`, anyway.

>From 48718649469aae62b2945e7de22cf7280316b757 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Fri, 20 Sep 2024 21:05:54 +
Subject: [PATCH] [lldb-dap] Simplify `readMemory`

The `readMemory` request used the `MemoryRegionInfo` so it could also
support short reads. Since #106532, this is no longer necessary.

We no longer set the `unreadableBytes` in the result. But this is
optional, anyway, and afaik the VS Code UI would not yet make good use
of `unreadableBytes`, anyway.
---
 .../tools/lldb-dap/memory/TestDAP_memory.py   |  5 +-
 lldb/tools/lldb-dap/lldb-dap.cpp  | 69 +--
 2 files changed, 21 insertions(+), 53 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
index 1082541aebcf7c..9c4bb794dccb61 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -93,7 +93,6 @@ def test_readMemory(self):
 
 # We can read the complete string
 mem = self.dap_server.request_readMemory(memref, 0, 5)["body"]
-self.assertEqual(mem["unreadableBytes"], 0)
 self.assertEqual(b64decode(mem["data"]), b"dead\0")
 
 # Use an offset
@@ -101,7 +100,7 @@ def test_readMemory(self):
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
 # Reads of size 0 are successful
-# VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
+# VS Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)
 self.assertEqual(mem["success"], True)
 self.assertEqual(mem["body"]["data"], "")
@@ -109,4 +108,4 @@ def test_readMemory(self):
 # Reads at offset 0x0 fail
 mem = self.dap_server.request_readMemory("0x0", 0, 6)
 self.assertEqual(mem["success"], False)
-self.assertEqual(mem["message"], "Memory region is not readable")
+self.assertEqual(mem["message"], "memory read failed for 0x0")
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 2fb86f675b4516..1ee04f0089179e 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4405,14 +4405,6 @@ void request_readMemory(const llvm::json::Object 
&request) {
   FillResponse(request, response);
   auto *arguments = request.getObject("arguments");
 
-  lldb::SBProcess process = g_dap.target.GetProcess();
-  if (!process.IsValid()) {
-response["success"] = false;
-response["message"] = "No process running";
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-
   llvm::StringRef memoryReference = GetString(arguments, "memoryReference");
   auto addr_opt = DecodeMemoryReference(memoryReference);
   if (!addr_opt.has_value()) {
@@ -4422,57 +4414,34 @@ void request_readMemory(const llvm::json::Object 
&request) {
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  lldb::addr_t addr = *addr_opt;
+  lldb::addr_t addr_int = *addr_opt;
+  addr_int += GetSigned(arguments, "offset", 0);
+  const uint64_t count_requested = GetUnsigned(arguments, "count", 0);
 
-  addr += GetSigned(arguments, "offset", 0);
-  const uint64_t requested_count = GetUnsigned(arguments, "count", 0);
-  lldb::SBMemoryRegionInfo region_info;
-  lldb::SBError memreg_error = process.GetMemoryRegionInfo(addr, region_info);
-  if (memreg_error.Fail()) {
-response["success"] = false;
-EmplaceSafeString(response, "message",
-  "Unable to find memory region: " +
-  std::string(memreg_error.GetCString()));
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-  if (!region_info.IsReadable()) {
+  lldb::SBAddress addr =
+  g_dap.target.ResolveLoadAddress(addr_int);
+
+  // We also need support reading 0 bytes
+  // VS Code sends those requests to check if a `memoryReference`
+  // can be dereferenced.
+  const uint64_t count_read = std::max(count_requested, 1);
+  std::vector buf;
+  buf.resize(count_read);
+  lldb::SBError error;
+  size_t count_result =
+  g_dap.target.ReadMemory(addr, buf.data(), count_read, error);
+  if (error.Fail()) {
 response["success"] = false;
-response.try_emplace("message", "Memory region is not readable");
+EmplaceSafeString(response, "message", error.GetCString());
 g_dap.SendJSON(llvm::json::Value(std::

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

2024-09-20 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Vogelsgesang (vogelsgesang)


Changes

The `readMemory` request used the `MemoryRegionInfo` so it could also support 
short reads. Since #106532, this is no longer necessary, as mentioned 
by @labath in a comment on #104317.

We no longer set the `unreadableBytes` in the result. But this is optional, 
anyway, and afaik the VS Code UI would not yet make good use of 
`unreadableBytes`, anyway.

---
Full diff: https://github.com/llvm/llvm-project/pull/109485.diff


2 Files Affected:

- (modified) lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py (+2-3) 
- (modified) lldb/tools/lldb-dap/lldb-dap.cpp (+19-50) 


``diff
diff --git a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py 
b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
index 1082541aebcf7c..9c4bb794dccb61 100644
--- a/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
+++ b/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py
@@ -93,7 +93,6 @@ def test_readMemory(self):
 
 # We can read the complete string
 mem = self.dap_server.request_readMemory(memref, 0, 5)["body"]
-self.assertEqual(mem["unreadableBytes"], 0)
 self.assertEqual(b64decode(mem["data"]), b"dead\0")
 
 # Use an offset
@@ -101,7 +100,7 @@ def test_readMemory(self):
 self.assertEqual(b64decode(mem["data"]), b"ad\0")
 
 # Reads of size 0 are successful
-# VS-Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
+# VS Code sends those in order to check if a `memoryReference` can 
actually be dereferenced.
 mem = self.dap_server.request_readMemory(memref, 0, 0)
 self.assertEqual(mem["success"], True)
 self.assertEqual(mem["body"]["data"], "")
@@ -109,4 +108,4 @@ def test_readMemory(self):
 # Reads at offset 0x0 fail
 mem = self.dap_server.request_readMemory("0x0", 0, 6)
 self.assertEqual(mem["success"], False)
-self.assertEqual(mem["message"], "Memory region is not readable")
+self.assertEqual(mem["message"], "memory read failed for 0x0")
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 2fb86f675b4516..1ee04f0089179e 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4405,14 +4405,6 @@ void request_readMemory(const llvm::json::Object 
&request) {
   FillResponse(request, response);
   auto *arguments = request.getObject("arguments");
 
-  lldb::SBProcess process = g_dap.target.GetProcess();
-  if (!process.IsValid()) {
-response["success"] = false;
-response["message"] = "No process running";
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-
   llvm::StringRef memoryReference = GetString(arguments, "memoryReference");
   auto addr_opt = DecodeMemoryReference(memoryReference);
   if (!addr_opt.has_value()) {
@@ -4422,57 +4414,34 @@ void request_readMemory(const llvm::json::Object 
&request) {
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  lldb::addr_t addr = *addr_opt;
+  lldb::addr_t addr_int = *addr_opt;
+  addr_int += GetSigned(arguments, "offset", 0);
+  const uint64_t count_requested = GetUnsigned(arguments, "count", 0);
 
-  addr += GetSigned(arguments, "offset", 0);
-  const uint64_t requested_count = GetUnsigned(arguments, "count", 0);
-  lldb::SBMemoryRegionInfo region_info;
-  lldb::SBError memreg_error = process.GetMemoryRegionInfo(addr, region_info);
-  if (memreg_error.Fail()) {
-response["success"] = false;
-EmplaceSafeString(response, "message",
-  "Unable to find memory region: " +
-  std::string(memreg_error.GetCString()));
-g_dap.SendJSON(llvm::json::Value(std::move(response)));
-return;
-  }
-  if (!region_info.IsReadable()) {
+  lldb::SBAddress addr =
+  g_dap.target.ResolveLoadAddress(addr_int);
+
+  // We also need support reading 0 bytes
+  // VS Code sends those requests to check if a `memoryReference`
+  // can be dereferenced.
+  const uint64_t count_read = std::max(count_requested, 1);
+  std::vector buf;
+  buf.resize(count_read);
+  lldb::SBError error;
+  size_t count_result =
+  g_dap.target.ReadMemory(addr, buf.data(), count_read, error);
+  if (error.Fail()) {
 response["success"] = false;
-response.try_emplace("message", "Memory region is not readable");
+EmplaceSafeString(response, "message", error.GetCString());
 g_dap.SendJSON(llvm::json::Value(std::move(response)));
 return;
   }
-  const uint64_t available_count =
-  std::min(requested_count, region_info.GetRegionEnd() - addr);
-  const uint64_t unavailable_count = requested_count - available_count;
-
-  std::vector buf;
-  buf.resize(available_count);
-  if (available_count > 0) {
-lldb::SBError memread_error;
-uint64_t bytes_read =
-process.ReadMemory(addr, buf.data(), available_count, memrea

[Lldb-commits] [lldb] [lldb/Interpreter] Propagate `script` output back to command return object (PR #109440)

2024-09-20 Thread via lldb-commits


jimingham wrote:

Now that successful results show up in the command return object, it's a little 
strange that if the expression fails - a parse error or whatever - that is not 
available in the command result.  It would be more consistent if we did 
SetError on the command result object with the error.  It looks like you could 
capture that and forward it to where the result is made up.
I think we should do that, but if you want to do it as a follow-up that's also 
fine.
I don't have any comments on the code beyond what Jonas added, but there should 
be a test for this.

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

[Lldb-commits] [lldb] [lldb-dap] Support inspecting memory (PR #104317)

2024-09-20 Thread Adrian Vogelsgesang via lldb-commits


vogelsgesang wrote:

Thanks for that thoughtful write-up!

#109485 should address your points

> The method I'd recommend is to call `ReadMemory`

I assume I should prefer `Target::ReadMemory` over `Process::readMemory`, right?

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

[Lldb-commits] [lldb] [lldb-dap] Simplify `readMemory` (PR #109485)

2024-09-20 Thread via lldb-commits


github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 65c57066e099fe7f1357485cd6c4fb068bc82323 
48718649469aae62b2945e7de22cf7280316b757 --extensions cpp -- 
lldb/tools/lldb-dap/lldb-dap.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/tools/lldb-dap/lldb-dap.cpp b/lldb/tools/lldb-dap/lldb-dap.cpp
index 1ee04f0089..ca742e8cee 100644
--- a/lldb/tools/lldb-dap/lldb-dap.cpp
+++ b/lldb/tools/lldb-dap/lldb-dap.cpp
@@ -4418,8 +4418,7 @@ void request_readMemory(const llvm::json::Object 
&request) {
   addr_int += GetSigned(arguments, "offset", 0);
   const uint64_t count_requested = GetUnsigned(arguments, "count", 0);
 
-  lldb::SBAddress addr =
-  g_dap.target.ResolveLoadAddress(addr_int);
+  lldb::SBAddress addr = g_dap.target.ResolveLoadAddress(addr_int);
 
   // We also need support reading 0 bytes
   // VS Code sends those requests to check if a `memoryReference`

``




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

1 2 >

1 - 100 of 174 matches

Mail list logo