[Lldb-commits] [lldb] 5a12f28 - LLVM_FALLTHROUGH => [[fallthrough]]. NFC

2024-04-25 Thread Fangrui Song via lldb-commits

Author: Fangrui Song
Date: 2024-04-25T17:50:59-07:00
New Revision: 5a12f2867a167bbe11099150f3cb6b6cb77d767c

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

LOG: LLVM_FALLTHROUGH => [[fallthrough]]. NFC

Added: 


Modified: 
clang-tools-extra/clangd/CodeCompletionStrings.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
llvm/include/llvm/IR/GenericConvergenceVerifierImpl.h
llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
llvm/lib/Support/regcomp.c
llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
llvm/lib/Target/SystemZ/SystemZISelLowering.cpp
llvm/utils/TableGen/DXILEmitter.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeCompletionStrings.cpp 
b/clang-tools-extra/clangd/CodeCompletionStrings.cpp
index 2075e5965f181e..9b4442b0bb76fd 100644
--- a/clang-tools-extra/clangd/CodeCompletionStrings.cpp
+++ b/clang-tools-extra/clangd/CodeCompletionStrings.cpp
@@ -253,7 +253,7 @@ void getSignature(const CodeCompletionString , 
std::string *Signature,
   if (!IncludeFunctionArguments &&
   ResultKind == CodeCompletionResult::RK_Declaration)
 TruncateSnippetAt.emplace(Snippet->size());
-  LLVM_FALLTHROUGH;
+  [[fallthrough]];
 case CodeCompletionString::CK_RightParen:
 case CodeCompletionString::CK_LeftBracket:
 case CodeCompletionString::CK_RightBracket:

diff  --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index d3fc487aed4333..9409497f1c81ba 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -1869,15 +1869,15 @@ 
AppleObjCRuntimeV2::DynamicClassInfoExtractor::ComputeHelper(
   if (loader->IsFullyInitialized()) {
 switch (exe_ctx.GetTargetRef().GetDynamicClassInfoHelper()) {
 case eDynamicClassInfoHelperAuto:
-  LLVM_FALLTHROUGH;
+  [[fallthrough]];
 case eDynamicClassInfoHelperGetRealizedClassList:
   if (m_runtime.m_has_objc_getRealizedClassList_trylock)
 return 
DynamicClassInfoExtractor::objc_getRealizedClassList_trylock;
-  LLVM_FALLTHROUGH;
+  [[fallthrough]];
 case eDynamicClassInfoHelperCopyRealizedClassList:
   if (m_runtime.m_has_objc_copyRealizedClassList)
 return DynamicClassInfoExtractor::objc_copyRealizedClassList;
-  LLVM_FALLTHROUGH;
+  [[fallthrough]];
 case eDynamicClassInfoHelperRealizedClassesStruct:
   return DynamicClassInfoExtractor::gdb_objc_realized_classes;
 }

diff  --git a/llvm/include/llvm/IR/GenericConvergenceVerifierImpl.h 
b/llvm/include/llvm/IR/GenericConvergenceVerifierImpl.h
index a3ebde709ae6e1..7525c9eb758bef 100644
--- a/llvm/include/llvm/IR/GenericConvergenceVerifierImpl.h
+++ b/llvm/include/llvm/IR/GenericConvergenceVerifierImpl.h
@@ -76,7 +76,7 @@ void GenericConvergenceVerifier::visit(const 
InstructionT ) {
   "Entry intrinsic cannot be preceded by a convergent operation in the 
"
   "same basic block.",
   {Context.print()});
-LLVM_FALLTHROUGH;
+[[fallthrough]];
   case CONV_ANCHOR:
 Check(!TokenDef,
   "Entry or anchor intrinsic cannot have a convergencectrl token "

diff  --git a/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp 
b/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
index 8cf392ab0567e5..d7b0c9aa166735 100644
--- a/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
@@ -2223,7 +2223,7 @@ bool IRTranslator::translateKnownIntrinsic(const CallInst 
, Intrinsic::ID ID,
 // addresses. We can treat it like a normal dbg_value intrinsic here; to
 // benefit from the full analysis of stack/SSA locations, GlobalISel would
 // need to register for and use the AssignmentTrackingAnalysis pass.
-LLVM_FALLTHROUGH;
+[[fallthrough]];
   case Intrinsic::dbg_value: {
 // This form of DBG_VALUE is target-independent.
 const DbgValueInst  = cast(CI);

diff  --git a/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp 
b/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
index aefedd060f897d..ef9f7833551905 100644
--- a/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
@@ -1424,7 +1424,7 @@ bool FastISel::selectIntrinsicCall(const IntrinsicInst 
*II) {
 // happened (such as an optimised function being 

[Lldb-commits] [lldb] [lldb-dap] Report exit status message in lldb-dap, same as lldb cli (PR #89405)

2024-04-25 Thread Paul Kirth via lldb-commits

ilovepi wrote:

Hi, I think we're seeing some breakage in our CI after this patch.

We see the lldb-api :: tools/lldb-dap/console/TestDAP_console.py test failing.

https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8749666263730294449/overview

```
 TEST 'lldb-api :: 
tools/lldb-dap/console/TestDAP_console.py' FAILED 
Script:
--
/b/s/w/ir/x/w/lldb_install/python3/bin/python3 
/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS 
--env ARCHIVER=/b/s/w/ir/x/w/cipd/bin/llvm-ar --env 
OBJCOPY=/b/s/w/ir/x/w/cipd/bin/llvm-objcopy --env 
LLVM_LIBS_DIR=/b/s/w/ir/x/w/llvm_build/./lib --env 
LLVM_INCLUDE_DIR=/b/s/w/ir/x/w/llvm_build/include --env 
LLVM_TOOLS_DIR=/b/s/w/ir/x/w/llvm_build/./bin --libcxx-include-dir 
/b/s/w/ir/x/w/llvm_build/include/c++/v1 --libcxx-include-target-dir 
/b/s/w/ir/x/w/llvm_build/include/aarch64-unknown-linux-gnu/c++/v1 
--libcxx-library-dir /b/s/w/ir/x/w/llvm_build/./lib/aarch64-unknown-linux-gnu 
--arch aarch64 --build-dir /b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-lldb/lldb-api 
--clang-module-cache-dir 
/b/s/w/ir/x/w/llvm_build/lldb-test-build.noindex/module-cache-clang/lldb-api 
--executable /b/s/w/ir/x/w/llvm_build/./bin/lldb --compiler 
/b/s/w/ir/x/w/llvm_build/./bin/clang --dsymutil 
/b/s/w/ir/x/w/llvm_build/./bin/dsymutil --llvm-tools-dir 
/b/s/w/ir/x/w/llvm_build/./bin --lldb-libs-dir /b/s/w/ir/x/w/llvm_build/./lib 
--skip-category=pexpect 
/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/tools/lldb-dap/console -p 
TestDAP_console.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 19.0.0git (https://llvm.googlesource.com/a/llvm-project revision 
5fb59e744783cf686e6a355c8331eeab90678c00)
  clang revision 5fb59e744783cf686e6a355c8331eeab90678c00
  llvm revision 5fb59e744783cf686e6a355c8331eeab90678c00
Skipping the following test categories: ['pexpect', 'dsym', 'gmodules', 
'debugserver', 'objc']

--
Command Output (stderr):
--
Traceback (most recent call last):
  File "/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/dotest.py", line 8, in 

lldbsuite.test.run_suite()
  File 
"/b/s/w/ir/x/w/llvm-llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 1039, in run_suite
visit("Test", dirpath, filenames)
  File 
"/b/s/w/ir/x/w/llvm-llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 700, in visit
visit_file(dir, name)
  File 
"/b/s/w/ir/x/w/llvm-llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py",
 line 643, in visit_file
module = __import__(base)
 
  File 
"/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py",
 line 7, in 
import psutil
ModuleNotFoundError: No module named 'psutil'

--
```
would you mind taking a look. CC: @mysterymath since he's the most familiar w/ 
our lldb build

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


[Lldb-commits] [lldb] [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (PR #90140)

2024-04-25 Thread Jason Molenda via lldb-commits

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


[Lldb-commits] [lldb] bb2b04c - [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (#90140)

2024-04-25 Thread via lldb-commits

Author: Jason Molenda
Date: 2024-04-25T16:42:47-07:00
New Revision: bb2b04c73332f017955115fedb94790dac3608b9

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

LOG: [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (#90140)

Jonas upstreamed recognition of DW_TAG_LLVM_ptrauth_type
https://reviews.llvm.org/D130215 but it isn't recognized as a type
qualifier tag in DWARFASTParserClang::ParseTypeFromDWARF.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 41d81fbcf1b087..12dafd3f5d5d51 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -495,6 +495,7 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const 
SymbolContext ,
   case DW_TAG_const_type:
   case DW_TAG_restrict_type:
   case DW_TAG_volatile_type:
+  case DW_TAG_LLVM_ptrauth_type:
   case DW_TAG_atomic_type:
   case DW_TAG_unspecified_type: {
 type_sp = ParseTypeModifier(sc, die, attrs);



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


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jason Molenda via lldb-commits

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


[Lldb-commits] [lldb] eb7dc99 - [lldb] Add SBValue::GetValueAsAddress API (#90144)

2024-04-25 Thread via lldb-commits

Author: Jason Molenda
Date: 2024-04-25T16:42:33-07:00
New Revision: eb7dc991841489e2f8f18467705944c9136b06d2

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

LOG: [lldb] Add SBValue::GetValueAsAddress API (#90144)

I previously added this API via https://reviews.llvm.org/D142792 in
2023, along with changes to the ValueObject class to treat pointer types
as addresses, and to annotate those ValueObjects with the original
uint64_t byte sequence AND the name of the symbol once stripped, if that
points to a symbol.

I did this unconditionally for all pointer type ValueObjects, and it
caused several regressions in the Objective-C data formatters which have
a ValueObject of an object, it has the address of its class -- but with
ObjC, sometimes it is a "tagged pointer" which is metadata, not an
actual pointer. (e.g. a small NSInteger value is stored entirely in the
tagged pointer, instead of a separate object) Treating these
not-addresses as addresses -- clearing the non-addressable-bits -- is
invalid.

The original version of this patch we're using downstream only does this
bits clearing for pointer types that are specifically decorated with the
pointerauth typequal, but not all of those clang changes are upstreamed
to github main yet, so I tried this simpler approach and hit the tagged
pointer issue and bailed on the whole patch.

This patch, however, is simply adding SBValue::GetValueAsAddress so
script writers who know that an SBValue has an address in memory, can
strip off any metadata. It's an important API to have for script writers
when AArch64 ptrauth is in use, so I'm going to put this part of the
patch back on github main now until we can get the rest of that original
patch upstreamed.

Added: 
lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile

lldb/test/API/clear-sbvalue-nonaddressable-bits/TestClearSBValueNonAddressableBits.py
lldb/test/API/clear-sbvalue-nonaddressable-bits/main.c

Modified: 
lldb/bindings/interface/SBValueDocstrings.i
lldb/include/lldb/API/SBValue.h
lldb/source/API/SBValue.cpp

Removed: 




diff  --git a/lldb/bindings/interface/SBValueDocstrings.i 
b/lldb/bindings/interface/SBValueDocstrings.i
index 6bab923e8b35a6..59fa807f5ec95c 100644
--- a/lldb/bindings/interface/SBValueDocstrings.i
+++ b/lldb/bindings/interface/SBValueDocstrings.i
@@ -135,6 +135,26 @@ linked list."
 %feature("docstring", "Expands nested expressions like .a->b[0].c[1]->d."
 ) lldb::SBValue::GetValueForExpressionPath;
 
+%feature("docstring", "
+  Return the value as an address.  On failure, LLDB_INVALID_ADDRESS
+  will be returned.  On architectures like AArch64, where the
+  top (unaddressable) bits can be used for authentication,
+  memory tagging, or top byte ignore,  this method will return
+  the value with those top bits cleared.
+
+  GetValueAsUnsigned returns the actual value, with the
+  authentication/Top Byte Ignore/Memory Tagging Extension bits.
+
+  Calling this on a random value which is not a pointer is
+  incorrect.  Call GetType().IsPointerType() if in doubt.
+
+  An SB API program may want to show both the literal byte value
+  and the address it refers to in memory.  These two SBValue
+  methods allow SB API writers to behave appropriately for their
+  interface."
+) lldb::SBValue::GetValueAsAddress;
+
+
 %feature("doctstring", "
 Returns the number for children.
 

diff  --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index 67f55ce7da2877..8f4c4fd56dfb18 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -68,6 +68,8 @@ class LLDB_API SBValue {
 
   uint64_t GetValueAsUnsigned(uint64_t fail_value = 0);
 
+  lldb::addr_t GetValueAsAddress();
+
   ValueType GetValueType();
 
   // If you call this on a newly created ValueObject, it will always return

diff  --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index 94a8f3ea319e89..c53ec5a7464829 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -909,6 +909,25 @@ uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value) {
   return fail_value;
 }
 
+lldb::addr_t SBValue::GetValueAsAddress() {
+  addr_t fail_value = LLDB_INVALID_ADDRESS;
+  ValueLocker locker;
+  lldb::ValueObjectSP value_sp(GetSP(locker));
+  if (value_sp) {
+bool success = true;
+uint64_t ret_val = fail_value;
+ret_val = value_sp->GetValueAsUnsigned(fail_value, );
+if (!success)
+  return fail_value;
+ProcessSP process_sp = m_opaque_sp->GetProcessSP();
+if (!process_sp)
+  return ret_val;
+return process_sp->FixDataAddress(ret_val);
+  }
+
+  return fail_value;
+}
+
 bool SBValue::MightHaveChildren() {
   LLDB_INSTRUMENT_VA(this);
 


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/90144

>From 3b66943d9c49fd5e71c2eb136b5bb3311e932bbc Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 25 Apr 2024 15:51:44 -0700
Subject: [PATCH 1/2] [lldb] Add SBValue::GetValueAsAddress API

I previously added this API via https://reviews.llvm.org/D142792
in 2023, along with changes to the ValueObject class to treat
pointer types as addresses, and to annotate those ValueObjects
with the original uint64_t byte sequence AND the name of the
symbol once stripped, if that points to a symbol.

I did this unconditionally for all pointer type ValueObjects, and
it caused several regressions in the Objective-C data formatters
which have a ValueObject of an object, it has the address of its
class -- but with ObjC, sometimes it is a "tagged pointer" which
is metadata, not an actual pointer.  (e.g. a small NSInteger value
is stored entirely in the tagged pointer, instead of a separate
object)  Treating these not-addresses as addresses -- clearing the
non-addressable-bits -- is invalid.

The original version of this patch we're using downstream only
does this bits clearing for pointer types that are specifically
decorated with the pointerauth typequal, but not all of those
clang changes are upstreamed to github main yet, so I tried this
simpler approach and hit the tagged pointer issue and bailed on
the whole patch.

This patch, however, is simply adding SBValue::GetValueAsAddress
so script writers who know that an SBValue has an address in
memory, can strip off any metadata.  It's an important API to have
for script writers when AArch64 ptrauth is in use, so I'm
going to put this part of the patch back on github main now until
we can get the rest of that original patch upstreamed.
---
 lldb/bindings/interface/SBValueDocstrings.i   | 20 +++
 lldb/include/lldb/API/SBValue.h   |  2 +
 lldb/source/API/SBValue.cpp   | 20 +++
 .../Makefile  |  3 +
 .../TestClearSBValueNonAddressableBits.py | 60 +++
 .../clear-sbvalue-nonaddressable-bits/main.c  | 27 +
 6 files changed, 132 insertions(+)
 create mode 100644 lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile
 create mode 100644 
lldb/test/API/clear-sbvalue-nonaddressable-bits/TestClearSBValueNonAddressableBits.py
 create mode 100644 lldb/test/API/clear-sbvalue-nonaddressable-bits/main.c

diff --git a/lldb/bindings/interface/SBValueDocstrings.i 
b/lldb/bindings/interface/SBValueDocstrings.i
index 6bab923e8b35a6..59fa807f5ec95c 100644
--- a/lldb/bindings/interface/SBValueDocstrings.i
+++ b/lldb/bindings/interface/SBValueDocstrings.i
@@ -135,6 +135,26 @@ linked list."
 %feature("docstring", "Expands nested expressions like .a->b[0].c[1]->d."
 ) lldb::SBValue::GetValueForExpressionPath;
 
+%feature("docstring", "
+  Return the value as an address.  On failure, LLDB_INVALID_ADDRESS
+  will be returned.  On architectures like AArch64, where the
+  top (unaddressable) bits can be used for authentication,
+  memory tagging, or top byte ignore,  this method will return
+  the value with those top bits cleared.
+
+  GetValueAsUnsigned returns the actual value, with the
+  authentication/Top Byte Ignore/Memory Tagging Extension bits.
+
+  Calling this on a random value which is not a pointer is
+  incorrect.  Call GetType().IsPointerType() if in doubt.
+
+  An SB API program may want to show both the literal byte value
+  and the address it refers to in memory.  These two SBValue
+  methods allow SB API writers to behave appropriately for their
+  interface."
+) lldb::SBValue::GetValueAsAddress;
+
+
 %feature("doctstring", "
 Returns the number for children.
 
diff --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index bbcccaab51aaee..6fac0961910540 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -68,6 +68,8 @@ class LLDB_API SBValue {
 
   uint64_t GetValueAsUnsigned(uint64_t fail_value = 0);
 
+  lldb::addr_t GetValueAsAddress();
+
   ValueType GetValueType();
 
   // If you call this on a newly created ValueObject, it will always return
diff --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index 94a8f3ea319e89..c8b664c86ec2d9 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -909,6 +909,26 @@ uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value) {
   return fail_value;
 }
 
+lldb::addr_t SBValue::GetValueAsAddress() {
+  addr_t fail_value = LLDB_INVALID_ADDRESS;
+  ValueLocker locker;
+  lldb::ValueObjectSP value_sp(GetSP(locker));
+  if (value_sp) {
+bool success = true;
+uint64_t ret_val = fail_value;
+ret_val = value_sp->GetValueAsUnsigned(fail_value, );
+if (!success) {
+  return fail_value;
+}
+ProcessSP process_sp = m_opaque_sp->GetProcessSP();
+if (!process_sp)
+  return ret_val;
+   

[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

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

LGTM with the formatting and braces fixed.

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


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -909,6 +909,26 @@ uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value) {
   return fail_value;
 }
 
+lldb::addr_t SBValue::GetValueAsAddress() {
+  addr_t fail_value = LLDB_INVALID_ADDRESS;
+  ValueLocker locker;
+  lldb::ValueObjectSP value_sp(GetSP(locker));
+  if (value_sp) {
+bool success = true;
+uint64_t ret_val = fail_value;
+ret_val = value_sp->GetValueAsUnsigned(fail_value, );
+if (!success) {
+  return fail_value;
+}

JDevlieghere wrote:

No braces

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


[Lldb-commits] [lldb] [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (PR #90140)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

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


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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits

jimingham wrote:

> Hi @jimingham ,
> 
> I have updated the code. Now we have `Add` and `Remove` (with tokens as you 
> suggested). `Set` clears everything then add the given one (also returns a 
> token).
> 
> Thread-safety is done through a `std::lock_guard`. This 
> is consistent with some of the other functions/fields.
> 
> Didn't understand one of your comment about "one destroy callback can 
> add/remove others" and how that relates to the code. See my reply in the 
> above.
> 
> Another thing I am not sure is, in python API test, how do I make concurrent 
> calls to these APIs. Do you know if this should be tested (e.g. if other 
> existing functions has similar tests)? If the answer is "yes", do you happen 
> to know what existing test I can see as examples?
> 
> Thanks for your reviews so far. Hope this PR is getting better as we converse.
> 
> Best, Roy

I don't think it's necessary to try to test concurrency.  That tends to be very 
hard to write a stable test that you know actually tests concurrent access.  
Those end up being more trouble than they are worth.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -321,8 +321,15 @@ class LLDB_API SBDebugger {
 
   void SetLoggingCallback(lldb::LogOutputCallback log_callback, void *baton);
 
-  void SetDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
-  void *baton);
+  lldb::SBDebuggerDestroyCallbackToken
+  AddDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
+ void *baton);
+
+  lldb::SBDebuggerDestroyCallbackToken
+  SetDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,

jimingham wrote:

This is also deprecated.  I'd add the same comment here, and use the 
LLDB_DEPRECATED_IN macro to mark it formally.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();

jimingham wrote:

I meant the former.  You could have added two Destroy callbacks, but then 
during the execution of the first one, the code figures out that it has already 
done the job the second one was intended to do, so the first Destroy callback 
removed the second one on the way out to keep the work from getting done twice.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -1686,13 +1686,33 @@ void 
SBDebugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   }
 }
 
-void SBDebugger::SetDestroyCallback(
-lldb::SBDebuggerDestroyCallback destroy_callback, void *baton) {
+lldb::SBDebuggerDestroyCallbackToken
+SBDebugger::AddDestroyCallback(lldb::SBDebuggerDestroyCallback 
destroy_callback, void *baton) {
+  LLDB_INSTRUMENT_VA(this, destroy_callback, baton);
+  if (m_opaque_sp) {
+return m_opaque_sp->AddDestroyCallback(
+destroy_callback, baton);
+  }
+  return -1;

jimingham wrote:

It's better to make an LLDB_INVALID_DESTROY_TOKEN and use that than have a 
magical -1 floating around in code.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -568,10 +569,22 @@ class Debugger : public 
std::enable_shared_from_this,
 
   static void ReportSymbolChange(const ModuleSpec _spec);
 
-  void
+  /// DEPRECATED. Use AddDestroyCallback and RemoveDestroyCallback instead.
+  /// Clear all previously added callbacks and only add the given one.

jimingham wrote:

I would give a reason for the deprecation, like:

DEPRECATED: We used to only support one Destroy callback.  Now that we support 
Add and Remove, you should only remove Destroy callbacks that you Add-ed.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -121,6 +121,7 @@ typedef struct type256 { uint64_t x[4]; } type256;
 using ValueObjectProviderTy =
 std::function;
 
+typedef int DebuggerDestroyCallbackToken;

jimingham wrote:

There's no need to make separate lldb_private & SB versions of the 
CallbackToken.  Since this is intended to be a public type (it shows up in the 
SB API) you can put it in the lldb namespace - in lldb-types.h, and then both 
the SB API's and the lldb_private one can use that.

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


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread via lldb-commits

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
5ac744d72ad2a8d04e0ae869c4e30558dd8058e3...3b66943d9c49fd5e71c2eb136b5bb3311e932bbc
 
lldb/test/API/clear-sbvalue-nonaddressable-bits/TestClearSBValueNonAddressableBits.py
``





View the diff from darker here.


``diff
--- TestClearSBValueNonAddressableBits.py   2024-04-25 22:59:00.00 +
+++ TestClearSBValueNonAddressableBits.py   2024-04-25 23:02:15.672739 +
@@ -5,11 +5,10 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
 
 class TestClearSBValueNonAddressableBits(TestBase):
-
 NO_DEBUG_INFO_TESTCASE = True
 
 # On AArch64 systems, the top bits that are not used for
 # addressing may be used for TBI, MTE, and/or pointer
 # authentication.

``




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


[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

I previously added this API via https://reviews.llvm.org/D142792 in 2023, along 
with changes to the ValueObject class to treat pointer types as addresses, and 
to annotate those ValueObjects with the original uint64_t byte sequence AND the 
name of the symbol once stripped, if that points to a symbol.

I did this unconditionally for all pointer type ValueObjects, and it caused 
several regressions in the Objective-C data formatters which have a ValueObject 
of an object, it has the address of its class -- but with ObjC, sometimes it is 
a "tagged pointer" which is metadata, not an actual pointer.  (e.g. a small 
NSInteger value is stored entirely in the tagged pointer, instead of a separate 
object)  Treating these not-addresses as addresses -- clearing the 
non-addressable-bits -- is invalid.

The original version of this patch we're using downstream only does this bits 
clearing for pointer types that are specifically decorated with the pointerauth 
typequal, but not all of those clang changes are upstreamed to github main yet, 
so I tried this simpler approach and hit the tagged pointer issue and bailed on 
the whole patch.

This patch, however, is simply adding SBValue::GetValueAsAddress so script 
writers who know that an SBValue has an address in memory, can strip off any 
metadata.  It's an important API to have for script writers when AArch64 
ptrauth is in use, so I'm going to put this part of the patch back on github 
main now until we can get the rest of that original patch upstreamed.

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


6 Files Affected:

- (modified) lldb/bindings/interface/SBValueDocstrings.i (+20) 
- (modified) lldb/include/lldb/API/SBValue.h (+2) 
- (modified) lldb/source/API/SBValue.cpp (+20) 
- (added) lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile (+3) 
- (added) 
lldb/test/API/clear-sbvalue-nonaddressable-bits/TestClearSBValueNonAddressableBits.py
 (+60) 
- (added) lldb/test/API/clear-sbvalue-nonaddressable-bits/main.c (+27) 


``diff
diff --git a/lldb/bindings/interface/SBValueDocstrings.i 
b/lldb/bindings/interface/SBValueDocstrings.i
index 6bab923e8b35a6..59fa807f5ec95c 100644
--- a/lldb/bindings/interface/SBValueDocstrings.i
+++ b/lldb/bindings/interface/SBValueDocstrings.i
@@ -135,6 +135,26 @@ linked list."
 %feature("docstring", "Expands nested expressions like .a->b[0].c[1]->d."
 ) lldb::SBValue::GetValueForExpressionPath;
 
+%feature("docstring", "
+  Return the value as an address.  On failure, LLDB_INVALID_ADDRESS
+  will be returned.  On architectures like AArch64, where the
+  top (unaddressable) bits can be used for authentication,
+  memory tagging, or top byte ignore,  this method will return
+  the value with those top bits cleared.
+
+  GetValueAsUnsigned returns the actual value, with the
+  authentication/Top Byte Ignore/Memory Tagging Extension bits.
+
+  Calling this on a random value which is not a pointer is
+  incorrect.  Call GetType().IsPointerType() if in doubt.
+
+  An SB API program may want to show both the literal byte value
+  and the address it refers to in memory.  These two SBValue
+  methods allow SB API writers to behave appropriately for their
+  interface."
+) lldb::SBValue::GetValueAsAddress;
+
+
 %feature("doctstring", "
 Returns the number for children.
 
diff --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index bbcccaab51aaee..6fac0961910540 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -68,6 +68,8 @@ class LLDB_API SBValue {
 
   uint64_t GetValueAsUnsigned(uint64_t fail_value = 0);
 
+  lldb::addr_t GetValueAsAddress();
+
   ValueType GetValueType();
 
   // If you call this on a newly created ValueObject, it will always return
diff --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index 94a8f3ea319e89..c8b664c86ec2d9 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -909,6 +909,26 @@ uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value) {
   return fail_value;
 }
 
+lldb::addr_t SBValue::GetValueAsAddress() {
+  addr_t fail_value = LLDB_INVALID_ADDRESS;
+  ValueLocker locker;
+  lldb::ValueObjectSP value_sp(GetSP(locker));
+  if (value_sp) {
+bool success = true;
+uint64_t ret_val = fail_value;
+ret_val = value_sp->GetValueAsUnsigned(fail_value, );
+if (!success) {
+  return fail_value;
+}
+ProcessSP process_sp = m_opaque_sp->GetProcessSP();
+if (!process_sp)
+  return ret_val;
+return process_sp->FixDataAddress(ret_val);
+  }
+
+  return fail_value;
+}
+
 bool SBValue::MightHaveChildren() {
   LLDB_INSTRUMENT_VA(this);
 
diff --git a/lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile 
b/lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile
new file mode 100644
index 

[Lldb-commits] [lldb] [lldb] Add SBValue::GetValueAsAddress API (PR #90144)

2024-04-25 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/90144

I previously added this API via https://reviews.llvm.org/D142792 in 2023, along 
with changes to the ValueObject class to treat pointer types as addresses, and 
to annotate those ValueObjects with the original uint64_t byte sequence AND the 
name of the symbol once stripped, if that points to a symbol.

I did this unconditionally for all pointer type ValueObjects, and it caused 
several regressions in the Objective-C data formatters which have a ValueObject 
of an object, it has the address of its class -- but with ObjC, sometimes it is 
a "tagged pointer" which is metadata, not an actual pointer.  (e.g. a small 
NSInteger value is stored entirely in the tagged pointer, instead of a separate 
object)  Treating these not-addresses as addresses -- clearing the 
non-addressable-bits -- is invalid.

The original version of this patch we're using downstream only does this bits 
clearing for pointer types that are specifically decorated with the pointerauth 
typequal, but not all of those clang changes are upstreamed to github main yet, 
so I tried this simpler approach and hit the tagged pointer issue and bailed on 
the whole patch.

This patch, however, is simply adding SBValue::GetValueAsAddress so script 
writers who know that an SBValue has an address in memory, can strip off any 
metadata.  It's an important API to have for script writers when AArch64 
ptrauth is in use, so I'm going to put this part of the patch back on github 
main now until we can get the rest of that original patch upstreamed.

>From 3b66943d9c49fd5e71c2eb136b5bb3311e932bbc Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 25 Apr 2024 15:51:44 -0700
Subject: [PATCH] [lldb] Add SBValue::GetValueAsAddress API

I previously added this API via https://reviews.llvm.org/D142792
in 2023, along with changes to the ValueObject class to treat
pointer types as addresses, and to annotate those ValueObjects
with the original uint64_t byte sequence AND the name of the
symbol once stripped, if that points to a symbol.

I did this unconditionally for all pointer type ValueObjects, and
it caused several regressions in the Objective-C data formatters
which have a ValueObject of an object, it has the address of its
class -- but with ObjC, sometimes it is a "tagged pointer" which
is metadata, not an actual pointer.  (e.g. a small NSInteger value
is stored entirely in the tagged pointer, instead of a separate
object)  Treating these not-addresses as addresses -- clearing the
non-addressable-bits -- is invalid.

The original version of this patch we're using downstream only
does this bits clearing for pointer types that are specifically
decorated with the pointerauth typequal, but not all of those
clang changes are upstreamed to github main yet, so I tried this
simpler approach and hit the tagged pointer issue and bailed on
the whole patch.

This patch, however, is simply adding SBValue::GetValueAsAddress
so script writers who know that an SBValue has an address in
memory, can strip off any metadata.  It's an important API to have
for script writers when AArch64 ptrauth is in use, so I'm
going to put this part of the patch back on github main now until
we can get the rest of that original patch upstreamed.
---
 lldb/bindings/interface/SBValueDocstrings.i   | 20 +++
 lldb/include/lldb/API/SBValue.h   |  2 +
 lldb/source/API/SBValue.cpp   | 20 +++
 .../Makefile  |  3 +
 .../TestClearSBValueNonAddressableBits.py | 60 +++
 .../clear-sbvalue-nonaddressable-bits/main.c  | 27 +
 6 files changed, 132 insertions(+)
 create mode 100644 lldb/test/API/clear-sbvalue-nonaddressable-bits/Makefile
 create mode 100644 
lldb/test/API/clear-sbvalue-nonaddressable-bits/TestClearSBValueNonAddressableBits.py
 create mode 100644 lldb/test/API/clear-sbvalue-nonaddressable-bits/main.c

diff --git a/lldb/bindings/interface/SBValueDocstrings.i 
b/lldb/bindings/interface/SBValueDocstrings.i
index 6bab923e8b35a6..59fa807f5ec95c 100644
--- a/lldb/bindings/interface/SBValueDocstrings.i
+++ b/lldb/bindings/interface/SBValueDocstrings.i
@@ -135,6 +135,26 @@ linked list."
 %feature("docstring", "Expands nested expressions like .a->b[0].c[1]->d."
 ) lldb::SBValue::GetValueForExpressionPath;
 
+%feature("docstring", "
+  Return the value as an address.  On failure, LLDB_INVALID_ADDRESS
+  will be returned.  On architectures like AArch64, where the
+  top (unaddressable) bits can be used for authentication,
+  memory tagging, or top byte ignore,  this method will return
+  the value with those top bits cleared.
+
+  GetValueAsUnsigned returns the actual value, with the
+  authentication/Top Byte Ignore/Memory Tagging Extension bits.
+
+  Calling this on a random value which is not a pointer is
+  incorrect.  Call GetType().IsPointerType() if in doubt.
+
+  An SB 

[Lldb-commits] [lldb] [lldb] Fix typo in CumulativeSystemTimeIsValid check (PR #89680)

2024-04-25 Thread Marc Auberer via lldb-commits

https://github.com/marcauberer updated 
https://github.com/llvm/llvm-project/pull/89680

>From efa805079552cf8f247a499d9b26cfc0ff03db72 Mon Sep 17 00:00:00 2001
From: Marc Auberer 
Date: Tue, 23 Apr 2024 00:05:53 +0200
Subject: [PATCH 1/2] [lldb] Fix typo in CumulativeSystemTimeIsValid check

---
 lldb/include/lldb/Utility/ProcessInfo.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Utility/ProcessInfo.h 
b/lldb/include/lldb/Utility/ProcessInfo.h
index e9fe71e1b851d1..54ac000dc7fc28 100644
--- a/lldb/include/lldb/Utility/ProcessInfo.h
+++ b/lldb/include/lldb/Utility/ProcessInfo.h
@@ -234,7 +234,7 @@ class ProcessInstanceInfo : public ProcessInfo {
 
   bool CumulativeSystemTimeIsValid() const {
 return m_cumulative_system_time.tv_sec > 0 ||
-   m_cumulative_system_time.tv_sec > 0;
+   m_cumulative_system_time.tv_usec > 0;
   }
 
   void Dump(Stream , UserIDResolver ) const;

>From c028b104a45b70fb68a3aba79a6d78521cdd593c Mon Sep 17 00:00:00 2001
From: Marc Auberer 
Date: Fri, 26 Apr 2024 00:58:40 +0200
Subject: [PATCH 2/2] Add tests for Cumulative[User|System]TimeIsValid

---
 lldb/unittests/Host/HostTest.cpp | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lldb/unittests/Host/HostTest.cpp b/lldb/unittests/Host/HostTest.cpp
index 5e01a6835c03dc..a1d8a3b7f485a3 100644
--- a/lldb/unittests/Host/HostTest.cpp
+++ b/lldb/unittests/Host/HostTest.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "lldb/Host/Host.h"
+#include "lldb/Utility/ProcessInfo.h"
 #include "gtest/gtest.h"
 
 using namespace lldb_private;
@@ -25,3 +26,23 @@ TEST(Host, GetEnvironment) {
   ASSERT_EQ("Host::GetEnvironment",
 Host::GetEnvironment().lookup("LLDB_TEST_ENVIRONMENT_VAR"));
 }
+
+TEST(Host, ProcessInstanceInfoCumulativeUserTimeIsValid) {
+  ProcessInstanceInfo info;
+  info.SetCumulativeUserTime(ProcessInstanceInfo::timespec{0, 0});
+  EXPECT_FALSE(info.CumulativeUserTimeIsValid());
+  info.SetCumulativeUserTime(ProcessInstanceInfo::timespec{0, 1});
+  EXPECT_TRUE(info.CumulativeUserTimeIsValid());
+  info.SetCumulativeUserTime(ProcessInstanceInfo::timespec{1, 0});
+  EXPECT_TRUE(info.CumulativeUserTimeIsValid());
+}
+
+TEST(Host, ProcessInstanceInfoCumulativeSystemTimeIsValid) {
+  ProcessInstanceInfo info;
+  info.SetCumulativeSystemTime(ProcessInstanceInfo::timespec{0, 0});
+  EXPECT_FALSE(info.CumulativeSystemTimeIsValid());
+  info.SetCumulativeSystemTime(ProcessInstanceInfo::timespec{0, 1});
+  EXPECT_TRUE(info.CumulativeSystemTimeIsValid());
+  info.SetCumulativeSystemTime(ProcessInstanceInfo::timespec{1, 0});
+  EXPECT_TRUE(info.CumulativeSystemTimeIsValid());
+}
\ No newline at end of file

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


[Lldb-commits] [lldb] [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (PR #90140)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

Jonas upstreamed recognition of DW_TAG_LLVM_ptrauth_type 
https://reviews.llvm.org/D130215 but it isn't recognized as a type qualifier 
tag in DWARFASTParserClang::ParseTypeFromDWARF.

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


1 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp (+1) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 41d81fbcf1b087..12dafd3f5d5d51 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -495,6 +495,7 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const 
SymbolContext ,
   case DW_TAG_const_type:
   case DW_TAG_restrict_type:
   case DW_TAG_volatile_type:
+  case DW_TAG_LLVM_ptrauth_type:
   case DW_TAG_atomic_type:
   case DW_TAG_unspecified_type: {
 type_sp = ParseTypeModifier(sc, die, attrs);

``




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


[Lldb-commits] [lldb] [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual (PR #90140)

2024-04-25 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/90140

Jonas upstreamed recognition of DW_TAG_LLVM_ptrauth_type 
https://reviews.llvm.org/D130215 but it isn't recognized as a type qualifier 
tag in DWARFASTParserClang::ParseTypeFromDWARF.

>From b5e6f50797ddde235dde86f8e2f15a9fd6632092 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 25 Apr 2024 15:31:51 -0700
Subject: [PATCH] [lldb] Recognize DW_TAG_LLVM_ptrauth_type as a type qual

Jonas upstreamed recognition of DW_TAG_LLVM_ptrauth_type
https://reviews.llvm.org/D130215 but it isn't recognized as a type
qualifier tag in DWARFASTParserClang::ParseTypeFromDWARF.
---
 lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 41d81fbcf1b087..12dafd3f5d5d51 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -495,6 +495,7 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const 
SymbolContext ,
   case DW_TAG_const_type:
   case DW_TAG_restrict_type:
   case DW_TAG_volatile_type:
+  case DW_TAG_LLVM_ptrauth_type:
   case DW_TAG_atomic_type:
   case DW_TAG_unspecified_type: {
 type_sp = ParseTypeModifier(sc, die, attrs);

___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

ldrumm wrote:

Perhaps things have got lost during the discussion, but my this part of my 
original commit message is perhaps worth re-reading:

> In simple terms this means "unless otherwise specified, convert all files 
> considered "text" files to LF in the project history, but checkout them out 
> as expected on the local machine. What is "expected on the local machine" is 
> dependent on configuration and default.

> For those files in the repository that do need CRLF endings, I've adopted a 
> policy of eol=crlf which means that git will store them in history with LF, 
> but regardless of user config, they'll be checked out in tree with CRLF.

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


[Lldb-commits] [lldb] [lldb] Reenable test HostTest.GetProcessInfo with relaxed constraints. (PR #89637)

2024-04-25 Thread Fred Grim via lldb-commits

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


[Lldb-commits] [lldb] a5c4f96 - [lldb] Reenable test HostTest.GetProcessInfo with relaxed constraints. (#89637)

2024-04-25 Thread via lldb-commits

Author: Fred Grim
Date: 2024-04-25T15:05:45-07:00
New Revision: a5c4f969f4f2f15a4150229eebff769521759554

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

LOG: [lldb] Reenable test HostTest.GetProcessInfo with relaxed constraints. 
(#89637)

@jimingham I am wondering if you are ok removing this test? It caused
failures in some of the build bots because the user time was less than a
microsecond. Alternatively we can increase the number of loops or maybe
I need some other approach? I had commented it out just to not impact
others

Added: 


Modified: 
lldb/unittests/Host/linux/HostTest.cpp

Removed: 




diff  --git a/lldb/unittests/Host/linux/HostTest.cpp 
b/lldb/unittests/Host/linux/HostTest.cpp
index 733909902474d7..8ecaf3ec0decb0 100644
--- a/lldb/unittests/Host/linux/HostTest.cpp
+++ b/lldb/unittests/Host/linux/HostTest.cpp
@@ -69,17 +69,21 @@ TEST_F(HostTest, GetProcessInfo) {
   EXPECT_EQ(HostInfo::GetArchitecture(HostInfo::eArchKindDefault),
 Info.GetArchitecture());
   // Test timings
-  /*
-   * This is flaky in the buildbots on all archs
+  // In some sense this is a pretty trivial test. What it is trying to
+  // accomplish is just to validate that these values are never decreasing
+  // which would be unambiguously wrong. We can not reliably show them
+  // to be always increasing because the microsecond granularity means that,
+  // with hardware variations the number of loop iterations need to always
+  // be increasing for faster and faster machines.
   ASSERT_TRUE(Host::GetProcessInfo(getpid(), Info));
   ProcessInstanceInfo::timespec user_time = Info.GetUserTime();
   static volatile unsigned u = 0;
   for (unsigned i = 0; i < 10'000'000; i++) {
-u = i;
+u += i;
   }
+  ASSERT_TRUE(u > 0);
   ASSERT_TRUE(Host::GetProcessInfo(getpid(), Info));
   ProcessInstanceInfo::timespec next_user_time = Info.GetUserTime();
-  ASSERT_TRUE(user_time.tv_sec < next_user_time.tv_sec ||
-  user_time.tv_usec < next_user_time.tv_usec);
-  */
+  ASSERT_TRUE(user_time.tv_sec <= next_user_time.tv_sec ||
+  user_time.tv_usec <= next_user_time.tv_usec);
 }



___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

ldrumm wrote:

> Note, the changes to clang-format-vs should likely all be reverted. .sln is a 
> Microsoft Visual Studio solution file, as are many of the others

Right. .sln is a text file: 
https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022

> I have no idea whether Visual Studio will be happy with .natvis files having 
> non-Windows line endings.

They have CRLF line endings: 
https://github.com/llvm/llvm-project/pull/86318/commits/1994c29731fde75f075c0605b79a14667bcfb9ac#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eR6

https://github.com/llvm/llvm-project/pull/86318
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

ldrumm wrote:

> Also, it's a bit funny to have .bat files without CRLF endings given that 
> they run on Windows

They do have CRLF line endings: 
https://github.com/llvm/llvm-project/pull/86318/commits/1994c29731fde75f075c0605b79a14667bcfb9ac#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eR3

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


[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)

2024-04-25 Thread Med Ismail Bennani via lldb-commits

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

Pretty cool! LGTM!

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits

royitaqi wrote:

Hi @jimingham ,

I have updated the code. Now we have `Add` and `Remove` (with tokens as you 
suggested). `Set` clears everything then add the given one (also returns a 
token).

Thread-safety is done through a `std::lock_guard`. This 
is consistent with some of the other functions/fields.

Didn't understand one of your comment about "one destroy callback can 
add/remove others" and how that relates to the code. See my reply in the above.

Another thing I am not sure is, in python API test, how do I make concurrent 
calls to these APIs. Do you know if this should be tested (e.g. if other 
existing functions has similar tests)? If the answer is "yes", do you happen to 
know what existing test I can see as examples?


Thanks for your reviews so far. Hope this PR is getting better as we converse.

Best,
Roy

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();

royitaqi wrote:

I don't understand.

Were you referring to the `foreach` loop below and saying that since the 
container can be modified during the loop, the looping needs to be changed 
(e.g. to use the iterator instead of the `foreach` syntax)?

If you did meant to talk about the `user_id` then I don't think I understand 
how the `user_id` is related, because it seems it should be constant throughout 
the `HandleDestroyCallback` execution.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -1425,10 +1426,19 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
+void Debugger::AddDestroyCallback(
+lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);
+}
+
 void Debugger::SetDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
-  m_destroy_callback = destroy_callback;
-  m_destroy_callback_baton = baton;
+  ClearDestroyCallback();
+  AddDestroyCallback(destroy_callback, baton);
+}
+
+void Debugger::ClearDestroyCallback() {
+  m_destroy_callback_and_baton.clear();

royitaqi wrote:

Addressed in the latest version.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -1425,10 +1426,19 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
+void Debugger::AddDestroyCallback(
+lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);

royitaqi wrote:

Addressed in the latest version.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits


@@ -321,9 +321,14 @@ class LLDB_API SBDebugger {
 
   void SetLoggingCallback(lldb::LogOutputCallback log_callback, void *baton);
 
+  void AddDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
+  void *baton);
+
   void SetDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
   void *baton);
 
+  void ClearDestroyCallback();

royitaqi wrote:

Addressed in the latest version.

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/89868

>From 079a550481d4cdcb69ad01c376b5e1f0632a07d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 18:10:21 -0700
Subject: [PATCH 1/8] Allow multiple destroy callbacks in
 `SBDebugger::SetDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h |  4 ++--
 lldb/source/Core/Debugger.cpp | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f4..20884f954ec7db 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -731,8 +731,8 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::vector>
+   m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 19b3cf3bbf46b1..0ebdf2b0a0f970 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();
+  for (const auto _and_baton : m_destroy_callback_and_baton) {
+callback_and_baton.first(user_id, callback_and_baton.second);
   }
+  m_destroy_callback_and_baton.clear();
 }
 
 void Debugger::Destroy(DebuggerSP _sp) {
@@ -1427,8 +1428,7 @@ void Debugger::SetLoggingCallback(lldb::LogOutputCallback 
log_callback,
 
 void Debugger::SetDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
-  m_destroy_callback = destroy_callback;
-  m_destroy_callback_baton = baton;
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);
 }
 
 static void PrivateReportProgress(Debugger , uint64_t progress_id,

>From 771b52723be8d0ffecaf8f0818105cfdb82ba332 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 21:05:58 -0700
Subject: [PATCH 2/8] Fix code format

---
 lldb/include/lldb/Core/Debugger.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 20884f954ec7db..af025219b0bc12 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -732,7 +732,7 @@ class Debugger : public 
std::enable_shared_from_this,
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
   std::vector>
-   m_destroy_callback_and_baton;
+  m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;

>From d1f13cad8a3789a994572459893b32a225ba3e1b Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 24 Apr 2024 11:55:16 -0700
Subject: [PATCH 3/8] Add `AddDestroyCallback()` and `ClearDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h | 11 +++
 lldb/source/Core/Debugger.cpp | 12 +++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index af025219b0bc12..5b3e433f09c68e 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -568,10 +568,21 @@ class Debugger : public 
std::enable_shared_from_this,
 
   static void ReportSymbolChange(const ModuleSpec _spec);
 
+  /// Add a callback for when the debugger is destroyed. A list is maintained
+  /// internally.
+  void
+  AddDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
+ void *baton);
+
+  /// Clear the list of callbacks, then add the callback.
   void
   SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
  void *baton);
 
+  /// Clear the list of callbacks.
+  void
+  ClearDestroyCallback();
+
   /// Manually start the global event handler thread. It is useful to plugins
   /// that directly use the \a lldb_private namespace and want to use the
   /// debugger's default event handler thread instead of defining their own.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 0ebdf2b0a0f970..159913642f253e 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1426,11 +1426,21 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
-void Debugger::SetDestroyCallback(
+void Debugger::AddDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
   

[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/89868

>From 079a550481d4cdcb69ad01c376b5e1f0632a07d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 18:10:21 -0700
Subject: [PATCH 1/7] Allow multiple destroy callbacks in
 `SBDebugger::SetDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h |  4 ++--
 lldb/source/Core/Debugger.cpp | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 418c2403d020f4..20884f954ec7db 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -731,8 +731,8 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::vector>
+   m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 19b3cf3bbf46b1..0ebdf2b0a0f970 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -743,10 +743,11 @@ DebuggerSP 
Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
 }
 
 void Debugger::HandleDestroyCallback() {
-  if (m_destroy_callback) {
-m_destroy_callback(GetID(), m_destroy_callback_baton);
-m_destroy_callback = nullptr;
+  const lldb::user_id_t user_id = GetID();
+  for (const auto _and_baton : m_destroy_callback_and_baton) {
+callback_and_baton.first(user_id, callback_and_baton.second);
   }
+  m_destroy_callback_and_baton.clear();
 }
 
 void Debugger::Destroy(DebuggerSP _sp) {
@@ -1427,8 +1428,7 @@ void Debugger::SetLoggingCallback(lldb::LogOutputCallback 
log_callback,
 
 void Debugger::SetDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
-  m_destroy_callback = destroy_callback;
-  m_destroy_callback_baton = baton;
+  m_destroy_callback_and_baton.emplace_back(destroy_callback, baton);
 }
 
 static void PrivateReportProgress(Debugger , uint64_t progress_id,

>From 771b52723be8d0ffecaf8f0818105cfdb82ba332 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 23 Apr 2024 21:05:58 -0700
Subject: [PATCH 2/7] Fix code format

---
 lldb/include/lldb/Core/Debugger.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 20884f954ec7db..af025219b0bc12 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -732,7 +732,7 @@ class Debugger : public 
std::enable_shared_from_this,
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
   std::vector>
-   m_destroy_callback_and_baton;
+  m_destroy_callback_and_baton;
 
   uint32_t m_interrupt_requested = 0; ///< Tracks interrupt requests
   std::mutex m_interrupt_mutex;

>From d1f13cad8a3789a994572459893b32a225ba3e1b Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 24 Apr 2024 11:55:16 -0700
Subject: [PATCH 3/7] Add `AddDestroyCallback()` and `ClearDestroyCallback()`

---
 lldb/include/lldb/Core/Debugger.h | 11 +++
 lldb/source/Core/Debugger.cpp | 12 +++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index af025219b0bc12..5b3e433f09c68e 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -568,10 +568,21 @@ class Debugger : public 
std::enable_shared_from_this,
 
   static void ReportSymbolChange(const ModuleSpec _spec);
 
+  /// Add a callback for when the debugger is destroyed. A list is maintained
+  /// internally.
+  void
+  AddDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
+ void *baton);
+
+  /// Clear the list of callbacks, then add the callback.
   void
   SetDestroyCallback(lldb_private::DebuggerDestroyCallback destroy_callback,
  void *baton);
 
+  /// Clear the list of callbacks.
+  void
+  ClearDestroyCallback();
+
   /// Manually start the global event handler thread. It is useful to plugins
   /// that directly use the \a lldb_private namespace and want to use the
   /// debugger's default event handler thread instead of defining their own.
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 0ebdf2b0a0f970..159913642f253e 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1426,11 +1426,21 @@ void 
Debugger::SetLoggingCallback(lldb::LogOutputCallback log_callback,
   std::make_shared(log_callback, baton);
 }
 
-void Debugger::SetDestroyCallback(
+void Debugger::AddDestroyCallback(
 lldb_private::DebuggerDestroyCallback destroy_callback, void *baton) {
   

[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -2067,10 +2110,8 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
   SectionList *module_section_list =
   module_sp ? module_sp->GetSectionList() : nullptr;
 
-  // Local cache to avoid doing a FindSectionByName for each symbol. The "const
-  // char*" key must came from a ConstString object so they can be compared by
-  // pointer
-  std::unordered_map section_name_to_section;
+  // Cache the section mapping

JDevlieghere wrote:

Nit: missing period. A map from SectionSP to SectionSP looks somewhat 
suspicious, might be worth explaining what the key and the value mean. 

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -1854,6 +1854,49 @@ class VMAddressProvider {
 };
 }
 
+namespace {

JDevlieghere wrote:

Nit: LLVM and LLDB prefer static functions over anonymous namespaces. 

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere commented:

Can we add a test for this with obj2yaml? 

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -1854,6 +1854,49 @@ class VMAddressProvider {
 };
 }
 
+namespace {
+  // We have to do this because ELF doesn't have section IDs, and also
+  // doesn't require section names to be unique.  (We use the section index
+  // for section IDs, but that isn't guaranteed to be the same in separate
+  // debug images.)
+  SectionSP FindMatchingSection(const SectionList _list,
+SectionSP section) {
+SectionSP sect_sp;
+
+addr_t vm_addr = section->GetFileAddress();
+ConstString name = section->GetName();
+offset_t file_size = section->GetFileSize();
+offset_t byte_size = section->GetByteSize();
+SectionType type = section->GetType();
+bool thread_specific = section->IsThreadSpecific();
+uint32_t permissions = section->GetPermissions();
+uint32_t alignment = section->GetLog2Align();
+
+for (auto sect_iter = section_list.begin();
+ sect_iter != section_list.end();
+ ++sect_iter) {
+  if ((*sect_iter)->GetName() == name
+  && (*sect_iter)->GetType() == type
+  && (*sect_iter)->IsThreadSpecific() == thread_specific
+  && (*sect_iter)->GetPermissions() == permissions
+  && (*sect_iter)->GetFileSize() == file_size
+  && (*sect_iter)->GetByteSize() == byte_size
+  && (*sect_iter)->GetFileAddress() == vm_addr
+  && (*sect_iter)->GetLog2Align() == alignment) {

JDevlieghere wrote:

This seems like it could be an `operator ==` in the Section class. 

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -1854,6 +1854,49 @@ class VMAddressProvider {
 };
 }
 
+namespace {
+  // We have to do this because ELF doesn't have section IDs, and also
+  // doesn't require section names to be unique.  (We use the section index
+  // for section IDs, but that isn't guaranteed to be the same in separate
+  // debug images.)
+  SectionSP FindMatchingSection(const SectionList _list,
+SectionSP section) {
+SectionSP sect_sp;
+
+addr_t vm_addr = section->GetFileAddress();
+ConstString name = section->GetName();
+offset_t file_size = section->GetFileSize();
+offset_t byte_size = section->GetByteSize();
+SectionType type = section->GetType();
+bool thread_specific = section->IsThreadSpecific();
+uint32_t permissions = section->GetPermissions();
+uint32_t alignment = section->GetLog2Align();
+
+for (auto sect_iter = section_list.begin();
+ sect_iter != section_list.end();
+ ++sect_iter) {

JDevlieghere wrote:

Can this be a range-based for loop?

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)

2024-04-25 Thread via lldb-commits

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


[Lldb-commits] [lldb] 2f2e31c - Initial step in targets DAP support (#86623)

2024-04-25 Thread via lldb-commits

Author: jeffreytan81
Date: 2024-04-25T11:49:10-07:00
New Revision: 2f2e31c3c980407b2660b4f5d10e7cdb3fa79138

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

LOG: Initial step in targets DAP support  (#86623)

This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.

It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.

A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.

-

Co-authored-by: jeffreytan81 

Added: 
lldb/test/API/tools/lldb-dap/stepInTargets/Makefile
lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp

Modified: 
lldb/include/lldb/API/SBLineEntry.h
lldb/include/lldb/API/SBSymbolContextList.h
lldb/include/lldb/API/SBTarget.h
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
lldb/source/API/SBLineEntry.cpp
lldb/source/API/SBTarget.cpp
lldb/tools/lldb-dap/DAP.h
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBLineEntry.h 
b/lldb/include/lldb/API/SBLineEntry.h
index 7c2431ba3c8a51..d70c4fac6ec717 100644
--- a/lldb/include/lldb/API/SBLineEntry.h
+++ b/lldb/include/lldb/API/SBLineEntry.h
@@ -29,6 +29,9 @@ class LLDB_API SBLineEntry {
 
   lldb::SBAddress GetEndAddress() const;
 
+  lldb::SBAddress
+  GetSameLineContiguousAddressRangeEnd(bool include_inlined_functions) const;
+
   explicit operator bool() const;
 
   bool IsValid() const;

diff  --git a/lldb/include/lldb/API/SBSymbolContextList.h 
b/lldb/include/lldb/API/SBSymbolContextList.h
index 4026afc213571c..95100d219df20f 100644
--- a/lldb/include/lldb/API/SBSymbolContextList.h
+++ b/lldb/include/lldb/API/SBSymbolContextList.h
@@ -44,6 +44,7 @@ class LLDB_API SBSymbolContextList {
 protected:
   friend class SBModule;
   friend class SBTarget;
+  friend class SBCompileUnit;
 
   lldb_private::SymbolContextList *operator->() const;
 

diff  --git a/lldb/include/lldb/API/SBTarget.h 
b/lldb/include/lldb/API/SBTarget.h
index 823615e6a36df5..feeaa1cb71132b 100644
--- a/lldb/include/lldb/API/SBTarget.h
+++ b/lldb/include/lldb/API/SBTarget.h
@@ -879,6 +879,10 @@ class LLDB_API SBTarget {
uint32_t count,
const char *flavor_string);
 
+  lldb::SBInstructionList ReadInstructions(lldb::SBAddress start_addr,
+   lldb::SBAddress end_addr,
+   const char *flavor_string);
+
   lldb::SBInstructionList GetInstructions(lldb::SBAddress base_addr,
   const void *buf, size_t size);
 

diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 27a76a652f4063..5838281bcb1a10 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -811,23 +811,34 @@ def request_next(self, threadId):
 command_dict = {"command": "next", "type": "request", "arguments": 
args_dict}
 return self.send_recv(command_dict)
 
-def request_stepIn(self, threadId):
+def request_stepIn(self, threadId, targetId):
 if self.exit_status is not None:
-raise 

[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)

2024-04-25 Thread via lldb-commits

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

Most comments are addressed. Stamping to unblock. We can iterate with another 
PR :D

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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 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 f5953f46aa0a664461584b78c14cb141a3be2b9d 
ce54a7fb339a00029da266c9f518e344aac5d19e -- 
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 60fc68c96b..80be674f76 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1855,47 +1855,44 @@ public:
 }
 
 namespace {
-  // We have to do this because ELF doesn't have section IDs, and also
-  // doesn't require section names to be unique.  (We use the section index
-  // for section IDs, but that isn't guaranteed to be the same in separate
-  // debug images.)
-  SectionSP FindMatchingSection(const SectionList _list,
-SectionSP section) {
-SectionSP sect_sp;
-
-addr_t vm_addr = section->GetFileAddress();
-ConstString name = section->GetName();
-offset_t file_size = section->GetFileSize();
-offset_t byte_size = section->GetByteSize();
-SectionType type = section->GetType();
-bool thread_specific = section->IsThreadSpecific();
-uint32_t permissions = section->GetPermissions();
-uint32_t alignment = section->GetLog2Align();
-
-for (auto sect_iter = section_list.begin();
- sect_iter != section_list.end();
- ++sect_iter) {
-  if ((*sect_iter)->GetName() == name
-  && (*sect_iter)->GetType() == type
-  && (*sect_iter)->IsThreadSpecific() == thread_specific
-  && (*sect_iter)->GetPermissions() == permissions
-  && (*sect_iter)->GetFileSize() == file_size
-  && (*sect_iter)->GetByteSize() == byte_size
-  && (*sect_iter)->GetFileAddress() == vm_addr
-  && (*sect_iter)->GetLog2Align() == alignment) {
-sect_sp = *sect_iter;
+// We have to do this because ELF doesn't have section IDs, and also
+// doesn't require section names to be unique.  (We use the section index
+// for section IDs, but that isn't guaranteed to be the same in separate
+// debug images.)
+SectionSP FindMatchingSection(const SectionList _list,
+  SectionSP section) {
+  SectionSP sect_sp;
+
+  addr_t vm_addr = section->GetFileAddress();
+  ConstString name = section->GetName();
+  offset_t file_size = section->GetFileSize();
+  offset_t byte_size = section->GetByteSize();
+  SectionType type = section->GetType();
+  bool thread_specific = section->IsThreadSpecific();
+  uint32_t permissions = section->GetPermissions();
+  uint32_t alignment = section->GetLog2Align();
+
+  for (auto sect_iter = section_list.begin(); sect_iter != section_list.end();
+   ++sect_iter) {
+if ((*sect_iter)->GetName() == name && (*sect_iter)->GetType() == type &&
+(*sect_iter)->IsThreadSpecific() == thread_specific &&
+(*sect_iter)->GetPermissions() == permissions &&
+(*sect_iter)->GetFileSize() == file_size &&
+(*sect_iter)->GetByteSize() == byte_size &&
+(*sect_iter)->GetFileAddress() == vm_addr &&
+(*sect_iter)->GetLog2Align() == alignment) {
+  sect_sp = *sect_iter;
+  break;
+} else {
+  sect_sp = FindMatchingSection((*sect_iter)->GetChildren(), section);
+  if (sect_sp)
 break;
-  } else {
-sect_sp = FindMatchingSection((*sect_iter)->GetChildren(),
-  section);
-if (sect_sp)
-  break;
-  }
 }
-
-return sect_sp;
   }
+
+  return sect_sp;
 }
+} // namespace
 
 void ObjectFileELF::CreateSections(SectionList _section_list) {
   if (m_sections_up)
@@ -2318,12 +2315,11 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
 module_section_list != section_list) {
   auto section_it = section_map.find(symbol_section_sp);
   if (section_it == section_map.end()) {
-section_it =
-  section_map
-  .emplace(symbol_section_sp,
-   FindMatchingSection(*module_section_list,
-   symbol_section_sp))
-  .first;
+section_it = section_map
+ .emplace(symbol_section_sp,
+  FindMatchingSection(*module_section_list,
+  symbol_section_sp))
+ .first;
   }
   if (section_it->second)
 symbol_section_sp = section_it->second;

``




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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Alastair Houghton (al45tair)


Changes

Section unification cannot just use names, because it's valid for ELF binaries 
to have multiple sections with the same name.  We should check other section 
properties too.

Fixes #88001.

rdar://124467787

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


1 Files Affected:

- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (+53-11) 


``diff
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 0d95a1c12bde35..60fc68c96bcc1c 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1854,6 +1854,49 @@ class VMAddressProvider {
 };
 }
 
+namespace {
+  // We have to do this because ELF doesn't have section IDs, and also
+  // doesn't require section names to be unique.  (We use the section index
+  // for section IDs, but that isn't guaranteed to be the same in separate
+  // debug images.)
+  SectionSP FindMatchingSection(const SectionList _list,
+SectionSP section) {
+SectionSP sect_sp;
+
+addr_t vm_addr = section->GetFileAddress();
+ConstString name = section->GetName();
+offset_t file_size = section->GetFileSize();
+offset_t byte_size = section->GetByteSize();
+SectionType type = section->GetType();
+bool thread_specific = section->IsThreadSpecific();
+uint32_t permissions = section->GetPermissions();
+uint32_t alignment = section->GetLog2Align();
+
+for (auto sect_iter = section_list.begin();
+ sect_iter != section_list.end();
+ ++sect_iter) {
+  if ((*sect_iter)->GetName() == name
+  && (*sect_iter)->GetType() == type
+  && (*sect_iter)->IsThreadSpecific() == thread_specific
+  && (*sect_iter)->GetPermissions() == permissions
+  && (*sect_iter)->GetFileSize() == file_size
+  && (*sect_iter)->GetByteSize() == byte_size
+  && (*sect_iter)->GetFileAddress() == vm_addr
+  && (*sect_iter)->GetLog2Align() == alignment) {
+sect_sp = *sect_iter;
+break;
+  } else {
+sect_sp = FindMatchingSection((*sect_iter)->GetChildren(),
+  section);
+if (sect_sp)
+  break;
+  }
+}
+
+return sect_sp;
+  }
+}
+
 void ObjectFileELF::CreateSections(SectionList _section_list) {
   if (m_sections_up)
 return;
@@ -2067,10 +2110,8 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
   SectionList *module_section_list =
   module_sp ? module_sp->GetSectionList() : nullptr;
 
-  // Local cache to avoid doing a FindSectionByName for each symbol. The "const
-  // char*" key must came from a ConstString object so they can be compared by
-  // pointer
-  std::unordered_map section_name_to_section;
+  // Cache the section mapping
+  std::unordered_map section_map;
 
   unsigned i;
   for (i = 0; i < num_symbols; ++i) {
@@ -2275,14 +2316,15 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
 
 if (symbol_section_sp && module_section_list &&
 module_section_list != section_list) {
-  ConstString sect_name = symbol_section_sp->GetName();
-  auto section_it = section_name_to_section.find(sect_name.GetCString());
-  if (section_it == section_name_to_section.end())
+  auto section_it = section_map.find(symbol_section_sp);
+  if (section_it == section_map.end()) {
 section_it =
-section_name_to_section
-.emplace(sect_name.GetCString(),
- module_section_list->FindSectionByName(sect_name))
-.first;
+  section_map
+  .emplace(symbol_section_sp,
+   FindMatchingSection(*module_section_list,
+   symbol_section_sp))
+  .first;
+  }
   if (section_it->second)
 symbol_section_sp = section_it->second;
 }

``




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


[Lldb-commits] [lldb] [LLDB][ELF] Fix section unification to not just use names. (PR #90099)

2024-04-25 Thread Alastair Houghton via lldb-commits

https://github.com/al45tair created 
https://github.com/llvm/llvm-project/pull/90099

Section unification cannot just use names, because it's valid for ELF binaries 
to have multiple sections with the same name.  We should check other section 
properties too.

Fixes #88001.

rdar://124467787

>From ce54a7fb339a00029da266c9f518e344aac5d19e Mon Sep 17 00:00:00 2001
From: Alastair Houghton 
Date: Thu, 25 Apr 2024 11:35:55 +0100
Subject: [PATCH] [LLDB][ELF] Fix section unification to not just use names.

Section unification cannot just use names, because it's valid for ELF
binaries to have multiple sections with the same name.  We should check
other section properties too.

rdar://124467787
---
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  | 64 +++
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 0d95a1c12bde35..60fc68c96bcc1c 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1854,6 +1854,49 @@ class VMAddressProvider {
 };
 }
 
+namespace {
+  // We have to do this because ELF doesn't have section IDs, and also
+  // doesn't require section names to be unique.  (We use the section index
+  // for section IDs, but that isn't guaranteed to be the same in separate
+  // debug images.)
+  SectionSP FindMatchingSection(const SectionList _list,
+SectionSP section) {
+SectionSP sect_sp;
+
+addr_t vm_addr = section->GetFileAddress();
+ConstString name = section->GetName();
+offset_t file_size = section->GetFileSize();
+offset_t byte_size = section->GetByteSize();
+SectionType type = section->GetType();
+bool thread_specific = section->IsThreadSpecific();
+uint32_t permissions = section->GetPermissions();
+uint32_t alignment = section->GetLog2Align();
+
+for (auto sect_iter = section_list.begin();
+ sect_iter != section_list.end();
+ ++sect_iter) {
+  if ((*sect_iter)->GetName() == name
+  && (*sect_iter)->GetType() == type
+  && (*sect_iter)->IsThreadSpecific() == thread_specific
+  && (*sect_iter)->GetPermissions() == permissions
+  && (*sect_iter)->GetFileSize() == file_size
+  && (*sect_iter)->GetByteSize() == byte_size
+  && (*sect_iter)->GetFileAddress() == vm_addr
+  && (*sect_iter)->GetLog2Align() == alignment) {
+sect_sp = *sect_iter;
+break;
+  } else {
+sect_sp = FindMatchingSection((*sect_iter)->GetChildren(),
+  section);
+if (sect_sp)
+  break;
+  }
+}
+
+return sect_sp;
+  }
+}
+
 void ObjectFileELF::CreateSections(SectionList _section_list) {
   if (m_sections_up)
 return;
@@ -2067,10 +2110,8 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
   SectionList *module_section_list =
   module_sp ? module_sp->GetSectionList() : nullptr;
 
-  // Local cache to avoid doing a FindSectionByName for each symbol. The "const
-  // char*" key must came from a ConstString object so they can be compared by
-  // pointer
-  std::unordered_map section_name_to_section;
+  // Cache the section mapping
+  std::unordered_map section_map;
 
   unsigned i;
   for (i = 0; i < num_symbols; ++i) {
@@ -2275,14 +2316,15 @@ unsigned ObjectFileELF::ParseSymbols(Symtab *symtab, 
user_id_t start_id,
 
 if (symbol_section_sp && module_section_list &&
 module_section_list != section_list) {
-  ConstString sect_name = symbol_section_sp->GetName();
-  auto section_it = section_name_to_section.find(sect_name.GetCString());
-  if (section_it == section_name_to_section.end())
+  auto section_it = section_map.find(symbol_section_sp);
+  if (section_it == section_map.end()) {
 section_it =
-section_name_to_section
-.emplace(sect_name.GetCString(),
- module_section_list->FindSectionByName(sect_name))
-.first;
+  section_map
+  .emplace(symbol_section_sp,
+   FindMatchingSection(*module_section_list,
+   symbol_section_sp))
+  .first;
+  }
   if (section_it->second)
 symbol_section_sp = section_it->second;
 }

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


[Lldb-commits] [lldb] f5953f4 - Fix lldb build failure caused by 39adc8f42329

2024-04-25 Thread via lldb-commits

Author: erichkeane
Date: 2024-04-25T10:36:31-07:00
New Revision: f5953f46aa0a664461584b78c14cb141a3be2b9d

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

LOG: Fix lldb build failure caused by 39adc8f42329

We changed the name of one of the types, which is consumed by LLDB.  My
patch local build + CI didn't catch it, but a build bot did!  This
commit fixes it by updating the name in LLDB.

Added: 


Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 5da94adb771f86..8fc0f9103f5541 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -4861,7 +4861,7 @@ lldb::Encoding 
TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
 case clang::BuiltinType::Kind::OCLQueue:
 case clang::BuiltinType::Kind::OCLReserveID:
 case clang::BuiltinType::Kind::OCLSampler:
-case clang::BuiltinType::Kind::OMPArraySection:
+case clang::BuiltinType::Kind::ArraySection:
 case clang::BuiltinType::Kind::OMPArrayShaping:
 case clang::BuiltinType::Kind::OMPIterator:
 case clang::BuiltinType::Kind::Overload:
@@ -6013,7 +6013,7 @@ uint32_t 
TypeSystemClang::GetNumPointeeChildren(clang::QualType type) {
 case clang::BuiltinType::ARCUnbridgedCast:
 case clang::BuiltinType::PseudoObject:
 case clang::BuiltinType::BuiltinFn:
-case clang::BuiltinType::OMPArraySection:
+case clang::BuiltinType::ArraySection:
   return 1;
 default:
   return 0;



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


[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread Jonas Devlieghere via lldb-commits

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


https://github.com/llvm/llvm-project/pull/90029
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread Saleem Abdulrasool via lldb-commits

compnerd wrote:

> Also, it's a bit funny to have .bat files without CRLF endings given that 
> they run on Windows.

I'm not sure about the funny bit - but certainly dangerous. I've had cmd 
misinterpret batch files with LF vs CRLF.

https://github.com/llvm/llvm-project/pull/86318
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread Aaron Ballman via lldb-commits

https://github.com/AaronBallman commented:

I don't want this to be considered a comment which blocks the changes if others 
feel strongly in favor of them, but I'm not really convinced we should do this. 
The number of problems this patch will solve is approximately zero but the 
number of potential issues it will introduce is definitely nonzero. We've 
already seen one such problem come up during review and I expect there will be 
more, but also, this makes potential merge conflicts for downstreams (of the 
potentially frustrating variety because tools don't make line ending merge 
conflicts easy to spot).

It feels like a lot of churn for little benefit, even in the long term.

Note, the changes to clang-format-vs should likely all be reverted. .sln is a 
Microsoft Visual Studio solution file, as are many of the others. Also, it's a 
bit funny to have .bat files without CRLF endings given that they run on 
Windows. I have no idea whether Visual Studio will be happy with .natvis files 
having non-Windows line endings.

Realistically, each one of these files needs to be considered individually and 
that's a tall order for reviewers.

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


[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)

2024-04-25 Thread Jonas Devlieghere via lldb-commits


@@ -67,6 +67,10 @@ class LLDB_API SBExpressionOptions {
   void SetTrapExceptions(bool trap_exceptions = true);
 
   void SetLanguage(lldb::LanguageType language);
+  /// Set the language using a pair of language code and version as
+  /// defined by the DWARF 6 specification.
+  /// WARNING: These codes may change until DWARF 6 is finalized.
+  void SetLanguage(uint16_t dwarf_lname_code, uint32_t dwarf_lversion);

JDevlieghere wrote:

This feels wrong. How would you feel about exposing `SourceLanguage` as 
`SBSourceLanguage` and having a SetLanguage overload that takes that as an 
argument? It seems like a small difference, but I think it conceptually makes 
sense to initialize an `SBSourceLanguage` with a dwarf code/version.

As an added benefit it's also more future proof, if we need to extend the 
class, or want to use it elsewhere in the SB API where we currently use 
`lldb::LanguageType`. A quick grep shows 21 instances of `lldb::LanguageType` 
and if we thread this through more I could imagine wanting to have the ability 
of passing an `SBSourceLanguage` like we do here. 

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


[Lldb-commits] [lldb] [lldb] [llgs] Fix assertion in Handle_qfThreadInfo (PR #88301)

2024-04-25 Thread Ayush Sahay via lldb-commits

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


[Lldb-commits] [lldb] 2db7820 - [lldb] [llgs] Fix assertion in Handle_qfThreadInfo (#88301)

2024-04-25 Thread via lldb-commits

Author: Ayush Sahay
Date: 2024-04-25T22:30:02+05:30
New Revision: 2db782047b295730cd018b2641a16461f87ce55e

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

LOG: [lldb] [llgs] Fix assertion in Handle_qfThreadInfo (#88301)

Currently, GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo asserts
if the number of processes under debug isn’t 1 and the multiprocess
feature isn’t supported. This is so that we don't string IDs of threads
belonging to different processes together without including the IDs of
the processes themselves in the response when there are multiple
processes under debug. However, it’s conceivable that we have no process
under debug and the multiprocess feature isn’t supported. So, have
GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo assert if the
number of processes under debug is greater than 1 and the multiprocess
feature isn’t supported.

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 3d37bb226a65fd..ae1a77e5be8321 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -2087,7 +2087,7 @@ void GDBRemoteCommunicationServerLLGS::AddProcessThreads(
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerLLGS::Handle_qfThreadInfo(
 StringExtractorGDBRemote ) {
-  assert(m_debugged_processes.size() == 1 ||
+  assert(m_debugged_processes.size() <= 1 ||
  bool(m_extensions_supported &
   NativeProcessProtocol::Extension::multiprocess));
 



___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread Saleem Abdulrasool via lldb-commits

compnerd wrote:

> changes to `clang/test/CXX/lex/lex.literal/lex.string/p4.cpp` should be 
> reverted (it's a CRLF related test)

This is the type of problems that I am concerned about. We certainly have some 
tests which are line-ending sensitive, and each test should be audited before 
we make such a change.

https://github.com/llvm/llvm-project/pull/86318
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread Saleem Abdulrasool via lldb-commits

compnerd wrote:

> @compnerd I just realised I didn't respond to your concern. Apologies.
> 
> > I think that the concern that I have is that do we have sufficient testing 
> > for supporting line-ending dependent behaviour in the compiler?
> 
> For the first part: I don't know that it matters, since this patch changes 
> how the LLVM source code is stored, but not how its parsers operate. In any 
> case, we run parser testing on LF and CRLF systems since the precommit 
> testing runs on Linux, and Win32 at least. In addition, and there are several 
> tests dedicated to line ending, so I think we should be good there. Happy to 
> tend to this and fix anything I've missed if someone lets me know something 
> is broken after we merge.

I don't know if the pre-commit testing guarantees that. Configuration settings 
will permit the files to be checked out in either Unix (`\n`) or Windows 
(`\r\n`) line-endings. If the builders are all configured to run in Unix line 
endings we lose that coverage. While I understand that this change only changes 
how the LLVM sources are stored, the issue is that the LLVM sources include the 
_tests_ directory. These need to be tested in various manners to ensure that we 
test how we handle the different inputs (in clang). One option might be to 
exclude the tests directory from the line ending conversion if we cannot verify 
that we have tests in both formats.

> As for the second part
> 
> > Additionally, do we have sufficient documentation for others to figure out 
> > how to ensure that git does not munge the line endings if they are 
> > introducing a test which is dependent on it? In such a case, how do we 
> > ensure that they are aware that the SCM will do so without actually 
> > checking the post-commit state with a hex editor?
> 
> I don't think we do, but also this patch doesn't really change the problem 
> since right now basically _anything_ can happen due to local configuration 
> overrides (`~/.gitconfig`). I'll add a comment to the testing infrastructure 
> page to be mindful of how line endings are storedand link to the 
> `.gitattributes` documentation. Does that sound enough?

I think that the documentation should be good. While, yes, it is possible to 
get the wrong behaviour currently, if the user configures git explicitly for a 
line-ending, I would expect them to be aware of that. The use of 
`.gitattributes` means that their defaults are not necessarily honoured and 
thus this can catch them by surprise.

https://github.com/llvm/llvm-project/pull/86318
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

cor3ntin wrote:

changes to `clang/test/CXX/lex/lex.literal/lex.string/p4.cpp` should be 
reverted (it's a CRLF related test)

https://github.com/llvm/llvm-project/pull/86318
___
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] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

ldrumm wrote:

> I'll add a comment to the testing infrastructure page to be mindful of how 
> line endings are storedand link to the .gitattributes documentation. Does 
> that sound enough?

Added 
[here](https://github.com/llvm/llvm-project/blob/1994c29731fde75f075c0605b79a14667bcfb9ac/llvm/docs/TestingGuide.rst?plain=1#L363)

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


[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)

2024-04-25 Thread Adrian Prantl via lldb-commits


@@ -1203,26 +1203,23 @@ bool StackFrame::IsArtificial() const {
   return m_stack_frame_kind == StackFrame::Kind::Artificial;
 }
 
-lldb::LanguageType StackFrame::GetLanguage() {
+SourceLanguage StackFrame::GetLanguage() {
   CompileUnit *cu = GetSymbolContext(eSymbolContextCompUnit).comp_unit;
   if (cu)
 return cu->GetLanguage();
-  return lldb::eLanguageTypeUnknown;
+  return {};
 }
 
-lldb::LanguageType StackFrame::GuessLanguage() {
-  LanguageType lang_type = GetLanguage();
+SourceLanguage StackFrame::GuessLanguage() {
+  SourceLanguage lang_type = GetLanguage();
 
   if (lang_type == eLanguageTypeUnknown) {
-SymbolContext sc = GetSymbolContext(eSymbolContextFunction
-| eSymbolContextSymbol);
-if (sc.function) {
-  lang_type = sc.function->GetMangled().GuessLanguage();
-}
+SymbolContext sc =
+GetSymbolContext(eSymbolContextFunction | eSymbolContextSymbol);
+if (sc.function)
+  lang_type = LanguageType(sc.function->GetMangled().GuessLanguage());

adrian-prantl wrote:

Good point! I also wanted to make clear that my intention would be to 
eventually deprecate eLanguageType and replace all uses with the superior split 
SourceLanguage. I just had to stop _somewhere_ for this first iteration of the 
patch. But this is not meant to be the final state.

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


[Lldb-commits] [lldb] [lldb-dap] Report exit status message in lldb-dap, same as lldb cli (PR #89405)

2024-04-25 Thread via lldb-commits

github-actions[bot] wrote:



@mbucko Congratulations on having your first Pull Request (PR) merged into the 
LLVM Project!

Your changes will be combined with recent changes from other authors, then 
tested
by our [build bots](https://lab.llvm.org/buildbot/). If there is a problem with 
a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as
the builds can include changes from many authors. It is not uncommon for your
change to be included in a build that fails due to someone else's changes, or
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail 
[here](https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr).

If your change does cause a problem, it may be reverted, or you can revert it 
yourself.
This is a normal part of [LLVM 
development](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy).
 You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are 
working as expected, well done!


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


[Lldb-commits] [lldb] [lldb-dap] Report exit status message in lldb-dap, same as lldb cli (PR #89405)

2024-04-25 Thread via lldb-commits

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


[Lldb-commits] [lldb] ef2ca97 - [lldb-dap] Report exit status message in lldb-dap, same as lldb cli (#89405)

2024-04-25 Thread via lldb-commits

Author: Miro Bucko
Date: 2024-04-25T09:20:43-07:00
New Revision: ef2ca97f48f1aee1483f0c29de5ba52979bec454

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

LOG: [lldb-dap] Report exit status message in lldb-dap, same as lldb cli 
(#89405)

Summary:
When the target inferior process that is being debugged exits in lldb
command line, it emits following message:
`Process 4049526 exited with status = -1 (0x) debugserver died
with signal SIGTERM`
lldb-dap on the other hand does not emit a similar message. This PR adds
the same status message to lldb-dap.

Test Plan:
In VSCode debug any target and hit stop mode, kill lldb-server and
observe an exit status message similar to the following: Process 2167677
exited with status = -1 (0x) debugserver died with signal
SIGTERM

Reviewers:
@jeffreytan81,@clayborg,@kusmour,

Subscribers:

Tasks:
lldb-dap

Tags:

Added: 


Modified: 
lldb/include/lldb/API/SBProcess.h
lldb/source/API/SBProcess.cpp
lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
lldb/tools/lldb-dap/lldb-dap.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBProcess.h 
b/lldb/include/lldb/API/SBProcess.h
index 7da3335a7234b7..f1b5d1fb92ce29 100644
--- a/lldb/include/lldb/API/SBProcess.h
+++ b/lldb/include/lldb/API/SBProcess.h
@@ -562,6 +562,8 @@ class LLDB_API SBProcess {
 
   lldb::SBScriptObject GetScriptedImplementation();
 
+  void GetStatus(SBStream );
+
 protected:
   friend class SBAddress;
   friend class SBBreakpoint;

diff  --git a/lldb/source/API/SBProcess.cpp b/lldb/source/API/SBProcess.cpp
index c73348fde3f74d..c37c111c5a58e0 100644
--- a/lldb/source/API/SBProcess.cpp
+++ b/lldb/source/API/SBProcess.cpp
@@ -928,6 +928,14 @@ size_t SBProcess::WriteMemory(addr_t addr, const void 
*src, size_t src_len,
   return bytes_written;
 }
 
+void SBProcess::GetStatus(SBStream ) {
+  LLDB_INSTRUMENT_VA(this, status);
+
+  ProcessSP process_sp(GetSP());
+  if (process_sp)
+process_sp->GetStatus(status.ref());
+}
+
 bool SBProcess::GetDescription(SBStream ) {
   LLDB_INSTRUMENT_VA(this, description);
 

diff  --git a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py 
b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
index ffa0dc943e0693..8f456aaf890c7f 100644
--- a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
+++ b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
@@ -4,11 +4,23 @@
 
 import dap_server
 import lldbdap_testcase
+import psutil
+from collections import deque
 from lldbsuite.test import lldbutil
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 
 
+def get_subprocess(process_name):
+queue = deque([psutil.Process(os.getpid())])
+while queue:
+process = queue.popleft()
+if process.name() == process_name:
+return process
+queue.extend(process.children())
+
+self.assertTrue(False, "No subprocess with name %s found" % process_name)
+
 class TestDAP_console(lldbdap_testcase.DAPTestCaseBase):
 def check_lldb_command(
 self, lldb_command, contains_string, assert_msg, 
command_escape_prefix="`"
@@ -104,3 +116,49 @@ def test_empty_escape_prefix(self):
 "Help can be invoked",
 command_escape_prefix="",
 )
+
+@skipIfWindows
+@skipIfRemote
+def test_exit_status_message_sigterm(self):
+source = "main.cpp"
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program, commandEscapePrefix="")
+breakpoint1_line = line_number(source, "// breakpoint 1")
+breakpoint_ids = self.set_source_breakpoints(source, 
[breakpoint1_line])
+self.continue_to_breakpoints(breakpoint_ids)
+
+# Kill lldb-server process.
+process_name = (
+"debugserver" if platform.system() in ["Darwin"] else "lldb-server"
+)
+process = get_subprocess(process_name)
+process.terminate()
+process.wait()
+
+# Get the console output
+console_output = self.collect_console(1.0)
+
+# Verify the exit status message is printed.
+self.assertIn(
+"exited with status = -1 (0x) debugserver died with signal 
SIGTERM",
+console_output,
+"Exit status does not contain message 'exited with status'",
+)
+
+@skipIfWindows
+@skipIfRemote
+def test_exit_status_message_ok(self):
+source = "main.cpp"
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program, commandEscapePrefix="")
+self.continue_to_exit()
+
+# Get the console output
+console_output = self.collect_console(1.0)
+
+# Verify the exit status message is printed.
+self.assertIn(
+   

[Lldb-commits] [lldb] [lldb][riscv] Fix setting breakpoint for undecoded instruction (PR #90075)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (ita-sc)


Changes

Hi

This patch adds an interface GetLastInstrSize to get information about the size 
of last tried to be decoded instruction and uses it to set software breakpoint 
if the memory can be decoded as instruction.

RISC-V architecture instruction format specifies the length of instruction in 
first bits, so we can set a breakpoint for these cases. This is needed as RISCV 
have a lot of extensions, that are not suppored by `EmulateInstructionRISCV`.

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


6 Files Affected:

- (modified) lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp 
(+20-3) 
- (modified) lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h 
(+3) 
- (modified) 
lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp 
(+52-26) 
- (added) lldb/test/API/riscv/break-undecoded/Makefile (+3) 
- (added) lldb/test/API/riscv/break-undecoded/TestBreakpointIlligal.py (+27) 
- (added) lldb/test/API/riscv/break-undecoded/main.c (+7) 


``diff
diff --git a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp 
b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
index 6c46618b337c23..3f61e011d620a2 100644
--- a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
+++ b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
@@ -624,9 +624,26 @@ std::optional 
EmulateInstructionRISCV::Decode(uint32_t inst) {
   uint16_t try_rvc = uint16_t(inst & 0x);
   // check whether the compressed encode could be valid
   uint16_t mask = try_rvc & 0b11;
-  bool is_rvc = try_rvc != 0 && mask != 3;
   uint8_t inst_type = RV64;
 
+  // Try to get size of RISCV instruction.
+  // 1.2 Instruction Length Encoding
+  bool is_16b = (inst & 0b11) != 0b11;
+  bool is_32b = (inst & 0x1f) != 0x1f;
+  bool is_48b = (inst & 0x3f) != 0x1f;
+  bool is_64b = (inst & 0x7f) != 0x3f;
+  if (is_16b)
+m_last_size = 2;
+  else if (is_32b)
+m_last_size = 4;
+  else if (is_48b)
+m_last_size = 6;
+  else if (is_64b)
+m_last_size = 8;
+  else
+// Not Valid
+m_last_size = std::nullopt;
+
   // if we have ArchSpec::eCore_riscv128 in the future,
   // we also need to check it here
   if (m_arch.GetCore() == ArchSpec::eCore_riscv32)
@@ -638,8 +655,8 @@ std::optional 
EmulateInstructionRISCV::Decode(uint32_t inst) {
   LLDB_LOGF(
   log, "EmulateInstructionRISCV::%s: inst(%x at %" PRIx64 ") was 
decoded to %s",
   __FUNCTION__, inst, m_addr, pat.name);
-  auto decoded = is_rvc ? pat.decode(try_rvc) : pat.decode(inst);
-  return DecodeResult{decoded, inst, is_rvc, pat};
+  auto decoded = is_16b ? pat.decode(try_rvc) : pat.decode(inst);
+  return DecodeResult{decoded, inst, is_16b, pat};
 }
   }
   LLDB_LOGF(log, "EmulateInstructionRISCV::%s: inst(0x%x) was unsupported",
diff --git a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h 
b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
index 8bca73a7f589df..7eac59d9a127b5 100644
--- a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
+++ b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
@@ -60,6 +60,7 @@ class EmulateInstructionRISCV : public EmulateInstruction {
 
   bool SetTargetTriple(const ArchSpec ) override;
   bool ReadInstruction() override;
+  virtual std::optional GetLastInstrSize() { return std::nullopt; }
   bool EvaluateInstruction(uint32_t options) override;
   bool TestEmulation(Stream _stream, ArchSpec ,
  OptionValueDictionary *test_data) override;
@@ -99,6 +100,8 @@ class EmulateInstructionRISCV : public EmulateInstruction {
 private:
   /// Last decoded instruction from m_opcode
   DecodeResult m_decoded;
+  /// Last tried to be decoded instruction expected size.
+  std::optional m_last_size;
 };
 
 } // namespace lldb_private
diff --git 
a/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp 
b/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
index 6bf8a0dc28b22e..a6019d09737472 100644
--- a/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
+++ b/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
@@ -94,6 +94,39 @@ static lldb::addr_t ReadFlags(NativeRegisterContext 
_context) {
  LLDB_INVALID_ADDRESS);
 }
 
+static int GetSoftwareWatchpointSize(const ArchSpec ,
+ lldb::addr_t next_flags) {
+  if (arch.GetMachine() == llvm::Triple::arm) {
+if (next_flags & 0x20)
+  // Thumb mode
+  return 2;
+else
+  // Arm mode
+  return 4;
+  }
+  if (arch.IsMIPS() || arch.GetTriple().isPPC64() ||
+  arch.GetTriple().isRISCV() || arch.GetTriple().isLoongArch())
+return 4;
+  return 0;
+}
+
+static Status SetSoftwareBreakPointOnPC(const ArchSpec , lldb::addr_t 

[Lldb-commits] [lldb] [lldb][riscv] Fix setting breakpoint for undecoded instruction (PR #90075)

2024-04-25 Thread via lldb-commits

https://github.com/ita-sc created 
https://github.com/llvm/llvm-project/pull/90075

Hi

This patch adds an interface GetLastInstrSize to get information about the size 
of last tried to be decoded instruction and uses it to set software breakpoint 
if the memory can be decoded as instruction.

RISC-V architecture instruction format specifies the length of instruction in 
first bits, so we can set a breakpoint for these cases. This is needed as RISCV 
have a lot of extensions, that are not suppored by `EmulateInstructionRISCV`.

>From e144b99f2200ba362f149b5552eaeef9a45fb747 Mon Sep 17 00:00:00 2001
From: Ivan Tetyushkin 
Date: Fri, 19 Apr 2024 18:47:05 +0300
Subject: [PATCH 1/2] [lldb][riscv] Fix setting breakpoint for undecoded
 instruction

Copy gdb behaviour:
For RISCV we can set breakpoint even for unknown instruction, as
RISCV encoding have information about size of instruction.
---
 .../RISCV/EmulateInstructionRISCV.cpp | 23 +-
 .../RISCV/EmulateInstructionRISCV.h   |  3 +
 .../NativeProcessSoftwareSingleStep.cpp   | 78 ---
 3 files changed, 75 insertions(+), 29 deletions(-)

diff --git a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp 
b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
index 6c46618b337c23..3f61e011d620a2 100644
--- a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
+++ b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp
@@ -624,9 +624,26 @@ std::optional 
EmulateInstructionRISCV::Decode(uint32_t inst) {
   uint16_t try_rvc = uint16_t(inst & 0x);
   // check whether the compressed encode could be valid
   uint16_t mask = try_rvc & 0b11;
-  bool is_rvc = try_rvc != 0 && mask != 3;
   uint8_t inst_type = RV64;
 
+  // Try to get size of RISCV instruction.
+  // 1.2 Instruction Length Encoding
+  bool is_16b = (inst & 0b11) != 0b11;
+  bool is_32b = (inst & 0x1f) != 0x1f;
+  bool is_48b = (inst & 0x3f) != 0x1f;
+  bool is_64b = (inst & 0x7f) != 0x3f;
+  if (is_16b)
+m_last_size = 2;
+  else if (is_32b)
+m_last_size = 4;
+  else if (is_48b)
+m_last_size = 6;
+  else if (is_64b)
+m_last_size = 8;
+  else
+// Not Valid
+m_last_size = std::nullopt;
+
   // if we have ArchSpec::eCore_riscv128 in the future,
   // we also need to check it here
   if (m_arch.GetCore() == ArchSpec::eCore_riscv32)
@@ -638,8 +655,8 @@ std::optional 
EmulateInstructionRISCV::Decode(uint32_t inst) {
   LLDB_LOGF(
   log, "EmulateInstructionRISCV::%s: inst(%x at %" PRIx64 ") was 
decoded to %s",
   __FUNCTION__, inst, m_addr, pat.name);
-  auto decoded = is_rvc ? pat.decode(try_rvc) : pat.decode(inst);
-  return DecodeResult{decoded, inst, is_rvc, pat};
+  auto decoded = is_16b ? pat.decode(try_rvc) : pat.decode(inst);
+  return DecodeResult{decoded, inst, is_16b, pat};
 }
   }
   LLDB_LOGF(log, "EmulateInstructionRISCV::%s: inst(0x%x) was unsupported",
diff --git a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h 
b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
index 8bca73a7f589df..7eac59d9a127b5 100644
--- a/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
+++ b/lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h
@@ -60,6 +60,7 @@ class EmulateInstructionRISCV : public EmulateInstruction {
 
   bool SetTargetTriple(const ArchSpec ) override;
   bool ReadInstruction() override;
+  virtual std::optional GetLastInstrSize() { return std::nullopt; }
   bool EvaluateInstruction(uint32_t options) override;
   bool TestEmulation(Stream _stream, ArchSpec ,
  OptionValueDictionary *test_data) override;
@@ -99,6 +100,8 @@ class EmulateInstructionRISCV : public EmulateInstruction {
 private:
   /// Last decoded instruction from m_opcode
   DecodeResult m_decoded;
+  /// Last tried to be decoded instruction expected size.
+  std::optional m_last_size;
 };
 
 } // namespace lldb_private
diff --git 
a/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp 
b/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
index 6bf8a0dc28b22e..a6019d09737472 100644
--- a/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
+++ b/lldb/source/Plugins/Process/Utility/NativeProcessSoftwareSingleStep.cpp
@@ -94,6 +94,39 @@ static lldb::addr_t ReadFlags(NativeRegisterContext 
_context) {
  LLDB_INVALID_ADDRESS);
 }
 
+static int GetSoftwareWatchpointSize(const ArchSpec ,
+ lldb::addr_t next_flags) {
+  if (arch.GetMachine() == llvm::Triple::arm) {
+if (next_flags & 0x20)
+  // Thumb mode
+  return 2;
+else
+  // Arm mode
+  return 4;
+  }
+  if (arch.IsMIPS() || arch.GetTriple().isPPC64() ||
+  arch.GetTriple().isRISCV() || arch.GetTriple().isLoongArch())
+return 4;
+  return 0;
+}
+
+static Status 

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-04-25 Thread via lldb-commits

ldrumm wrote:

@compnerd I just realised I didn't respond to your concern. Apologies.

> I think that the concern that I have is that do we have sufficient testing 
> for supporting line-ending dependent behaviour in the compiler? 

For the first part: I don't know that it matters, since this patch changes how 
the LLVM source code is stored, but not how its parsers operate. In any case, 
we run parser testing on LF and CRLF systems since the precommit testing runs 
on Linux, and Win32 at least. In addition, and there are several tests 
dedicated to line ending, so I think we should be good there. Happy to tend to 
this and fix anything I've missed if someone lets me know something is broken 
after we merge.

As for the second part
>Additionally, do we have sufficient documentation for others to figure out how 
>to ensure that git does not munge the line endings if they are introducing a 
>test which is dependent on it? In such a case, how do we ensure that they are 
>aware that the SCM will do so without actually checking the post-commit state 
>with a hex editor?

I don't think we do, but also this patch doesn't really change the problem 
since right now basically *anything* can happen due to local configuration 
overrides (`~/.gitconfig`). I'll add a comment to the testing infrastructure 
page to be mindful of how line endings are storedand link to the 
`.gitattributes` documentation. Does that sound enough?

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


[Lldb-commits] [lldb] Allow multiple destroy callbacks in `SBDebugger::SetDestroyCallback()` (PR #89868)

2024-04-25 Thread via lldb-commits

jimingham wrote:

For legacy reasons, I think we have to keep SetDestroyCallbacks doing what it 
did, but we should comment that it is deprecated and to use the Add and Remove 
to only affect your own callbacks.

Jim


> On Apr 24, 2024, at 6:19 PM, royitaqi ***@***.***> wrote:
> 
> 
> @royitaqi commented on this pull request.
> 
> In lldb/include/lldb/API/SBDebugger.h 
> :
> 
> >void SetDestroyCallback(lldb::SBDebuggerDestroyCallback destroy_callback,
>void *baton);
>  
> +  void ClearDestroyCallback();
> It seems wrong that one client can only remove its destroy callback by 
> removing ones it didn't install.
> Makes sense to me.
> 
> I think you are suggesting:
> 
> TToken AddDestroyCallback(callback, baton)
> bool RemoveDestroyCallback(TToken token) - returns success/fail
> No/remove ClearDestroyCallbacks - because no one is supposed to clear
> Then what should SetDestroyCallback be?
> 
> It clears existing callbacks, so I think in this new world this semantics 
> isn't allowed, similar to how ClearDestroyCallbacks shouldn't exist.
> That is, unless, we introduce the concept of a client ID, where 
> SetDestroyCallback will remove all callbacks from the specified client ID. 
> But then I feel the introduction of the client ID opens up even more 
> questions, and it's not an existing pattern in the Debugger class. So it's 
> probably not a good idea.
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you were mentioned.
> 



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


[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I understand, so the value is made from `a | b | c` for example. I didn't think 
of whether register fields could hit this path, but it's equivalent to a C enum 
they'll be using, so I think it could happen.

I'll test this, thanks for bringing it up.

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


[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread Vlad Serebrennikov via lldb-commits

Endilll wrote:

> For me the picture is limited to register printing. I'll be setting this new 
> option on the register type when printing 
> (https://github.com/DavidSpickett/llvm-project/commit/24dbefaa14030646ba0871298989558221af1ba0#diff-18135f619417bbaa1ab0c181ce55b2c55681323c06e90fa1a3e16099c7176e21).
>  So only from C++ for now.

So it's hard-coded, I see.

> What is a flag like enum?

`enum { a = 1, b = 2, c = 4, d = 8}` — this sort of enumeration. Sorry if my 
terminology was confusing. They are handled further in `DumpEnumValue()`, after 
the changes you've made here, and called bit-fields in the comments.

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


[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> It's also not clear how this new "presentation mode" is going to be 
> controlled. While it's not in the scope of this PR, it would be nice if you 
> can share a bigger picture.

For me the picture is limited to register printing. I'll be setting this new 
option on the register type when printing 
(https://github.com/DavidSpickett/llvm-project/commit/24dbefaa14030646ba0871298989558221af1ba0#diff-18135f619417bbaa1ab0c181ce55b2c55681323c06e90fa1a3e16099c7176e21).
 So only from C++ for now.

> Another thing this PR doesn't seem to touch is flag-like enums. Even if you 
> don't want to add a numerical value there, because it'd be too much 
> information to present, it still would be nice to see it explicitly 
> considered.

What is a flag like enum?

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


[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread Vlad Serebrennikov via lldb-commits

Endilll wrote:

I'm excited so see changes in this area!

> It is a subset of https://github.com/llvm/llvm-project/pull/69815, only for 
> use by register printing (ping @Endilll).

Yeah, that effort is stalled because I don't see a clear path forward there, 
and I'm lacking energy to find and push for one. I guess I can try to piggyback 
on this PR if it goes in the direction I need (I hope you don't mind :).

Seriously, though, I'm not sure how your design with a flag orthogonal to 
format fares in the feedback I was given back then. It's also not clear how 
this new "presentation mode" is going to be controlled. While it's not in the 
scope of this PR, it would be nice if you can share a bigger picture.

Another thing this PR doesn't seem to touch is flag-like enums. Even if you 
don't want to add a numerical value there, because it'd be too much information 
to present, it still would be nice to see it explicitly considered.

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


[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

This represents the enum type that can be assigned to a field using the 
`enum` element in the target XML.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html

Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to

The XML includes a "size" but we don't need that for anything and it's a pain 
to verify so I've left it out of our internal structures. When emitting XML 
we'll set size to the size of the register using the enum.

An Enumerator class is added to RegisterFlags and hooked up to the existing 
ToXML so lldb-server can use it to emit enums as well.

As enums are elements on the same level as flags, when emitting XML we'll do so 
via the registers. Before emitting a flags element we look at all the fields 
and see what enums they reference. Then print all of those if we haven't 
already done so.

Functions are added to dump enum information for `register info` to use to show 
the enum information.

---

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


3 Files Affected:

- (modified) lldb/include/lldb/Target/RegisterFlags.h (+65-7) 
- (modified) lldb/source/Target/RegisterFlags.cpp (+197-2) 
- (modified) lldb/unittests/Target/RegisterFlagsTest.cpp (+174-1) 


``diff
diff --git a/lldb/include/lldb/Target/RegisterFlags.h 
b/lldb/include/lldb/Target/RegisterFlags.h
index 9b343e445678ab..49219a52e13643 100644
--- a/lldb/include/lldb/Target/RegisterFlags.h
+++ b/lldb/include/lldb/Target/RegisterFlags.h
@@ -13,11 +13,42 @@
 #include 
 #include 
 
+#include "llvm/ADT/StringSet.h"
+
 namespace lldb_private {
 
 class StreamString;
 class Log;
 
+class FieldEnum {
+public:
+  struct Enumerator {
+uint64_t m_value;
+// Short name for the value. Shown in tables and when printing the field's
+// value. For example "RZ".
+std::string m_name;
+
+Enumerator(uint64_t value, std::string name)
+: m_value(value), m_name(name) {}
+
+void ToXML(StreamString ) const;
+  };
+
+  typedef std::vector Enumerators;
+
+  FieldEnum(std::string id, const Enumerators );
+
+  const Enumerators () const { return m_enumerators; }
+
+  const std::string () const { return m_id; }
+
+  void ToXML(StreamString , unsigned size) const;
+
+private:
+  std::string m_id;
+  std::vector m_enumerators;
+};
+
 class RegisterFlags {
 public:
   class Field {
@@ -26,17 +57,27 @@ class RegisterFlags {
 /// significant bit. The start bit must be <= the end bit.
 Field(std::string name, unsigned start, unsigned end);
 
+/// Construct a field that also has some known enum values.
+Field(std::string name, unsigned start, unsigned end,
+  const FieldEnum *enum_type);
+
 /// Construct a field that occupies a single bit.
-Field(std::string name, unsigned bit_position)
-: m_name(std::move(name)), m_start(bit_position), m_end(bit_position) 
{}
+Field(std::string name, unsigned bit_position);
 
 /// Get size of the field in bits. Will always be at least 1.
-unsigned GetSizeInBits() const { return m_end - m_start + 1; }
+unsigned GetSizeInBits() const;
+
+/// Identical to GetSizeInBits, but for the GDB client to use.
+static unsigned GetSizeInBits(unsigned start, unsigned end);
 
 /// A mask that covers all bits of the field.
-uint64_t GetMask() const {
-  return (((uint64_t)1 << (GetSizeInBits())) - 1) << m_start;
-}
+uint64_t GetMask() const;
+
+/// The maximum unsigned value that could be contained in this field.
+uint64_t GetMaxValue() const;
+
+/// Identical to GetMaxValue but for the GDB client to use.
+static uint64_t GetMaxValue(unsigned start, unsigned end);
 
 /// Extract value of the field from a whole register value.
 uint64_t GetValue(uint64_t register_value) const {
@@ -46,6 +87,7 @@ class RegisterFlags {
 const std::string () const { return m_name; }
 unsigned GetStart() const { return m_start; }
 unsigned GetEnd() const { return m_end; }
+const FieldEnum *GetEnum() const { return m_enum_type; }
 bool Overlaps(const Field ) const;
 void log(Log *log) const;
 
@@ -69,12 +111,15 @@ class RegisterFlags {
 
   private:
 std::string m_name;
+
 /// Start/end bit positions. Where start N, end N means a single bit
 /// field at position N. We expect that start <= end. Bit positions begin
 /// at 0.
 /// Start is the LSB, end is the MSB.
 unsigned m_start;
 unsigned m_end;
+
+const FieldEnum *m_enum_type;
   };
 
   /// This assumes that:
@@ -89,6 +134,10 @@ class RegisterFlags {
   /// when runtime field detection is needed.
   void SetFields(const std::vector );
 
+  /// Make a string where each line contains the name of a field that has
+  /// enum values, and lists what those values are.
+  std::string 

[Lldb-commits] [lldb] [lldb] Add register field enum class (PR #90063)

2024-04-25 Thread David Spickett via lldb-commits

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

This represents the enum type that can be assigned to a field using the 
`` element in the target XML.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html

Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to

The XML includes a "size" but we don't need that for anything and it's a pain 
to verify so I've left it out of our internal structures. When emitting XML 
we'll set size to the size of the register using the enum.

An Enumerator class is added to RegisterFlags and hooked up to the existing 
ToXML so lldb-server can use it to emit enums as well.

As enums are elements on the same level as flags, when emitting XML we'll do so 
via the registers. Before emitting a flags element we look at all the fields 
and see what enums they reference. Then print all of those if we haven't 
already done so.

Functions are added to dump enum information for `register info` to use to show 
the enum information.

>From 1ed45727235f68d0208dbcf6c871ccbc768f92e5 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Mon, 11 Mar 2024 10:51:22 +
Subject: [PATCH] [lldb] Add register field enum class

This represents the enum type that can be assigned to a field
using the `` element in the target XML.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html

Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to

The XML includes a "size" but we don't need that for anything
and it's a pain to verify so I've left it out of our internal
strcutures. When emitting XML we'll set size to the size of
the register using the enum.

An Enumerator class is added to RegisterFlags and hooked up
to the existing ToXML so lldb-server will include them in the
target XML.

As enums are elements on the same level as flags, when emitting
XML we'll do so via the registers. Before emitting a flags element
we look at all the fields and see what enums they refernce. Then
print all of those if we haven't already.

Functions are added to dump enum information for `register info`
to use to show the enum information.
---
 lldb/include/lldb/Target/RegisterFlags.h|  72 ++-
 lldb/source/Target/RegisterFlags.cpp| 199 +++-
 lldb/unittests/Target/RegisterFlagsTest.cpp | 175 -
 3 files changed, 436 insertions(+), 10 deletions(-)

diff --git a/lldb/include/lldb/Target/RegisterFlags.h 
b/lldb/include/lldb/Target/RegisterFlags.h
index 9b343e445678ab..49219a52e13643 100644
--- a/lldb/include/lldb/Target/RegisterFlags.h
+++ b/lldb/include/lldb/Target/RegisterFlags.h
@@ -13,11 +13,42 @@
 #include 
 #include 
 
+#include "llvm/ADT/StringSet.h"
+
 namespace lldb_private {
 
 class StreamString;
 class Log;
 
+class FieldEnum {
+public:
+  struct Enumerator {
+uint64_t m_value;
+// Short name for the value. Shown in tables and when printing the field's
+// value. For example "RZ".
+std::string m_name;
+
+Enumerator(uint64_t value, std::string name)
+: m_value(value), m_name(name) {}
+
+void ToXML(StreamString ) const;
+  };
+
+  typedef std::vector Enumerators;
+
+  FieldEnum(std::string id, const Enumerators );
+
+  const Enumerators () const { return m_enumerators; }
+
+  const std::string () const { return m_id; }
+
+  void ToXML(StreamString , unsigned size) const;
+
+private:
+  std::string m_id;
+  std::vector m_enumerators;
+};
+
 class RegisterFlags {
 public:
   class Field {
@@ -26,17 +57,27 @@ class RegisterFlags {
 /// significant bit. The start bit must be <= the end bit.
 Field(std::string name, unsigned start, unsigned end);
 
+/// Construct a field that also has some known enum values.
+Field(std::string name, unsigned start, unsigned end,
+  const FieldEnum *enum_type);
+
 /// Construct a field that occupies a single bit.
-Field(std::string name, unsigned bit_position)
-: m_name(std::move(name)), m_start(bit_position), m_end(bit_position) 
{}
+Field(std::string name, unsigned bit_position);
 
 /// Get size of the field in bits. Will always be at least 1.
-unsigned GetSizeInBits() const { return m_end - m_start + 1; }
+unsigned GetSizeInBits() const;
+
+/// Identical to GetSizeInBits, but for the GDB client to use.
+static unsigned GetSizeInBits(unsigned start, unsigned end);
 
 /// A mask that covers all bits of the field.
-uint64_t GetMask() const {
-  return (((uint64_t)1 << (GetSizeInBits())) - 1) << m_start;
-}
+uint64_t GetMask() const;
+
+/// The maximum unsigned value that could be contained in this field.
+uint64_t GetMaxValue() const;
+
+/// Identical to GetMaxValue but for the GDB client to use.
+static uint64_t GetMaxValue(unsigned start, unsigned end);
 
 /// Extract value of the field from a whole register value.
 

[Lldb-commits] [lldb] [lldb-dap] Report exit status message in lldb-dap, same as lldb cli (PR #89405)

2024-04-25 Thread Miro Bucko via lldb-commits

https://github.com/mbucko updated 
https://github.com/llvm/llvm-project/pull/89405

>From edefccebc44296d9be29ddde2c48174feb5d2911 Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 19 Apr 2024 08:08:02 -0700
Subject: [PATCH] Report exit status message in lldb-dap, same as lldb cli

Summary:
When the target inferior process that is being debugged exits in lldb command 
line, it emits following message:
Process 4049526 exited with status = -1 (0x) debugserver died with 
signal SIGTERM
lldb-dap on the other hand does not emit a similar message.
This PR adds the same status message to lldb-dap.

Test Plan:
In VSCode debug any target and hit stop mode, kill lldb-server and observe an 
exit status message similar to the following:
Process 2167677 exited with status = -1 (0x) debugserver died with 
signal SIGTERM

Reviewers:

Subscribers:

Tasks:
lldb-dap

Tags:
---
 lldb/include/lldb/API/SBProcess.h |  2 +
 lldb/source/API/SBProcess.cpp |  8 +++
 .../tools/lldb-dap/console/TestDAP_console.py | 58 +++
 lldb/tools/lldb-dap/lldb-dap.cpp  |  5 ++
 4 files changed, 73 insertions(+)

diff --git a/lldb/include/lldb/API/SBProcess.h 
b/lldb/include/lldb/API/SBProcess.h
index 7da3335a7234b7..f1b5d1fb92ce29 100644
--- a/lldb/include/lldb/API/SBProcess.h
+++ b/lldb/include/lldb/API/SBProcess.h
@@ -562,6 +562,8 @@ class LLDB_API SBProcess {
 
   lldb::SBScriptObject GetScriptedImplementation();
 
+  void GetStatus(SBStream );
+
 protected:
   friend class SBAddress;
   friend class SBBreakpoint;
diff --git a/lldb/source/API/SBProcess.cpp b/lldb/source/API/SBProcess.cpp
index c73348fde3f74d..c37c111c5a58e0 100644
--- a/lldb/source/API/SBProcess.cpp
+++ b/lldb/source/API/SBProcess.cpp
@@ -928,6 +928,14 @@ size_t SBProcess::WriteMemory(addr_t addr, const void 
*src, size_t src_len,
   return bytes_written;
 }
 
+void SBProcess::GetStatus(SBStream ) {
+  LLDB_INSTRUMENT_VA(this, status);
+
+  ProcessSP process_sp(GetSP());
+  if (process_sp)
+process_sp->GetStatus(status.ref());
+}
+
 bool SBProcess::GetDescription(SBStream ) {
   LLDB_INSTRUMENT_VA(this, description);
 
diff --git a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py 
b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
index ffa0dc943e0693..8f456aaf890c7f 100644
--- a/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
+++ b/lldb/test/API/tools/lldb-dap/console/TestDAP_console.py
@@ -4,11 +4,23 @@
 
 import dap_server
 import lldbdap_testcase
+import psutil
+from collections import deque
 from lldbsuite.test import lldbutil
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 
 
+def get_subprocess(process_name):
+queue = deque([psutil.Process(os.getpid())])
+while queue:
+process = queue.popleft()
+if process.name() == process_name:
+return process
+queue.extend(process.children())
+
+self.assertTrue(False, "No subprocess with name %s found" % process_name)
+
 class TestDAP_console(lldbdap_testcase.DAPTestCaseBase):
 def check_lldb_command(
 self, lldb_command, contains_string, assert_msg, 
command_escape_prefix="`"
@@ -104,3 +116,49 @@ def test_empty_escape_prefix(self):
 "Help can be invoked",
 command_escape_prefix="",
 )
+
+@skipIfWindows
+@skipIfRemote
+def test_exit_status_message_sigterm(self):
+source = "main.cpp"
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program, commandEscapePrefix="")
+breakpoint1_line = line_number(source, "// breakpoint 1")
+breakpoint_ids = self.set_source_breakpoints(source, 
[breakpoint1_line])
+self.continue_to_breakpoints(breakpoint_ids)
+
+# Kill lldb-server process.
+process_name = (
+"debugserver" if platform.system() in ["Darwin"] else "lldb-server"
+)
+process = get_subprocess(process_name)
+process.terminate()
+process.wait()
+
+# Get the console output
+console_output = self.collect_console(1.0)
+
+# Verify the exit status message is printed.
+self.assertIn(
+"exited with status = -1 (0x) debugserver died with signal 
SIGTERM",
+console_output,
+"Exit status does not contain message 'exited with status'",
+)
+
+@skipIfWindows
+@skipIfRemote
+def test_exit_status_message_ok(self):
+source = "main.cpp"
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program, commandEscapePrefix="")
+self.continue_to_exit()
+
+# Get the console output
+console_output = self.collect_console(1.0)
+
+# Verify the exit status message is printed.
+self.assertIn(
+"exited with status = 0 (0x)",
+console_output,
+"Exit status does not contain message 'exited with status'",
+   

[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread David Spickett via lldb-commits

DavidSpickett wrote:

This is the first change for 
https://discourse.llvm.org/t/rfc-adding-register-field-enums-to-lldb/77275, 
though there has been a change of plans and now I'm implementing existing GDB 
features to get the same result.

It is a subset of https://github.com/llvm/llvm-project/pull/69815, only for use 
by register printing (ping @Endilll).

> I have not added tests for this because right now the use case for this is 
> registers

Also I wasn't sure if I could test this given only C++ can set this right now, 
but I'll add tests if someone knows where they might go.

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


[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

When an enum is used to represent certain data it can be useful to know its 
name and the value of it. For instance, register fields are often set in source 
code as numbers, but in the debugger you'd like to see the meaning as well.

(lldb) register read fpcr
fpcr = 0x
 = (... RMode = RN (0), ...)

Often you do just want the meaning but the value saves you having to manually 
decode it if you want to confirm what your source code has done, or try to 
replicate the current state in your source code.

I have not added tests for this because right now the use case for this is 
registers and those will have their own test cases to cover this. If we decide 
to expose this to formatters then this will need more testing.

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


7 Files Affected:

- (modified) lldb/include/lldb/Core/ValueObject.h (+7) 
- (modified) lldb/include/lldb/Symbol/CompilerType.h (+2-1) 
- (modified) lldb/include/lldb/Symbol/TypeSystem.h (+2-1) 
- (modified) lldb/source/DataFormatters/TypeFormat.cpp (+1-1) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (+14-7) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (+2-1) 
- (modified) lldb/source/Symbol/CompilerType.cpp (+3-2) 


``diff
diff --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index e7e35e2b2bffc0..36a6321428ec05 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -757,6 +757,12 @@ class ValueObject {
 
   AddressType GetAddressTypeOfChildren();
 
+  void SetEnumsAlwaysShowValue(bool always) {
+m_enums_always_show_value = always;
+  }
+
+  bool GetEnumsAlwaysShowValue() { return m_enums_always_show_value; }
+
   void SetHasCompleteType() {
 m_flags.m_did_calculate_complete_objc_class_type = true;
   }
@@ -889,6 +895,7 @@ class ValueObject {
   lldb::SyntheticChildrenSP m_synthetic_children_sp;
   ProcessModID m_user_id_of_forced_summary;
   AddressType m_address_type_of_ptr_or_ref_children = eAddressTypeInvalid;
+  bool m_enums_always_show_value = false;
 
   llvm::SmallVector m_value_checksum;
 
diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index b71c531f21633a..9e26e4c5f7b93d 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -490,7 +490,8 @@ class CompilerType {
   bool DumpTypeValue(Stream *s, lldb::Format format, const DataExtractor ,
  lldb::offset_t data_offset, size_t data_byte_size,
  uint32_t bitfield_bit_size, uint32_t bitfield_bit_offset,
- ExecutionContextScope *exe_scope);
+ ExecutionContextScope *exe_scope,
+ bool enums_always_show_value = false);
 
   /// Dump to stdout.
   void DumpTypeDescription(lldb::DescriptionLevel level =
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h 
b/lldb/include/lldb/Symbol/TypeSystem.h
index 3a927d313b823d..3395442f5b3f56 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -398,7 +398,8 @@ class TypeSystem : public PluginInterface,
  lldb::offset_t data_offset, size_t data_byte_size,
  uint32_t bitfield_bit_size,
  uint32_t bitfield_bit_offset,
- ExecutionContextScope *exe_scope) = 0;
+ ExecutionContextScope *exe_scope,
+ bool enums_always_show_value = false) = 0;
 
   /// Dump the type to stdout.
   virtual void DumpTypeDescription(
diff --git a/lldb/source/DataFormatters/TypeFormat.cpp 
b/lldb/source/DataFormatters/TypeFormat.cpp
index 409c452110bddc..2898b4394891c3 100644
--- a/lldb/source/DataFormatters/TypeFormat.cpp
+++ b/lldb/source/DataFormatters/TypeFormat.cpp
@@ -108,7 +108,7 @@ bool TypeFormatImpl_Format::FormatObject(ValueObject 
*valobj,
 *size,  // Byte size of item in "m_data"
 valobj->GetBitfieldBitSize(),   // Bitfield bit size
 valobj->GetBitfieldBitOffset(), // Bitfield bit offset
-exe_scope);
+exe_scope, valobj->GetEnumsAlwaysShowValue());
 // Given that we do not want to set the ValueObject's m_error for a
 // formatting error (or else we wouldn't be able to reformat until a
 // next update), an empty string is treated as a "false" return from
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 2621f682011b41..b1dbf7fbca1b92 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -8474,7 +8474,7 @@ void 

[Lldb-commits] [lldb] [lldb] Add ability to show enum as name and value at the same time (PR #90059)

2024-04-25 Thread David Spickett via lldb-commits

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

When an enum is used to represent certain data it can be useful to know its 
name and the value of it. For instance, register fields are often set in source 
code as numbers, but in the debugger you'd like to see the meaning as well.

(lldb) register read fpcr
fpcr = 0x
 = (... RMode = RN (0), ...)

Often you do just want the meaning but the value saves you having to manually 
decode it if you want to confirm what your source code has done, or try to 
replicate the current state in your source code.

I have not added tests for this because right now the use case for this is 
registers and those will have their own test cases to cover this. If we decide 
to expose this to formatters then this will need more testing.

>From afd2920071eeaf2237b232d69188d6e86ec082be Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Mon, 11 Mar 2024 10:18:51 +
Subject: [PATCH] [lldb] Add ability to show enum as name and value at the same
 time

When an enum is used to represent certain data it can be useful to know
its name and the value of it. For instance, register fields are
often set in source code as numbers, but in the debugger you'd like
to see the meaning as well.

(lldb) register read fpcr
fpcr = 0x
 = (... RMode = RN (0), ...)

Often you do just want the meaning but the value saves you having
to manually decode it if you want to confirm what your source code
has done, or try to replicate the current state in your source code.

I have not added tests for this because right now the use case for
this is registers and those will have their own test cases to cover
this. If we decide to expose this to formatters then this will need
more testing.
---
 lldb/include/lldb/Core/ValueObject.h  |  7 +++
 lldb/include/lldb/Symbol/CompilerType.h   |  3 ++-
 lldb/include/lldb/Symbol/TypeSystem.h |  3 ++-
 lldb/source/DataFormatters/TypeFormat.cpp |  2 +-
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 21 ---
 .../TypeSystem/Clang/TypeSystemClang.h|  3 ++-
 lldb/source/Symbol/CompilerType.cpp   |  5 +++--
 7 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index e7e35e2b2bffc0..36a6321428ec05 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -757,6 +757,12 @@ class ValueObject {
 
   AddressType GetAddressTypeOfChildren();
 
+  void SetEnumsAlwaysShowValue(bool always) {
+m_enums_always_show_value = always;
+  }
+
+  bool GetEnumsAlwaysShowValue() { return m_enums_always_show_value; }
+
   void SetHasCompleteType() {
 m_flags.m_did_calculate_complete_objc_class_type = true;
   }
@@ -889,6 +895,7 @@ class ValueObject {
   lldb::SyntheticChildrenSP m_synthetic_children_sp;
   ProcessModID m_user_id_of_forced_summary;
   AddressType m_address_type_of_ptr_or_ref_children = eAddressTypeInvalid;
+  bool m_enums_always_show_value = false;
 
   llvm::SmallVector m_value_checksum;
 
diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index b71c531f21633a..9e26e4c5f7b93d 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -490,7 +490,8 @@ class CompilerType {
   bool DumpTypeValue(Stream *s, lldb::Format format, const DataExtractor ,
  lldb::offset_t data_offset, size_t data_byte_size,
  uint32_t bitfield_bit_size, uint32_t bitfield_bit_offset,
- ExecutionContextScope *exe_scope);
+ ExecutionContextScope *exe_scope,
+ bool enums_always_show_value = false);
 
   /// Dump to stdout.
   void DumpTypeDescription(lldb::DescriptionLevel level =
diff --git a/lldb/include/lldb/Symbol/TypeSystem.h 
b/lldb/include/lldb/Symbol/TypeSystem.h
index 3a927d313b823d..3395442f5b3f56 100644
--- a/lldb/include/lldb/Symbol/TypeSystem.h
+++ b/lldb/include/lldb/Symbol/TypeSystem.h
@@ -398,7 +398,8 @@ class TypeSystem : public PluginInterface,
  lldb::offset_t data_offset, size_t data_byte_size,
  uint32_t bitfield_bit_size,
  uint32_t bitfield_bit_offset,
- ExecutionContextScope *exe_scope) = 0;
+ ExecutionContextScope *exe_scope,
+ bool enums_always_show_value = false) = 0;
 
   /// Dump the type to stdout.
   virtual void DumpTypeDescription(
diff --git a/lldb/source/DataFormatters/TypeFormat.cpp 
b/lldb/source/DataFormatters/TypeFormat.cpp
index 409c452110bddc..2898b4394891c3 100644
--- a/lldb/source/DataFormatters/TypeFormat.cpp
+++ b/lldb/source/DataFormatters/TypeFormat.cpp
@@ -108,7 +108,7 @@ bool TypeFormatImpl_Format::FormatObject(ValueObject 
*valobj,

[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)

2024-04-25 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)

2024-04-25 Thread Michael Buch via lldb-commits

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

LGTM

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


[Lldb-commits] [lldb] Add a new SBExpressionOptions::SetLanguage() API (NFCI) (PR #89981)

2024-04-25 Thread Michael Buch via lldb-commits


@@ -1203,26 +1203,23 @@ bool StackFrame::IsArtificial() const {
   return m_stack_frame_kind == StackFrame::Kind::Artificial;
 }
 
-lldb::LanguageType StackFrame::GetLanguage() {
+SourceLanguage StackFrame::GetLanguage() {
   CompileUnit *cu = GetSymbolContext(eSymbolContextCompUnit).comp_unit;
   if (cu)
 return cu->GetLanguage();
-  return lldb::eLanguageTypeUnknown;
+  return {};
 }
 
-lldb::LanguageType StackFrame::GuessLanguage() {
-  LanguageType lang_type = GetLanguage();
+SourceLanguage StackFrame::GuessLanguage() {
+  SourceLanguage lang_type = GetLanguage();
 
   if (lang_type == eLanguageTypeUnknown) {
-SymbolContext sc = GetSymbolContext(eSymbolContextFunction
-| eSymbolContextSymbol);
-if (sc.function) {
-  lang_type = sc.function->GetMangled().GuessLanguage();
-}
+SymbolContext sc =
+GetSymbolContext(eSymbolContextFunction | eSymbolContextSymbol);
+if (sc.function)
+  lang_type = LanguageType(sc.function->GetMangled().GuessLanguage());

Michael137 wrote:

This works because the `SourceLanguage(LanguageType)` constructor isn't marked 
explicit. Would it be clearer to mark it explicit and instead rewrite this as 
`SourceLanguage(sc.function->GetMangled().GuessLanguage())`

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


[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread David Spickett via lldb-commits


@@ -1,484 +1,49 @@
 # LLDB Platform Packets
 
-Here is a brief overview of the packets that an lldb platform server
+This is a list of the packets that an lldb platform server
 needs to implement for the lldb testsuite to be run on a remote
 target device/system.
 
 These are almost all lldb extensions to the gdb-remote serial
-protocol.  Many of the `vFile:` packets are also described in the "Host
+protocol. Many of the `vFile:` packets are also described in the "Host
 I/O Packets" detailed in the gdb-remote protocol documentation,
 although the lldb platform extensions include packets that are not
 defined there (`vFile:size:`, `vFile:mode:`, `vFile:symlink`, `vFile:chmod:`).
 
-Most importantly, the flags that lldb passes to `vFile:open:` are
-incompatible with the flags that gdb specifies.
-
-## QStartNoAckMode
-
-### Brief
-
-A request to stop sending ACK packets for each properly formatted packet.
-
-### Example
-
-A platform session will typically start like this:
-```
-receive: +$QStartNoAckMode#b0
-send:+   <-- ACKing the properly formatted QStartNoAckMode packet
-send:$OK#9a
-receive: +   <-- Our OK packet getting ACKed
-```
-
-ACK mode is now disabled.
-
-## qHostInfo
-
-### Brief
-
-Describe the hardware and OS of the target system
-
-### Example
-
-```
-receive: qHostInfo
-send:
cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5;
-```
-
-All numbers are base 10, `os_version` is a string that will be parsed as 
major.minor.patch.
-
-## qModuleInfo
-
-### Brief
-
-Get information for a module by given module path and architecture.
-
-The response is:
-* `(uuid|md5):...;triple:...;file_offset:...;file_size...;` or
-* `EXX` - for any errors
-
-### Example
-
-```
-receive: qModuleInfo:2f62696e2f6c73;
-```
-
-## qGetWorkingDir
-
-### Brief
-
-Get the current working directory of the platform stub in
-ASCII hex encoding.
-
-### Example
-
-```
-receive: qGetWorkingDir
-send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
-```
-
-## QSetWorkingDir
-
-### Brief
-
-Set the current working directory of the platform stub in
-ASCII hex encoding.
-
-### Example
-
-```
-receive: 
QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
-send:OK
-```
-
-## qPlatform_mkdir
-
-### Brief
-
-Create a directory on the target system.
-
-### Example
-
-```
-receive: qPlatform_mkdir:01fd,2f746d702f6131
-send:F0
-```
-
-request packet has the fields:
-   1. mode bits in base 16
-   2. file path in ASCII hex encoding
-
-response is F followed by the return value of the `mkdir()` call,
-base 16 encoded.
-
-## qPlatform_shell
-
-### Brief
-
-Run a shell command on the target system, return the output.
-
-### Example
-
-```
-receive: qPlatform_shell:6c73202f746d702f,000a
-send:F,0,0,
-```
-
-request packet has the fields:
-   1. shell command in ASCII hex encoding
-   2. timeout
-   3. working directory in ASCII hex encoding (optional)
-
-Response is `F` followed by the return value of the command (base 16),
-followed by another number, followed by the output of the command
-in binary-escaped-data encoding.
-
-## qLaunchGDBServer
-
-### Brief
-
-Start a gdbserver process (`gdbserver`, `debugserver`, `lldb-server`)
-on the target system.
-
-### Example
-
-```
-receive: qLaunchGDBServer;host:;
-send:pid:1337;port:43001;
-```
-
-Request packet hostname field is not ASCII hex encoded. Hostnames
-do not have `$` or `#` characters in them.
-
-Response to the packet is the pid of the newly launched gdbserver,
-and the port it is listening for a connection on.
-
-When the testsuite is running, lldb may use the pid to kill off a
-debugserver that doesn't seem to be responding, etc.
-
-## qKillSpawnedProcess
-
-### Brief
-
-Kill a process running on the target system.
-
-### Example
-
-```
-receive: qKillSpawnedProcess:1337
-send:OK
-```
-The request packet has the process ID in base 10.
-
-## qProcessInfoPID:
-
-### Brief
-
-Gather information about a process running on the target.
-
-### Example
-
-```
-receive: qProcessInfoPID:71964
-send:pid:71964;name:612e6f7574;
-```
-
-The request packet has the pid encoded in base 10.
-
-The reply has semicolon-separated `name:value` fields, two are
-shown here. `pid` is base 10 encoded. `name` is ascii hex encoded.
-lldb-server can reply with many additional fields, but this is probably
-enough for the testsuite.
-
-## qfProcessInfo
-
-### Brief
-
-Search the process table for processes matching criteria,
-respond with them in multiple packets.
-
-### Example
-
-```
-receive: 
qfProcessInfo:name_match:equals;name:6e6f70726f6365737365786973747377697468746869736e616d65;
-send:pid:3500;name:612e6f7574;
-```
-
-The request packet has a criteria to 

[Lldb-commits] [lldb] [lldb][Docs] Document vFile:exists and vFile:MD5 (PR #89357)

2024-04-25 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I forgot I didn't land this, so I will instead push a Markdown version of the 
same content once the other PRs have landed.

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


[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread David Spickett via lldb-commits

DavidSpickett wrote:

I'll remove the "Brief" subtitles after this.

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


[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread David Spickett via lldb-commits

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


[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/90029

>From 034efa46305f001092bbaacd563d9d2635ed49ed Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Wed, 24 Apr 2024 11:21:15 +0100
Subject: [PATCH 1/2] [lldb][Docs] Link from platform doc to extensions doc

So we aren't describing the same packets twice. Basically
turning the platform doc into a list of cross links.

qLaunchSuccess was missing a description so I added one.

The links will have text generated from the link title,
though they may not show up in GitHub's preview. Easier
than writing out all the names again though.
---
 lldb/docs/resources/lldbgdbremote.md   | 227 -
 lldb/docs/resources/lldbplatformpackets.md | 514 ++---
 2 files changed, 266 insertions(+), 475 deletions(-)

diff --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index cbe5c766d61eef..9a1032818af021 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -130,6 +130,21 @@ The above packet helps when you have remote debugging 
abilities where you
 could launch a process on a remote host, this isn't needed for bare board
 debugging.
 
+## qLaunchSuccess
+
+### Brief
+
+Check whether launching a process with the `A` packet succeeded.
+
+### Description
+
+Returns the status of the last attempt to launch a process.
+Either `OK` if no error ocurred, or `E` followed by a string
+describing the error.
+
+### Priority To Implement
+
+High, launching processes is a key part of LLDB's platform mode.
 
 ## QEnvironment:NAME=VALUE
 
@@ -263,6 +278,20 @@ QSetWorkingDir:
 ```
 This packet must be sent  _prior_ to sending a "A" packet.
 
+## qGetWorkingDir
+
+### Brief
+
+Get the current working directory of the platform stub in
+ASCII hex encoding.
+
+### Example
+
+```
+receive: qGetWorkingDir
+send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
+```
+
 ## QSetDisableASLR:\
 
 ### Brief
@@ -1029,13 +1058,17 @@ a remote host.
 
 Request: `qPlatform_mkdir:,`
 
+The request packet has the fields:
+   1. mode bits in base 16
+   2. file path in ascii-hex encoding
+
 Reply: 
   * `F`
 (mkdir called successfully and returned with the given return code)
   * `Exx` (An error occurred)
 
 
-## qPlatform_chmod
+## vFile:chmod / qPlatform_chmod
 
 ### Brief
 
@@ -1900,6 +1933,43 @@ send packet: $qsProcessInfo#00
 read packet: $E04#00
 ```
 
+## qPathComplete (Platform Extension)
+
+### Brief
+
+Get a list of matched disk files/directories by passing a boolean flag
+and a partial path.
+
+### Example
+
+```
+receive: qPathComplete:0,6d61696e
+send:M6d61696e2e637070
+receive: qPathComplete:1,746573
+send:M746573742f,74657374732f
+```
+
+If the first argument is zero, the result should contain all
+files (including directories) starting with the given path. If the
+argument is one, the result should contain only directories.
+
+The result should be a comma-separated list of hex-encoded paths.
+Paths denoting a directory should end with a directory separator (`/` or `\`.
+
+## qKillSpawnedProcess (Platform Extension)
+
+### Brief
+
+Kill a process running on the target system.
+
+### Example
+
+```
+receive: qKillSpawnedProcess:1337
+send:OK
+```
+The request packet has the process ID in base 10.
+
 ## qLaunchGDBServer (Platform Extension)
 
 ### Brief
@@ -2397,3 +2467,158 @@ STUB REPLIES: {"process_state_value":48,"process_state 
string":"dyld_process_sta
 Low. This packet is needed to prevent lldb's utility functions for
 scanning the Objective-C class list from running very early in
 process startup.
+
+## vFile Packets
+
+Though some of these may match the ones described in GDB's protocol
+documentation, we include our own expectations here in case of
+mismatches or extensions.
+
+### vFile:size
+
+ Brief
+
+Get the size of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:size:2f746d702f61
+send:Fc008
+```
+
+response is `F` followed by the file size in base 16.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:mode
+
+ Brief
+
+Get the mode bits of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:mode:2f746d702f61
+send:F1ed
+```
+
+response is `F` followed by the mode bits in base 16, this `0x1ed` would
+correspond to `0755` in octal.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:unlink
+
+ Brief
+
+Remove a file on the target system.
+
+ Example
+
+```
+receive: vFile:unlink:2f746d702f61
+send:F0
+```
+
+Argument is a file path in ascii-hex encoding.
+Response is `F` plus the return value of `unlink()`, base 16 encoding.
+Return value may optionally be followed by a comma and the base16
+value of errno if unlink failed.
+
+### vFile:symlink
+
+ Brief
+
+Create a symbolic link (symlink, 

[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)


Changes

So we aren't describing the same packets twice. Basically turning the platform 
doc into a list of cross links.

qLaunchSuccess was missing a description so I added one.

The links will have text generated from the link title, though they may not 
show up in GitHub's preview. Easier than writing out all the names again though.

---

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


2 Files Affected:

- (modified) lldb/docs/resources/lldbgdbremote.md (+226-1) 
- (modified) lldb/docs/resources/lldbplatformpackets.md (+40-474) 


``diff
diff --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index cbe5c766d61eef..9a1032818af021 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -130,6 +130,21 @@ The above packet helps when you have remote debugging 
abilities where you
 could launch a process on a remote host, this isn't needed for bare board
 debugging.
 
+## qLaunchSuccess
+
+### Brief
+
+Check whether launching a process with the `A` packet succeeded.
+
+### Description
+
+Returns the status of the last attempt to launch a process.
+Either `OK` if no error ocurred, or `E` followed by a string
+describing the error.
+
+### Priority To Implement
+
+High, launching processes is a key part of LLDB's platform mode.
 
 ## QEnvironment:NAME=VALUE
 
@@ -263,6 +278,20 @@ QSetWorkingDir:
 ```
 This packet must be sent  _prior_ to sending a "A" packet.
 
+## qGetWorkingDir
+
+### Brief
+
+Get the current working directory of the platform stub in
+ASCII hex encoding.
+
+### Example
+
+```
+receive: qGetWorkingDir
+send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
+```
+
 ## QSetDisableASLR:\
 
 ### Brief
@@ -1029,13 +1058,17 @@ a remote host.
 
 Request: `qPlatform_mkdir:,`
 
+The request packet has the fields:
+   1. mode bits in base 16
+   2. file path in ascii-hex encoding
+
 Reply: 
   * `F`
 (mkdir called successfully and returned with the given return code)
   * `Exx` (An error occurred)
 
 
-## qPlatform_chmod
+## vFile:chmod / qPlatform_chmod
 
 ### Brief
 
@@ -1900,6 +1933,43 @@ send packet: $qsProcessInfo#00
 read packet: $E04#00
 ```
 
+## qPathComplete (Platform Extension)
+
+### Brief
+
+Get a list of matched disk files/directories by passing a boolean flag
+and a partial path.
+
+### Example
+
+```
+receive: qPathComplete:0,6d61696e
+send:M6d61696e2e637070
+receive: qPathComplete:1,746573
+send:M746573742f,74657374732f
+```
+
+If the first argument is zero, the result should contain all
+files (including directories) starting with the given path. If the
+argument is one, the result should contain only directories.
+
+The result should be a comma-separated list of hex-encoded paths.
+Paths denoting a directory should end with a directory separator (`/` or `\`.
+
+## qKillSpawnedProcess (Platform Extension)
+
+### Brief
+
+Kill a process running on the target system.
+
+### Example
+
+```
+receive: qKillSpawnedProcess:1337
+send:OK
+```
+The request packet has the process ID in base 10.
+
 ## qLaunchGDBServer (Platform Extension)
 
 ### Brief
@@ -2397,3 +2467,158 @@ STUB REPLIES: {"process_state_value":48,"process_state 
string":"dyld_process_sta
 Low. This packet is needed to prevent lldb's utility functions for
 scanning the Objective-C class list from running very early in
 process startup.
+
+## vFile Packets
+
+Though some of these may match the ones described in GDB's protocol
+documentation, we include our own expectations here in case of
+mismatches or extensions.
+
+### vFile:size
+
+ Brief
+
+Get the size of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:size:2f746d702f61
+send:Fc008
+```
+
+response is `F` followed by the file size in base 16.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:mode
+
+ Brief
+
+Get the mode bits of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:mode:2f746d702f61
+send:F1ed
+```
+
+response is `F` followed by the mode bits in base 16, this `0x1ed` would
+correspond to `0755` in octal.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:unlink
+
+ Brief
+
+Remove a file on the target system.
+
+ Example
+
+```
+receive: vFile:unlink:2f746d702f61
+send:F0
+```
+
+Argument is a file path in ascii-hex encoding.
+Response is `F` plus the return value of `unlink()`, base 16 encoding.
+Return value may optionally be followed by a comma and the base16
+value of errno if unlink failed.
+
+### vFile:symlink
+
+ Brief
+
+Create a symbolic link (symlink, soft-link) on the target system.
+
+ Example
+
+```
+receive: vFile:symlink:,
+send:F0,0
+```

[Lldb-commits] [lldb] [lldb][Docs] Link from platform doc to extensions doc (PR #90029)

2024-04-25 Thread David Spickett via lldb-commits

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

So we aren't describing the same packets twice. Basically turning the platform 
doc into a list of cross links.

qLaunchSuccess was missing a description so I added one.

The links will have text generated from the link title, though they may not 
show up in GitHub's preview. Easier than writing out all the names again though.

>From 034efa46305f001092bbaacd563d9d2635ed49ed Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Wed, 24 Apr 2024 11:21:15 +0100
Subject: [PATCH] [lldb][Docs] Link from platform doc to extensions doc

So we aren't describing the same packets twice. Basically
turning the platform doc into a list of cross links.

qLaunchSuccess was missing a description so I added one.

The links will have text generated from the link title,
though they may not show up in GitHub's preview. Easier
than writing out all the names again though.
---
 lldb/docs/resources/lldbgdbremote.md   | 227 -
 lldb/docs/resources/lldbplatformpackets.md | 514 ++---
 2 files changed, 266 insertions(+), 475 deletions(-)

diff --git a/lldb/docs/resources/lldbgdbremote.md 
b/lldb/docs/resources/lldbgdbremote.md
index cbe5c766d61eef..9a1032818af021 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -130,6 +130,21 @@ The above packet helps when you have remote debugging 
abilities where you
 could launch a process on a remote host, this isn't needed for bare board
 debugging.
 
+## qLaunchSuccess
+
+### Brief
+
+Check whether launching a process with the `A` packet succeeded.
+
+### Description
+
+Returns the status of the last attempt to launch a process.
+Either `OK` if no error ocurred, or `E` followed by a string
+describing the error.
+
+### Priority To Implement
+
+High, launching processes is a key part of LLDB's platform mode.
 
 ## QEnvironment:NAME=VALUE
 
@@ -263,6 +278,20 @@ QSetWorkingDir:
 ```
 This packet must be sent  _prior_ to sending a "A" packet.
 
+## qGetWorkingDir
+
+### Brief
+
+Get the current working directory of the platform stub in
+ASCII hex encoding.
+
+### Example
+
+```
+receive: qGetWorkingDir
+send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
+```
+
 ## QSetDisableASLR:\
 
 ### Brief
@@ -1029,13 +1058,17 @@ a remote host.
 
 Request: `qPlatform_mkdir:,`
 
+The request packet has the fields:
+   1. mode bits in base 16
+   2. file path in ascii-hex encoding
+
 Reply: 
   * `F`
 (mkdir called successfully and returned with the given return code)
   * `Exx` (An error occurred)
 
 
-## qPlatform_chmod
+## vFile:chmod / qPlatform_chmod
 
 ### Brief
 
@@ -1900,6 +1933,43 @@ send packet: $qsProcessInfo#00
 read packet: $E04#00
 ```
 
+## qPathComplete (Platform Extension)
+
+### Brief
+
+Get a list of matched disk files/directories by passing a boolean flag
+and a partial path.
+
+### Example
+
+```
+receive: qPathComplete:0,6d61696e
+send:M6d61696e2e637070
+receive: qPathComplete:1,746573
+send:M746573742f,74657374732f
+```
+
+If the first argument is zero, the result should contain all
+files (including directories) starting with the given path. If the
+argument is one, the result should contain only directories.
+
+The result should be a comma-separated list of hex-encoded paths.
+Paths denoting a directory should end with a directory separator (`/` or `\`.
+
+## qKillSpawnedProcess (Platform Extension)
+
+### Brief
+
+Kill a process running on the target system.
+
+### Example
+
+```
+receive: qKillSpawnedProcess:1337
+send:OK
+```
+The request packet has the process ID in base 10.
+
 ## qLaunchGDBServer (Platform Extension)
 
 ### Brief
@@ -2397,3 +2467,158 @@ STUB REPLIES: {"process_state_value":48,"process_state 
string":"dyld_process_sta
 Low. This packet is needed to prevent lldb's utility functions for
 scanning the Objective-C class list from running very early in
 process startup.
+
+## vFile Packets
+
+Though some of these may match the ones described in GDB's protocol
+documentation, we include our own expectations here in case of
+mismatches or extensions.
+
+### vFile:size
+
+ Brief
+
+Get the size of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:size:2f746d702f61
+send:Fc008
+```
+
+response is `F` followed by the file size in base 16.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:mode
+
+ Brief
+
+Get the mode bits of a file on the target system, filename in ASCII hex.
+
+ Example
+
+```
+receive: vFile:mode:2f746d702f61
+send:F1ed
+```
+
+response is `F` followed by the mode bits in base 16, this `0x1ed` would
+correspond to `0755` in octal.
+`F-1,errno` with the errno if an error occurs, base 16.
+
+### vFile:unlink
+
+ Brief
+
+Remove a file on the target system.
+
+ Example
+
+```
+receive: 

[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)

2024-04-25 Thread David Spickett via lldb-commits

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


[Lldb-commits] [lldb] 51f6570 - [lldb][Docs] Convert platform packets doc to Markdown (#89913)

2024-04-25 Thread via lldb-commits

Author: David Spickett
Date: 2024-04-25T08:49:57+01:00
New Revision: 51f6570eba69b7030f2845e30b7973bd9ac6c522

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

LOG: [lldb][Docs] Convert platform packets doc to Markdown (#89913)

As before, script did most of the work, hand edits after that.

There's a lot more we can do dedupe this and the packets doc, this will
come in a follow up PR.

Added: 
lldb/docs/resources/lldbplatformpackets.md

Modified: 
lldb/docs/index.rst

Removed: 
lldb/docs/lldb-platform-packets.txt



diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 6906566ea55e58..7a27f6914fa89d 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -158,6 +158,7 @@ interesting areas to contribute to lldb.
resources/dataformatters
resources/extensions
resources/lldbgdbremote
+   resources/lldbplatformpackets
resources/caveats
resources/projects
Public C++ API 

diff  --git a/lldb/docs/lldb-platform-packets.txt 
b/lldb/docs/lldb-platform-packets.txt
deleted file mode 100644
index 4cf575e5ee8adb..00
--- a/lldb/docs/lldb-platform-packets.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-Here is a brief overview of the packets that an lldb platform server
-needs to implement for the lldb testsuite to be run on a remote
-target device/system.
-
-These are almost all lldb extensions to the gdb-remote serial
-protocol.  Many of the vFile: packets are described to the "Host
-I/O Packets" detailed in the gdb-remote protocol documentation,
-although the lldb platform extensions include packets that are not
-defined there (vFile:size:, vFile:mode:, vFile:symlink, vFile:chmod:).
-Most importantly, the flags that lldb passes to vFile:open: are 
-incompatible with the flags that gdb specifies.
-
-
-//--
-// QStartNoAckMode
-//
-// BRIEF
-//   A request to stop sending ACK packets for each properly formatted packet.
-//
-// EXAMPLE 
-//   A platform session will typically start like this:
-//
-//   receive: +$QStartNoAckMode#b0
-//   send:+   <-- ACKing the properly formatted QStartNoAckMode packet
-//   send:$OK#9a
-//   receive: +   <-- Our OK packet getting ACKed
-//
-//   ACK mode is now disabled.
-
-//--
-// qHostInfo
-//
-// BRIEF
-//   Describe the hardware and OS of the target system
-//
-// EXAMPLE
-//
-//  receive: qHostInfo
-//  send:
cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5;
-//
-//  All numbers are base 10, os_version is a string that will be parsed as 
major.minor.patch.
-
-//--
-// qModuleInfo
-//
-// BRIEF
-//   Report information about a binary on the target system
-//
-// EXAMPLE
-//  receive: qModuleInfo:2f62696e2f6c73;
-//
-// FIXME finish this packet description, v. 
GDBRemoteCommunicationServerCommon::Handle_qModuleInfo
-
-
-//--
-// qGetWorkingDir
-//
-// BRIEF
-//   Get the current working directory of the platform stub in
-//   ASCII hex encoding.
-//
-// EXAMPLE
-// 
-//  receive: qGetWorkingDir
-//  send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
-
-
-
-//--
-// QSetWorkingDir:
-//
-// BRIEF
-//   Set the current working directory of the platform stub in
-//   ASCII hex encoding.
-//
-// EXAMPLE
-// 
-//  receive: 
QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
-//  send:OK
-
-//--
-// qPlatform_mkdir:
-//
-// BRIEF
-//   Create a directory on the target system.
-//
-// EXAMPLE
-// 
-//  receive: qPlatform_mkdir:01fd,2f746d702f6131
-//  send:F0
-//
-//  request packet has the fields:
-// 1. mode bits in base 16
-// 2. file path in ascii-hex encoding
-//
-//  response is F followed by the return value of the mkdir() call,
-//  base 16 encoded.
-
-//--
-// qPlatform_shell:
-//
-// BRIEF
-//   Run a shell command on the target system, return the output.
-//
-// EXAMPLE
-// 
-//  receive: qPlatform_shell:6c73202f746d702f,000a
-//  send:F,0,0,
-//
-//  request packet has the fields:
-// 1. shell command ascii-hex encoded
-// 2. timeout 
-// 3. 

[Lldb-commits] [lldb] [lldb][Docs] Convert platform packets doc to Markdown (PR #89913)

2024-04-25 Thread David Spickett via lldb-commits

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/89913

>From d9b8ee42dfb753012f2f7032d7fb2dfde3e440f0 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Wed, 24 Apr 2024 10:21:08 +0100
Subject: [PATCH 1/3] [lldb][Docs] Make formatting in platform packet doc
 regular

---
 lldb/docs/lldb-platform-packets.txt | 66 ++---
 1 file changed, 42 insertions(+), 24 deletions(-)

diff --git a/lldb/docs/lldb-platform-packets.txt 
b/lldb/docs/lldb-platform-packets.txt
index 4cf575e5ee8adb..62c3e38d9521ac 100644
--- a/lldb/docs/lldb-platform-packets.txt
+++ b/lldb/docs/lldb-platform-packets.txt
@@ -26,6 +26,7 @@ incompatible with the flags that gdb specifies.
 //   receive: +   <-- Our OK packet getting ACKed
 //
 //   ACK mode is now disabled.
+//--
 
 //--
 // qHostInfo
@@ -39,6 +40,7 @@ incompatible with the flags that gdb specifies.
 //  send:
cputype:16777228;cpusubtype:1;ostype:ios;watchpoint_exceptions_received:before;os_version:12.1;vendor:apple;default_packet_timeout:5;
 //
 //  All numbers are base 10, os_version is a string that will be parsed as 
major.minor.patch.
+//--
 
 //--
 // qModuleInfo
@@ -50,6 +52,7 @@ incompatible with the flags that gdb specifies.
 //  receive: qModuleInfo:2f62696e2f6c73;
 //
 // FIXME finish this packet description, v. 
GDBRemoteCommunicationServerCommon::Handle_qModuleInfo
+//--
 
 
 //--
@@ -63,11 +66,12 @@ incompatible with the flags that gdb specifies.
 // 
 //  receive: qGetWorkingDir
 //  send:
2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
+//--
 
 
 
 //--
-// QSetWorkingDir:
+// QSetWorkingDir
 //
 // BRIEF
 //   Set the current working directory of the platform stub in
@@ -77,9 +81,10 @@ incompatible with the flags that gdb specifies.
 // 
 //  receive: 
QSetWorkingDir:2f4170706c65496e7465726e616c2f6c6c64622f73657474696e67732f342f5465737453657474696e67732e746573745f646973617373656d626c65725f73657474696e6773
 
 //  send:OK
+//--
 
 //--
-// qPlatform_mkdir:
+// qPlatform_mkdir
 //
 // BRIEF
 //   Create a directory on the target system.
@@ -95,9 +100,10 @@ incompatible with the flags that gdb specifies.
 //
 //  response is F followed by the return value of the mkdir() call,
 //  base 16 encoded.
+//--
 
 //--
-// qPlatform_shell:
+// qPlatform_shell
 //
 // BRIEF
 //   Run a shell command on the target system, return the output.
@@ -114,7 +120,8 @@ incompatible with the flags that gdb specifies.
 //
 //  Response is F followed by the return value of the command (base 16),
 //  followed by another number, followed by the output of the command
-/   in binary-escaped-data encoding.
+//   in binary-escaped-data encoding.
+//--
 
 //--
 // qLaunchGDBServer
@@ -136,9 +143,10 @@ incompatible with the flags that gdb specifies.
 //
 //  When the testsuite is running, lldb may use the pid to kill off a 
 //  debugserver that doesn't seem to be responding, etc.
+//--
 
 //--
-// qKillSpawnedProcess:
+// qKillSpawnedProcess
 //
 // BRIEF
 //   Kill a process running on the target system.
@@ -149,6 +157,7 @@ incompatible with the flags that gdb specifies.
 //  send:OK
 //
 //  The request packet has the process ID in base 10.
+//--
 
 //--
 // qProcessInfoPID:
@@ -167,9 +176,10 @@ incompatible with the flags that gdb specifies.
 //  shown here.  pid is base 10 encoded.  name is ascii hex encoded.
 //  lldb-server can reply with many additional fields, but I think
 //  this is enough for the testsuite.
+//--
 
 //--
-// qfProcessInfo:
+// qfProcessInfo
 //
 // BRIEF
 //   

[Lldb-commits] [lldb] [lldb] Add SB API to access static constexpr member values (PR #89730)

2024-04-25 Thread Pavel Labath via lldb-commits

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


[Lldb-commits] [lldb] 565bdb5 - [lldb] Add SB API to access static constexpr member values (#89730)

2024-04-25 Thread via lldb-commits

Author: Pavel Labath
Date: 2024-04-25T09:06:48+02:00
New Revision: 565bdb55453f0bdd59d9325b8a748cb42e6df95b

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

LOG: [lldb] Add SB API to access static constexpr member values (#89730)

The main change is the addition of a new SBTypeStaticField class,
representing a static member of a class. It can be retrieved created
through SBType::GetStaticFieldWithName. It contains several methods
(GetName, GetMangledName, etc.) whose meaning is hopefully obvious. The
most interesting method is
lldb::SBValue GetConstantValue(lldb::SBTarget)
which returns a the value of the field -- if it is a compile time
constant. The reason for that is that only constants have their values
represented in the clang AST.

For non-constants, we need to go back to the module containing that
constant, and ask retrieve the associated ValueObjectVariable. That's
easy enough if the we are still in the type system of the module
(because then the type system will contain the pointer to the module
symbol file), but it's hard when the type has been copied into another
AST (e.g. during expression evaluation). To do that we would need to
walk the ast import chain backwards to find the source TypeSystem, and I
haven't found a nice way to do that.

Another possibility would be to use the mangled name of the variable to
perform a lookup (in all modules). That is sort of what happens when
evaluating the variable in an expression (which does work), but I did
not want to commit to that implementation as it's not necessary for my
use case (and if anyone wants to, he can use the GetMangledName function
and perform the lookup manually).

The patch adds a couple of new TypeSystem functions to surface the
information needed to implement this functionality.

Added: 


Modified: 
lldb/include/lldb/API/SBTarget.h
lldb/include/lldb/API/SBType.h
lldb/include/lldb/API/SBValue.h
lldb/include/lldb/Symbol/CompilerDecl.h
lldb/include/lldb/Symbol/CompilerType.h
lldb/include/lldb/Symbol/TypeSystem.h
lldb/source/API/SBType.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
lldb/source/Symbol/CompilerDecl.cpp
lldb/source/Symbol/CompilerType.cpp
lldb/test/API/python_api/type/TestTypeList.py
lldb/test/API/python_api/type/main.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBTarget.h 
b/lldb/include/lldb/API/SBTarget.h
index 3644ac056da3dc..823615e6a36df5 100644
--- a/lldb/include/lldb/API/SBTarget.h
+++ b/lldb/include/lldb/API/SBTarget.h
@@ -954,6 +954,7 @@ class LLDB_API SBTarget {
   friend class SBSection;
   friend class SBSourceManager;
   friend class SBSymbol;
+  friend class SBTypeStaticField;
   friend class SBValue;
   friend class SBVariablesOptions;
 

diff  --git a/lldb/include/lldb/API/SBType.h b/lldb/include/lldb/API/SBType.h
index 9980fe1218305b..5b9ff2170b2b24 100644
--- a/lldb/include/lldb/API/SBType.h
+++ b/lldb/include/lldb/API/SBType.h
@@ -107,6 +107,35 @@ class SBTypeMemberFunction {
   lldb::TypeMemberFunctionImplSP m_opaque_sp;
 };
 
+class LLDB_API SBTypeStaticField {
+public:
+  SBTypeStaticField();
+
+  SBTypeStaticField(const lldb::SBTypeStaticField );
+  lldb::SBTypeStaticField =(const lldb::SBTypeStaticField );
+
+  ~SBTypeStaticField();
+
+  explicit operator bool() const;
+
+  bool IsValid() const;
+
+  const char *GetName();
+
+  const char *GetMangledName();
+
+  lldb::SBType GetType();
+
+  lldb::SBValue GetConstantValue(lldb::SBTarget target);
+
+protected:
+  friend class SBType;
+
+  explicit SBTypeStaticField(lldb_private::CompilerDecl decl);
+
+  std::unique_ptr m_opaque_up;
+};
+
 class SBType {
 public:
   SBType();
@@ -182,6 +211,8 @@ class SBType {
 
   lldb::SBTypeMember GetVirtualBaseClassAtIndex(uint32_t idx);
 
+  lldb::SBTypeStaticField GetStaticFieldWithName(const char *name);
+
   lldb::SBTypeEnumMemberList GetEnumMembers();
 
   uint32_t GetNumberOfTemplateArguments();
@@ -242,6 +273,7 @@ class SBType {
   friend class SBTypeNameSpecifier;
   friend class SBTypeMember;
   friend class SBTypeMemberFunction;
+  friend class SBTypeStaticField;
   friend class SBTypeList;
   friend class SBValue;
   friend class SBWatchpoint;

diff  --git a/lldb/include/lldb/API/SBValue.h b/lldb/include/lldb/API/SBValue.h
index bbcccaab51aaee..67f55ce7da2877 100644
--- a/lldb/include/lldb/API/SBValue.h
+++ b/lldb/include/lldb/API/SBValue.h
@@ -426,6 +426,7 @@ class LLDB_API SBValue {
   friend class SBModule;
   friend class SBTarget;
   friend class SBThread;
+  friend class SBTypeStaticField;
   friend class SBTypeSummary;
   friend class SBValueList;
 

diff  --git a/lldb/include/lldb/Symbol/CompilerDecl.h