[Lldb-commits] [lldb] [lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation (PR #161688)

2025-10-10 Thread Michael Buch via lldb-commits 

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/161688

>From 7300143d42a2a496d5ce522c7f862cb458fa6d9d Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 2 Oct 2025 16:24:12 +0100
Subject: [PATCH 1/9] [lldb][Expression] Emit a 'Note' diagnistc that indicates
 the language used for expression evaluation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite clear
what language the expression ran as. It may also reduce confusion around
why the expression evaluator ran an expression in a language it wasn't
asked to run (a softer alternative to what I attempted in 
https://github.com/llvm/llvm-project/pull/156648).

Here are some example outputs:
```
(lldb) expr -l c -- blah
˄
╰─ error: use of undeclared identifier 'blah'
note: Requested expression evaluation as 'c' but fell back to 'c++'.
(lldb) expr -l c++ -- blah
  ˄
  ╰─ error: use of undeclared identifier 'blah'
note: Requested expression evaluation as c++
(lldb) expr -l objc -- blah
   ˄
   ╰─ error: use of undeclared identifier 'blah'
note: Requested expression evaluation as 'objective-c' but fell back to 
'objective-c++'.
(lldb) expr -l rust -- blah
   ˄
   ╰─ error: use of undeclared identifier 'blah'
note: Requested expression evaluation as rust
```

I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.

Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).

rdar://160297649
---
 .../Clang/ClangExpressionParser.cpp   | 29 ---
 .../Clang/ClangExpressionParser.h |  1 +
 .../Clang/ClangFunctionCaller.cpp |  4 +--
 .../Clang/ClangUserExpression.cpp |  4 +--
 .../Clang/ClangUtilityFunction.cpp|  2 +-
 5 files changed, 31 insertions(+), 9 deletions(-)

diff --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
index 3c49c911108a3..b3aebfcc77039 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -74,6 +74,7 @@
 #include "lldb/Core/Debugger.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/Module.h"
+#include "lldb/Expression/DiagnosticManager.h"
 #include "lldb/Expression/IRExecutionUnit.h"
 #include "lldb/Expression/IRInterpreter.h"
 #include "lldb/Host/File.h"
@@ -527,7 +528,8 @@ static void SetupTargetOpts(CompilerInstance &compiler,
 
 static void SetupLangOpts(CompilerInstance &compiler,
   ExecutionContextScope &exe_scope,
-  const Expression &expr) {
+  const Expression &expr,
+  DiagnosticManager &diagnostic_manager) {
   Log *log = GetLog(LLDBLog::Expressions);
 
   // If the expression is being evaluated in the context of an existing stack
@@ -547,6 +549,8 @@ static void SetupLangOpts(CompilerInstance &compiler,
  : lldb::eLanguageTypeUnknown),
 lldb_private::Language::GetNameForLanguageType(language));
 
+  lldb::LanguageType language_for_note = language;
+
   LangOptions &lang_opts = compiler.getLangOpts();
 
   switch (language) {
@@ -560,12 +564,14 @@ static void SetupLangOpts(CompilerInstance &compiler,
 // family language, because the expression parser uses features of C++ to
 // capture values.
 lang_opts.CPlusPlus = true;
+language_for_note = lldb::eLanguageTypeC_plus_plus;
 break;
   case lldb::eLanguageTypeObjC:
 lang_opts.ObjC = true;
 // FIXME: the following language option is a temporary workaround,
 // to "ask for ObjC, get ObjC++" (see comment above).
 lang_opts.CPlusPlus = true;
+language_for_note = lldb::eLanguageTypeObjC_plus_plus;
 
 // Clang now sets as default C++14 as the default standard (with
 // GNU extensions), so we do the same here to avoid mismatches that
@@ -610,6 +616,21 @@ static void SetupLangOpts(CompilerInstance &compiler,
 brea

[Lldb-commits] [lldb] [LLDB] Fix `GetIndexOfChildMemberWithName` to handle anonymous struct in base classes (PR #158256)

2025-10-10 Thread Michael Buch via lldb-commits 

https://github.com/Michael137 commented:

I have the suspicion that this could be done simpler.

`CXXRecordDecl::lookupInBases` is already perfectly capable of finding field in 
anonymous structures in bases. That's why the expression evaluator is able to 
find them just fine.

I think the actual problem lies in our logic that iterates the `CXXBasePaths` 
after the `lookupInBases` lookup.

The field of the anonymous structure *is found* by `lookupInBases`. It is an 
`IndirectFieldDecl`. But we fail to extract it in:
```
  for (clang::DeclContext::lookup_iterator I = path->Decls, E;
   I != E; ++I) {
child_idx = GetIndexForRecordChild(
parent_record_decl, *I, omit_empty_base_classes);
if (child_idx == UINT32_MAX) {
  child_indexes.clear();
  return 0;
```

Here `GetIndexForRecordChild` doesn't correctly get the index of the 
`IndirectFieldDecl`:

```
   6702   clang::RecordDecl::field_iterator field, field_end;   
  
   6703   for (field = record_decl->field_begin(), field_end = 
record_decl->field_end();  
   6704field != field_end; ++field, ++child_idx) {  
  
-> 6705 if (field->getCanonicalDecl() == canonical_decl)
  
   6706   return child_idx; 
  
   6707   } 
  
   6708 
  
   6709   return UINT32_MAX;
  
   6710 }   
  
   6711 
  
   6712 // Look for a child member (doesn't include base classes, but it does 
include 
   6713 // their members) in the type hierarchy. Returns an index path into 
  
   6714 // "clang_type" on how to reach the appropriate member. 
  
   6715 //  
  
Target 0: (lldb) stopped.   
  
(lldb) p field->getCanonicalDecl()->dump()  
  
FieldDecl 0x7e9f01418 <>  implicit 
'Base::(anonymous struct)' 
(lldb) p canonical_decl->dump() 
  
IndirectFieldDecl 0x7e9f014c8 <>  implicit x 'int'  
  
|-Field 0x7e9f01418 field_index 0 'Base::(anonymous struct)'
  
`-Field 0x7e9f013c0 'x' 'int'   
  
```

I haven't fully thought this through, but could we adjust 
`GetIndexForRecordChild` to look into unwrap the anonymous union?

We can fish out the underlying `FieldDecl`s in both cases:
```
(lldb) p ((clang::IndirectFieldDecl*)canonical_decl)->getAnonField()
(clang::FieldDecl *) 0x000c563293c0
(lldb) p field->getType()->getAsCXXRecordDecl()->field_begin()
(clang::RecordDecl::field_iterator) {
  Current = {
Current = 0x000c563293c0
  }
}
(lldb) p field->getType()->getAsCXXRecordDecl()->field_begin()->dump()
FieldDecl 0xc563293c0 <>  x 'int'
```

So in pseudo-code, maybe the function could look something like:
```
uint32_t TypeSystemClang::GetIndexForRecordChild(
const clang::RecordDecl *record_decl, clang::NamedDecl *canonical_decl,
bool omit_empty_base_classes) {
  uint32_t child_idx = TypeSystemClang::GetNumBaseClasses(
  llvm::dyn_cast(record_decl),
  omit_empty_base_classes);

  clang::RecordDecl::field_iterator field, field_end;
  for (field = record_decl->field_begin(), field_end = record_decl->field_end();
   field != field_end; ++field, ++child_idx) {
IndirectFieldDecl * indirect_decl = 
llvm::dyn_cast(canonical_decl);
if (field is unnamed && indirect_decl) {
  for (anon_field : fields of anonymous structure)
 if (anon_field == canonical_decl->getAnonField())
return child_idx;
} else if (field == canonical_decl)
  return child_idx;
  }

  return UINT32_MAX;
}
```
Might need to adjust the `child_idx` calculation here. But hopefully that 
conveys the overall idea.

Let me know if you have any questions or if you think this doesn't work

https://github.com/llvm/llvm-project/pull/158256
___
lldb-commits mailing list
[email protected]
https://lists.llv

[Lldb-commits] [lldb] [LLDB] Fix `GetIndexOfChildMemberWithName` to handle anonymous struct in base classes (PR #158256)

2025-10-10 Thread Michael Buch via lldb-commits 

https://github.com/Michael137 edited 
https://github.com/llvm/llvm-project/pull/158256
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Fix `GetIndexOfChildMemberWithName` to handle anonymous struct in base classes (PR #158256)

2025-10-10 Thread Michael Buch via lldb-commits 

https://github.com/Michael137 edited 
https://github.com/llvm/llvm-project/pull/158256
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB, x86, FreeBSD] Fix Architecture parsing by reading the ELF header. (PR #162811)

2025-10-10 Thread David Spickett via lldb-commits 

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

LGTM, I see that NetBSD and Linux do this too.

Though I doubt whether debugging works on those platforms either, and I don't 
think we have upstream tests for it so I won't demand them here.

This change applies to AArch64 as well, right? At least the code is generic, 
maybe AArch32 binaries aren't allowed on AArch64 FreeBSD.

If you do get this working overall, I would like to see tests that run on 
Linux. If it's not a massive amount of work I can help fix Linux, if it is 
though, FreeBSD only test case would be fine. I'll take something over nothing.

https://github.com/llvm/llvm-project/pull/162811
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][windows] add support for out of PATH python.dll resolution (PR #162509)

2025-10-10 Thread Martin Storsjö via lldb-commits 


@@ -167,6 +167,12 @@ function(add_lldb_executable name)
   )
 
   target_link_libraries(${name} PRIVATE ${ARG_LINK_LIBS})
+  if(WIN32)
+list(FIND ARG_LINK_LIBS liblldb LIBLLDB_INDEX)
+if(NOT LIBLLDB_INDEX EQUAL -1)
+  target_link_options(${name} PRIVATE 
"/DELAYLOAD:$.dll")

mstorsjo wrote:

Any particular reason for using `$.dll` rather 
than the more straightforward `$`?

This patch broke compilation for mingw targets, as these options are specific 
to the MSVC style build case - and for that case, the DLL name we'd like to 
pass here has a `lib` prefix, i.e. `liblldb.dll`, not `lldb.dll`. So instead of 
trying to manually reapply a prefix and add `.dll` at the end, it seems more 
straightforward to me to just use `$` which should 
give the right string in both cases?

https://github.com/llvm/llvm-project/pull/162509
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][windows] add support for out of PATH python.dll resolution (PR #162509)

2025-10-10 Thread Martin Storsjö via lldb-commits 

mstorsjo wrote:

> This, combined with `liblldb.dll` being delay loaded, allows to package 
> `python.dll` with the `llvm` installer.

Just for reference - for llvm-mingw, we've been bundling a python install in 
our toolchain as well, but we've solved this slightly differently. We've just 
copied `python.dll` (but nothing else from the Python install) into the LLVM 
tool `bin` directory. That, together with the `LLDB_PYTHON_HOME` flag, has been 
enough for finding the bundled python install in a different directory. This 
solution is kinda neat though, and would allow skipping copying the 
`python.dll`.

https://github.com/llvm/llvm-project/pull/162509
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [cmake] Fix delayloading liblldb.dll in mingw builds (PR #162831)

2025-10-10 Thread via lldb-commits 

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Martin Storsjö (mstorsjo)


Changes

ec28b95b7491bc2fbb6ec66cdbfd939e71255c42 made liblldb delayloaded, but the 
supplied command line parameter is only valid for MSVC style builds.

For mingw builds using LLD, we can easily pass a similar option. For mingw 
builds with ld.bfd, we can't quite as easily delayload it - for these cases, 
just keep linking it like we usually do, and warn if the user tried to set 
LLDB_PYTHON_DLL_RELATIVE_PATH in a build where it won't have any effect.

Also change the setting for MSVC style builds, to use the simpler 
`$` instead of 
`$.dll`. The former pattern is what we use 
for mingw targets, and it makes the code clearer to use that for both, as that 
same expression should do the right thing for both.

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


1 Files Affected:

- (modified) lldb/cmake/modules/AddLLDB.cmake (+13-1) 


``diff
diff --git a/lldb/cmake/modules/AddLLDB.cmake b/lldb/cmake/modules/AddLLDB.cmake
index bdd6f73238422..5d58abf237f58 100644
--- a/lldb/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -170,7 +170,19 @@ function(add_lldb_executable name)
   if(WIN32)
 list(FIND ARG_LINK_LIBS liblldb LIBLLDB_INDEX)
 if(NOT LIBLLDB_INDEX EQUAL -1)
-  target_link_options(${name} PRIVATE 
"/DELAYLOAD:$.dll")
+  if (MSVC)
+target_link_options(${name} PRIVATE 
"/DELAYLOAD:$")
+  elseif (MINGW AND LINKER_IS_LLD)
+# LLD can delay load just by passing a --delayload flag, as long as 
the import
+# library is a short type import library (which LLD and MS link.exe 
produce).
+# With ld.bfd, with long import libraries (as produced by GNU 
binutils), one
+# has to generate a separate delayload import library with dlltool.
+target_link_options(${name} PRIVATE 
"-Wl,--delayload=$")
+  elseif (DEFINED LLDB_PYTHON_DLL_RELATIVE_PATH)
+# If liblldb can't be delayloaded, then LLDB_PYTHON_DLL_RELATIVE_PATH 
will not
+# have any effect.
+message(WARNING "liblldb is not delay loaded, 
LLDB_PYTHON_DLL_RELATIVE_PATH has no effect")
+  endif()
 endif()
   endif()
   if(CLANG_LINK_CLANG_DYLIB)

``




https://github.com/llvm/llvm-project/pull/162831
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] Allow empty memory reference in disassemble arguments (PR #162517)

2025-10-10 Thread Sergei Druzhkov via lldb-commits 

https://github.com/DrSergei updated 
https://github.com/llvm/llvm-project/pull/162517

>From 3d548533d38277eb2ba59c810f7634909bb7adbd Mon Sep 17 00:00:00 2001
From: Druzhkov Sergei 
Date: Wed, 8 Oct 2025 11:38:55 +0300
Subject: [PATCH 1/2] [lldb-dap] Allow empty memory reference in disassemble
 arguments

---
 .../disassemble/TestDAP_disassemble.py| 22 +++
 .../Handler/DisassembleRequestHandler.cpp |  5 +
 lldb/tools/lldb-dap/JSONUtils.cpp |  7 +-
 lldb/tools/lldb-dap/JSONUtils.h   |  5 -
 .../lldb-dap/Protocol/ProtocolRequests.cpp|  2 +-
 5 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/lldb/test/API/tools/lldb-dap/disassemble/TestDAP_disassemble.py 
b/lldb/test/API/tools/lldb-dap/disassemble/TestDAP_disassemble.py
index 0562f20335a23..6c41c86ff9ae5 100644
--- a/lldb/test/API/tools/lldb-dap/disassemble/TestDAP_disassemble.py
+++ b/lldb/test/API/tools/lldb-dap/disassemble/TestDAP_disassemble.py
@@ -91,3 +91,25 @@ def test_disassemble_backwards(self):
 # clear breakpoints
 self.set_source_breakpoints(source, [])
 self.continue_to_exit()
+
+def test_disassemble_empty_memory_reference(self):
+"""
+Tests the 'disassemble' request with empty memory reference.
+"""
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+source = "main.c"
+bp_line_no = line_number(source, "// breakpoint 1")
+self.set_source_breakpoints(source, [bp_line_no])
+self.continue_to_next_stop()
+
+instructions = self.dap_server.request_disassemble(
+memoryReference="", instructionOffset=0, instructionCount=50
+)
+self.assertEqual(len(instructions), 50)
+for instruction in instructions:
+self.assertEqual(instruction["presentationHint"], "invalid")
+
+# clear breakpoints
+self.set_source_breakpoints(source, [])
+self.continue_to_exit()
diff --git a/lldb/tools/lldb-dap/Handler/DisassembleRequestHandler.cpp 
b/lldb/tools/lldb-dap/Handler/DisassembleRequestHandler.cpp
index 9542f091b055e..6d2eb74a9634c 100644
--- a/lldb/tools/lldb-dap/Handler/DisassembleRequestHandler.cpp
+++ b/lldb/tools/lldb-dap/Handler/DisassembleRequestHandler.cpp
@@ -182,6 +182,11 @@ static DisassembledInstruction 
ConvertSBInstructionToDisassembledInstruction(
 /// `supportsDisassembleRequest` is true.
 llvm::Expected
 DisassembleRequestHandler::Run(const DisassembleArguments &args) const {
+  if (args.memoryReference == LLDB_INVALID_ADDRESS) {
+std::vector invalid_instructions(
+args.instructionCount, GetInvalidInstruction());
+return DisassembleResponseBody{std::move(invalid_instructions)};
+  }
   const lldb::addr_t addr_ptr = args.memoryReference + args.offset;
   lldb::SBAddress addr(addr_ptr, dap.target);
   if (!addr.IsValid())
diff --git a/lldb/tools/lldb-dap/JSONUtils.cpp 
b/lldb/tools/lldb-dap/JSONUtils.cpp
index 4f26599a49bac..c00e39c86b92a 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -122,7 +122,7 @@ DecodeMemoryReference(llvm::StringRef memoryReference) {
 
 bool DecodeMemoryReference(const llvm::json::Value &v, llvm::StringLiteral key,
lldb::addr_t &out, llvm::json::Path path,
-   bool required) {
+   bool required, bool allow_empty) {
   const llvm::json::Object *v_obj = v.getAsObject();
   if (!v_obj) {
 path.report("expected object");
@@ -145,6 +145,11 @@ bool DecodeMemoryReference(const llvm::json::Value &v, 
llvm::StringLiteral key,
 return false;
   }
 
+  if (allow_empty && mem_ref_str->empty()) {
+out = LLDB_INVALID_ADDRESS;
+return true;
+  }
+
   const std::optional addr_opt =
   DecodeMemoryReference(*mem_ref_str);
   if (!addr_opt) {
diff --git a/lldb/tools/lldb-dap/JSONUtils.h b/lldb/tools/lldb-dap/JSONUtils.h
index e9094f67b94ec..b8187fe988350 100644
--- a/lldb/tools/lldb-dap/JSONUtils.h
+++ b/lldb/tools/lldb-dap/JSONUtils.h
@@ -156,11 +156,14 @@ DecodeMemoryReference(llvm::StringRef memoryReference);
 ///Indicates if the key is required to be present, otherwise report an 
error
 ///if the key is missing.
 ///
+/// \param[in] allow_empty
+///Interpret empty string as a valid value, don't report an error.
+///
 /// \return
 ///Returns \b true if the address was decoded successfully.
 bool DecodeMemoryReference(const llvm::json::Value &v, llvm::StringLiteral key,
lldb::addr_t &out, llvm::json::Path path,
-   bool required);
+   bool required, bool allow_empty = false);
 
 /// Extract an array of strings for the specified key from an object.
 ///
diff --git a/lldb/tools/lldb-dap/Protocol/ProtocolRequests.cpp 
b/lldb/tools/lldb-dap/Protocol/ProtocolRequests.cpp
index b455112cd37d9..fc046d18825ec 100644
--- a/lldb/tools/lldb-

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

2025-10-10 Thread David Spickett via lldb-commits 


@@ -789,6 +789,10 @@ def canRunLibcxxTests():
 return True, "libc++ always present"
 
 if platform == "linux":
+if not configuration.libcxx_include_dir or not 
configuration.libcxx_library_dir:
+return False, "API tests require a locally built libc++."

DavidSpickett wrote:

This gets printed somewhere right? I forget where it appears.

https://github.com/llvm/llvm-project/pull/162657
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

2025-10-10 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

> --category libc++

It shows 68 skipped, did you paste the wrong output?

https://github.com/llvm/llvm-project/pull/162657
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB, x86, FreeBSD] Fix Architecture parsing by reading the ELF header. (PR #162811)

2025-10-10 Thread via lldb-commits 

aokblast wrote:

> I can merge this if you need me to.

Sure. Thanks for your help!

https://github.com/llvm/llvm-project/pull/162811
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

2025-10-10 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

> As in, I wanted to show that the simluators aren't part of the libc++ 
> category :p

Ok I see now. You enabled only that category, to show that no simulator test 
falls into it. Rather than disabling the category, to show that all the 
simulator tests ran (because how would I know exactly how many there are).

:+1: 

https://github.com/llvm/llvm-project/pull/162657
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libunwind] [lldb] [llvm] [openmp] Fix typos: 'auxilliary' to 'auxiliary' and 'unit64_t' to 'uint64_t' (PR #161955)

2025-10-10 Thread via lldb-commits 

https://github.com/smallzhong closed 
https://github.com/llvm/llvm-project/pull/161955
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add a missing include. NFC. (PR #162809)

2025-10-10 Thread Martin Storsjö via lldb-commits 

https://github.com/mstorsjo closed 
https://github.com/llvm/llvm-project/pull/162809
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB, x86, FreeBSD] Fix Architecture parsing by reading the ELF header. (PR #162811)

2025-10-10 Thread David Spickett via lldb-commits 

DavidSpickett wrote:

My impression is that 32-bit executables are much more common on x86. To the 
point where there are standard flags like `-m32`, which we do not have for 
AArch64/AArch32.

https://github.com/llvm/llvm-project/pull/162811
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libunwind] [lldb] [llvm] [openmp] Fix typos: 'auxilliary' to 'auxiliary' and 'unit64_t' to 'uint64_t' (PR #161955)

2025-10-10 Thread via lldb-commits 

smallzhong wrote:

Sorry, I accidentally created a pull request for all commits. I'll close this 
one and create a new one.

https://github.com/llvm/llvm-project/pull/161955
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [cmake] Fix delayloading liblldb.dll in mingw builds (PR #162831)

2025-10-10 Thread Martin Storsjö via lldb-commits 

https://github.com/mstorsjo closed 
https://github.com/llvm/llvm-project/pull/162831
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Introduce ScriptedFrameProvider for real threads (PR #161870)

2025-10-10 Thread Felipe de Azevedo Piovezan via lldb-commits 

felipepiovezan wrote:

> the need for coroutine stack traces. I need to splice in additional stack 
> frames in the middle of real, physical stack frames.

@vogelsgesang Have you considered writing a custom unwinder for this? If you 
want stack frames from which you can perform step operations, I think you 
_need_ to go down language-plugin-unwinder route. This is what we do for swift 
async functions (which have a lot of similarities to C++ coroutines).

https://github.com/llvm/llvm-project/pull/161870
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [debugserver] Implement MultiMemRead packet (PR #162670)

2025-10-10 Thread David Spickett via lldb-commits 


@@ -0,0 +1,72 @@
+"""
+Tests the exit code/description coming from the debugserver.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+@skipUnlessDarwin
+@skipIfOutOfTreeDebugserver
+class TestCase(TestBase):
+def send_process_packet(self, packet_str):
+self.runCmd(f"proc plugin packet send {packet_str}", check=False)
+# The output is of the form:
+#  packet: 
+#  response: 
+reply = self.res.GetOutput().split("\n")
+reply[0] = reply[0].strip()
+reply[1] = reply[1].strip()
+
+self.assertTrue(reply[0].startswith("packet: "), reply[0])
+self.assertTrue(reply[1].startswith("response: "))
+return reply[1][len("response: ") :]
+
+def test_packets(self):
+self.build()
+source_file = lldb.SBFileSpec("main.c")
+target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, "break here", source_file
+)
+
+reply = self.send_process_packet("qSupported")
+self.assertIn("MultiMemRead+", reply)
+
+mem_address_var = thread.frames[0].FindVariable("memory")
+self.assertTrue(mem_address_var)
+mem_address = int(mem_address_var.GetValue(), 16)
+
+reply = self.send_process_packet("MultiMemRead:")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2,")
+self.assertEqual(reply, "E03")
+reply = self.send_process_packet("MultiMemRead:ranges:10,2,;")
+self.assertEqual(reply, "0;")  # Debugserver is permissive with 
trailing commas.
+reply = self.send_process_packet("MultiMemRead:ranges:10,2;")
+self.assertEqual(reply, "0;")
+reply = 
self.send_process_packet(f"MultiMemRead:ranges:{mem_address:x},0;")
+self.assertEqual(reply, "0;")
+reply = self.send_process_packet(
+f"MultiMemRead:ranges:{mem_address:x},0;options:;"
+)
+self.assertEqual(reply, "0;")
+reply = 
self.send_process_packet(f"MultiMemRead:ranges:{mem_address:x},2;")
+self.assertEqual(reply, "2;ab")
+reply = self.send_process_packet(
+f"MultiMemRead:ranges:{mem_address:x},2,{mem_address+2:x},4;"
+)
+self.assertEqual(reply, "2,4;abcdef")
+reply = self.send_process_packet(
+
f"MultiMemRead:ranges:{mem_address:x},2,{mem_address+2:x},4,{mem_address+6:x},8;"
+)
+self.assertEqual(reply, "2,4,8;abcdefghijklmn")

DavidSpickett wrote:

Add tests for zero length reply in the middle and end, you have one for the 
start earlier.

Also check a zero length returns 0 bytes for a mapped and unmapped location.

https://github.com/llvm/llvm-project/pull/162670
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [debugserver] Implement MultiMemRead packet (PR #162670)

2025-10-10 Thread David Spickett via lldb-commits 


@@ -0,0 +1,72 @@
+"""
+Tests the exit code/description coming from the debugserver.

DavidSpickett wrote:

"...when handling MultiMemRead packets."

https://github.com/llvm/llvm-project/pull/162670
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][mcp] Get the running MCP server connection information (PR #162752)

2025-10-10 Thread Alexandre Perez via lldb-commits 

https://github.com/aperez closed 
https://github.com/llvm/llvm-project/pull/162752
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Fix empty register set when trying to get size of register (PR #162890)

2025-10-10 Thread via lldb-commits 

https://github.com/aokblast updated 
https://github.com/llvm/llvm-project/pull/162890

>From 02a3bd3f786925b22f29a8c9f7c9a1db2c9dbec4 Mon Sep 17 00:00:00 2001
From: ShengYi Hung 
Date: Sat, 11 Oct 2025 01:07:36 +0800
Subject: [PATCH] [LLDB, FreeBSD, x86] Fix empty register set when trying to
 get size of register

GetSharedRegisterInfoVector is a function to get the singleton of total
register info. Also, PrivateGetRegisterCount assumes that we have already
filled the object in GetSharedRegisterInfoVector and panic when the object
is empty.
However, the actually function possess the register info
is GetRegisterInfo_i386. Originally, I plan to solve this by only
referencing object in GetSharedRegisterInfoVector. However,
RegisterInfos_x86_64.h requires the symbol with name g_register_infos in
current scope so that the header can append x86_64 registers after it.
As a result, I decide to copy the info to the object in
GetSharedRegisterInfoVector.

Also, reorder the header order and provide tests for debugging 32bit
binary on 64bit platform.
---
 lldb/source/Host/freebsd/Host.cpp   | 3 +--
 .../Process/Utility/RegisterContextFreeBSD_x86_64.cpp   | 6 --
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Host/freebsd/Host.cpp 
b/lldb/source/Host/freebsd/Host.cpp
index fa7efad466bad..dfdbfea0c3c0a 100644
--- a/lldb/source/Host/freebsd/Host.cpp
+++ b/lldb/source/Host/freebsd/Host.cpp
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#include "llvm/Object/ELF.h"
-
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/HostInfo.h"
@@ -32,6 +30,7 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StreamString.h"
 
+#include "llvm/Object/ELF.h"
 #include "llvm/TargetParser/Host.h"
 
 namespace lldb_private {
diff --git 
a/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp 
b/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
index e0f3971c6e272..b55a5c595d3ca 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.cpp
@@ -76,8 +76,7 @@ static std::vector 
&GetSharedRegisterInfoVector() {
 
 static const RegisterInfo *
 GetRegisterInfo_i386(const lldb_private::ArchSpec &arch) {
-  static std::vector g_register_infos(
-  GetSharedRegisterInfoVector());
+  static std::vector g_register_infos;
 
   // Allocate RegisterInfo only once
   if (g_register_infos.empty()) {
@@ -93,6 +92,9 @@ GetRegisterInfo_i386(const lldb_private::ArchSpec &arch) {
 #define UPDATE_REGISTER_INFOS_I386_STRUCT_WITH_X86_64_OFFSETS
 #include "RegisterInfos_x86_64.h"
 #undef UPDATE_REGISTER_INFOS_I386_STRUCT_WITH_X86_64_OFFSETS
+std::vector &shared_regs =
+GetSharedRegisterInfoVector();
+shared_regs = g_register_infos;
   }
 
   return &g_register_infos[0];

___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] e3620fe - [lldb][Expression] Emit a 'Note' diagnostic that indicates the language used for expression evaluation (#161688)

2025-10-10 Thread via lldb-commits 

Author: Michael Buch
Date: 2025-10-10T19:23:02+01:00
New Revision: e3620fe0685c656915977d55f822a82090041965

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

LOG: [lldb][Expression] Emit a 'Note' diagnostic that indicates the language 
used for expression evaluation (#161688)

Depends on:
* https://github.com/llvm/llvm-project/pull/162050

Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).

Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.

# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.

(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression 
as 'Objective C++'.

(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO 
C++'.

(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'

(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'

(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'

(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default 
language. Ran expression as 'Objective C++'.
```

I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.

Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).

rdar://160297649
rdar://159669244

Added: 
lldb/test/Shell/Expr/TestExprLanguageNote.test

Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
lldb/test/API/python_api/interpreter/TestCommandInterpreterAPI.py

Removed: 




diff  --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
index 3c49c911108a3..6b121c934dfbb 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -74,6 +74,7 @@
 #include "lldb/Core/Debugger.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/Module.h"
+#include "lldb/Expression/DiagnosticManager.h"
 #include "lldb/Expression/IRExecutionUnit.h"
 #include "lldb/Expression/IRInterpreter.h"
 #include "lldb/Host/File.h"
@@ -96,6 +97,7 @@
 #include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
 #include "Plugins/Platform/MacOSX/PlatformDarwin.h"
 #include "lldb/Utility/XcodeSDK.h"
+#include "lldb/lldb-enumerations.h"
 
 #include 
 #include 
@@ -527,7 +529,8 @@ static void SetupTargetOpts(CompilerInstance &compiler,
 
 static void SetupLangOpts(CompilerInstance &compiler,
   ExecutionContextScope &exe_scope,
-  const Expression &expr) {
+  const Expression &expr,
+  DiagnosticManager &diagnostic_manager) {
   Log *log = GetLog(LLDBLog::Expressions);
 
   // If the expression is being evaluated in the context of an existing stack
@@ -547,6 +550,9 @@ static void SetupLangOpts(CompilerInstance &compiler,
  : lldb::eLanguageTypeUnknown),
 lldb_private::Language::GetNameForLanguageType(language));
 
+  lldb::LanguageType language_for_note = language;
+  std::string language_fallback_reason;
+
   LangOptions &lang_opts = compiler.getLangOpts();
 
   switch (language) {
@@ -560,6 +566,10 @@ static void SetupLangOpts(CompilerInstance &compiler,
 // family languag

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

2025-10-10 Thread Adrian Prantl via lldb-commits 

https://github.com/adrian-prantl approved this pull request.


https://github.com/llvm/llvm-project/pull/162657
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Don't run libc++ API tests without a locally built libc++ (PR #162657)

2025-10-10 Thread David Spickett via lldb-commits 


@@ -789,6 +789,10 @@ def canRunLibcxxTests():
 return True, "libc++ always present"
 
 if platform == "linux":
+if not configuration.libcxx_include_dir or not 
configuration.libcxx_library_dir:
+return False, "API tests require a locally built libc++."

DavidSpickett wrote:

That's fine.

https://github.com/llvm/llvm-project/pull/162657
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][windows] add support for out of PATH python.dll resolution (PR #162509)

2025-10-10 Thread Adrian Prantl via lldb-commits 


@@ -426,6 +433,47 @@ SBError Driver::ProcessArgs(const opt::InputArgList &args, 
bool &exiting) {
   return error;
 }
 
+#ifdef _WIN32
+// Returns the full path to the lldb.exe executable
+inline std::wstring GetPathToExecutableW() {
+  // Iterate until we reach the Windows max path length (32,767).
+  std::vector buffer;
+  buffer.resize(MAX_PATH);
+  while (buffer.size() < 32767) {
+if (GetModuleFileNameW(NULL, buffer.data(), buffer.size()) < buffer.size())
+  return std::wstring(buffer.begin(), buffer.end());
+buffer.resize(buffer.size() * 2);
+  }
+  return L"";
+}
+
+// Resolve the full path of the directory defined by
+// LLDB_PYTHON_DLL_RELATIVE_PATH. If it exists, add it to the list of DLL 
search
+// directories.
+void AddPythonDLLToSearchPath() {
+  std::wstring modulePath = GetPathToExecutableW();
+  if (modulePath.empty()) {
+WithColor::error() << "Unable to find python: " << GetLastError() << '\n';

adrian-prantl wrote:

We typically with the word "error:" in the error color, and not the entire 
message.

https://github.com/llvm/llvm-project/pull/162509
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][NativePDB] Use typedef compiler type for typedef types (PR #156250)

2025-10-10 Thread Michael Buch via lldb-commits 

Michael137 wrote:

> Ping - I'd like to use the added test from this PR as the "current state" and 
> fix the missing things from above in other PRs.

Will some time today.  Sorry for the delay!

https://github.com/llvm/llvm-project/pull/156250
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-dap] expand tilde in dap executable path (PR #162635)

2025-10-10 Thread Walter Erquinigo via lldb-commits 


@@ -9,6 +10,16 @@ import { LogFilePathProvider, LogType } from "./logging";
 
 const exec = util.promisify(child_process.execFile);
 
+/**

walter-erquinigo wrote:

better use this package https://www.npmjs.com/package/untildify
there are some interesting cases related to ~, so better rely on a library

https://github.com/llvm/llvm-project/pull/162635
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits