[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread David Spickett via lldb-commits


@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)

DavidSpickett wrote:

Doesn't this now do the wrong thing for a hypothetical 4.x? I thought that's 
what the `|| (PY_MAJOR_VERSION > 3)` was there for.

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


[Lldb-commits] [lldb] [LLDB] Add a target.launch-working-dir setting (PR #113521)

2024-10-30 Thread David Spickett via lldb-commits

DavidSpickett wrote:

`launch-working-dir` sounds like `working-dir` to me. Do we need the `launch` 
prefix? Should this be `target.process` not `target`?

This issue could be re-stated as "a process launched with -w does not use the 
same working dir if run again". Which I think is certainly unexpected behaviour 
as a user. Did you look into making `run` of the process just re-use the 
working dir that was set up front?

The way I see it this splits in two:
* One use case is saying "I'm running lldb from X but I want to launch all 
processes as if they were in Y" - where that might be the same program or many 
different programs across a single session.
  * Which you could also automate with `cd  && /lldb/`. 
Would that work in your system?
* `process launch -w`'d processes should not forget their initial working dir 
when re-run.

Feels like you are solving one problem using the solution of a different 
problem.

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Michael Buch via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Michael Buch via lldb-commits

Michael137 wrote:

> @Michael137 I wasn't able to run `yaml2obj` to convert back an object file 
> that contains debug info, I'm not sure if the issue is that `yaml2obj` 
> doesn't support something that's encoded in the debug info, or some bug with 
> MachO.
> 
> This is the error:
> 
> ```
> error: wrote too much data somewhere, section offsets in section 
> __debug_str_offs__DWARF for segment __DWARF don't line up: [cursor=0x41d1e0], 
> [fileStart=0x41ccdc], [sectionOffset=0x4f2]
> ```

Hmm yea I wouldn't be surprised if `yaml2obj` doesn't properly handle this. 
Could give it a shot using ELF (I think that has better support). But if that 
doesn't work either I wouldn't bother

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


[Lldb-commits] [lldb] Fix the sort function for languages to have "strict weak ordering". (PR #114160)

2024-10-30 Thread Michael Buch via lldb-commits

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


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


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,42 @@
+// This test verifies that loading an ELF file that has no section headers can
+// load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+// the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+// segment.
+
+// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj \
+// RUN:   -o - - <<<".globl defined, undefined; defined:" | \
+// RUN:   ld.lld /dev/stdin -o - --hash-style=gnu -export-dynamic -shared \
+// RUN:   -z nosectionheader -o %t.gnu
+// RUN: %lldb %t.gnu -b \
+// RUN:   -o "image dump objfile" \
+// RUN:   | FileCheck %s --dump-input=always --check-prefix=GNU
+// GNU: (lldb) image dump objfile
+// GNU: Dumping headers for 1 module(s).
+// GNU: ObjectFileELF, file =
+// GNU: ELF Header
+// GNU: e_type  = 0x0003 ET_DYN
+// Make sure there are no section headers
+// GNU: e_shnum = 0x
+// Make sure we were able to load the symbols
+// GNU: Symtab, file = {{.*}}elf-dynsym.test.tmp.gnu, num_symbols = 2:
+// GNU-DAG: undefined
+// GNU-DAG: defined
+
+// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj \
+// RUN:   -o - - <<<".globl defined, undefined; defined:" | \
+// RUN:   ld.lld /dev/stdin -o - --hash-style=sysv -export-dynamic -shared \

labath wrote:

```suggestion
// RUN:   ld.lld %t.o -o - --hash-style=sysv -export-dynamic -shared \
```
(we can reuse the object file)

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Michael Buch via lldb-commits


@@ -2758,6 +2758,20 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return true; // Keep iterating over index types, language mismatch.
 }
 
+// Since mangled names are unique, we only need to check if the names are
+// the same.
+if (query.GetSearchByMangledName()) {
+  if (die.GetMangledName(/*substitute_name_allowed=*/false) !=

Michael137 wrote:

Even with substitutions, that would only cause problems if the `DW_AT_name` 
somehow contained a the mangled name, right? Even then, that might not actually 
be a problem.

But I guess being more explicit about really only checking the linkage name 
seems fine

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


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,42 @@
+// This test verifies that loading an ELF file that has no section headers can
+// load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+// the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+// segment.
+
+// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj \
+// RUN:   -o - - <<<".globl defined, undefined; defined:" | \
+// RUN:   ld.lld /dev/stdin -o - --hash-style=gnu -export-dynamic -shared \

labath wrote:

```suggestion
// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj %s -o %t.o \
// RUN: ld.lld %t.o --hash-style=gnu -export-dynamic -shared \
```

.. and put the asm input into this file. I don't think `<<<` and `/dev/stdin` 
will work on windows. I've just used as a simple command for experimentation.

I would also recommend more unique names and thinking about whether there are 
any corner cases that are worth explicitly testing (e.g. deliberately creating 
some hash collisions?).

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


[Lldb-commits] [lldb] [LLDB] Finish implementing support for DW_FORM_data16 (PR #113508)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -165,6 +172,11 @@
 .long   .Lulong_ptr-.Lcu_begin0 # DW_AT_type
 .uleb128 0xdeadbeefbaadf00d # DW_AT_const_value
 
+.byte   18  # Abbrev DW_TAG_variable
+.asciz  "data16"# DW_AT_name
+.long   .Lu128-.Lcu_begin0  # DW_AT_type
+.asciz 
""
 # DW_AT_const_value

labath wrote:

This doesn't sound right. Shouldn't this be a 128 bit integer value? I'd also 
recommend writing the variable in a way that's easily recognisable as "correct" 
in the test expectations. Since we don't have a way (AFAIK) to insert 128 bit 
asm constants, I'd probably do it by putting two `.quad 0xhex` statements here 
and then telling lldb to print the variable in hex (by adding an extra `target 
variable --format x data16` command)

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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread Jonas Devlieghere via lldb-commits


@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)

JDevlieghere wrote:

@DavidSpickett The hypothetical Python 4 case is covered above and goes down 
the ` Py_InitializeFromConfig` path. 

@labath Happy to use that but everything else in this file uses the same check 
I have here, so I'll simplify the defines in a separate patch/PR. 

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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread David Spickett via lldb-commits


@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)

DavidSpickett wrote:

Yes you're right I was struggling to read the nested ifdefs. This 3.2 code will 
be removed once the 20 branch happens so it's fine as is.

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


[Lldb-commits] [lldb] [lldb] Use LLVM's helper for Unicode conversion (NFC) (PR #112582)

2024-10-30 Thread Pavel Labath via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Use LLVM's helper for Unicode conversion (NFC) (PR #112582)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -12,6 +12,8 @@
 
 #include "lldb/Host/Editline.h"
 
+#include 

labath wrote:

I guess this is not needed now (?)

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


[Lldb-commits] [lldb] [lldb] Use LLVM's helper for Unicode conversion (NFC) (PR #112582)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -1574,25 +1584,23 @@ bool Editline::CompleteCharacter(char ch, 
EditLineGetCharType &out) {
   out = (unsigned char)ch;
   return true;
 #else
-  LLDB_DEPRECATED_WARNING_DISABLE
-  std::codecvt_utf8 cvt;
-  LLDB_DEPRECATED_WARNING_RESTORE
   llvm::SmallString<4> input;
   for (;;) {
-const char *from_next;
-wchar_t *to_next;
-std::mbstate_t state = std::mbstate_t();
 input.push_back(ch);
-switch (cvt.in(state, input.begin(), input.end(), from_next, &out, &out + 
1,
-   to_next)) {
-case std::codecvt_base::ok:
+const char *cur_ptr = input.begin();
+const char *end_ptr = input.end();
+llvm::UTF32 code_point = 0;
+llvm::ConversionResult cr = llvm::convertUTF8Sequence(
+(const llvm::UTF8 **)&cur_ptr, (const llvm::UTF8 *)end_ptr, 
&code_point,

labath wrote:

```suggestion
auto *cur_ptr = reinterpret_cast(input.begin());
auto *end_ptr = reinterpret_cast(input.end());
llvm::UTF32 code_point = 0;
llvm::ConversionResult cr = llvm::convertUTF8Sequence(
&cur_ptr, end_ptr, &code_point,
```

I think this is "less undefined" :P

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


[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-10-30 Thread Pavel Labath via lldb-commits

labath wrote:

The lldb change looks good (you can submit that in its own patch without a 
review), but you'll probably want to find a different reviewer for the codeview 
part (I have no idea who's responsible for that these days).

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


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-30 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/112596

>From 0ff6ba499bcb04581cf5b77780f769bee05e4aef Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Sat, 28 Sep 2024 15:05:37 -0700
Subject: [PATCH 1/3] Add support for reading the dynamic symbol table from
 program headers and PT_DYNAMIC.

Allow LLDB to parse the dynamic symbol table from an ELF file or memory image 
in an ELF file that has no section headers. This patch uses the ability to 
parse the PT_DYNAMIC segment and find the DT_SYMTAB, DT_SYMENT, DT_HASH or 
DT_GNU_HASH to find and parse the dynamic symbol table if the section headers 
are not present. It also adds a helper function to read data from a .dynamic 
key/value pair entry correctly from the file or from memory.
---
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  | 163 -
 .../Plugins/ObjectFile/ELF/ObjectFileELF.h|  34 +
 .../test/Shell/ObjectFile/ELF/elf-dynsym.yaml | 631 ++
 3 files changed, 811 insertions(+), 17 deletions(-)
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/elf-dynsym.yaml

diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 10d09662c0a47a..7374ac10a1e27a 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -44,6 +44,8 @@
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/MipsABIFlags.h"
+#include "lldb/Target/Process.h"
+
 
 #define CASE_AND_STREAM(s, def, width) 
\
   case def:
\
@@ -2990,18 +2992,34 @@ void ObjectFileELF::ParseSymtab(Symtab &lldb_symtab) {
   // section, nomatter if .symtab was already parsed or not. This is because
   // minidebuginfo normally removes the .symtab symbols which have their
   // matching .dynsym counterparts.
+  bool found_dynsym = false;
   if (!symtab ||
   GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"))) {
 Section *dynsym =
 section_list->FindSectionByType(eSectionTypeELFDynamicSymbols, true)
 .get();
 if (dynsym) {
+  found_dynsym = true;
   auto [num_symbols, address_class_map] =
   ParseSymbolTable(&lldb_symtab, symbol_id, dynsym);
   symbol_id += num_symbols;
   m_address_class_map.merge(address_class_map);
 }
   }
+  if (!found_dynsym) {
+// Try and read the dynamic symbol table from the .dynamic section.
+uint32_t num_symbols = 0;
+std::optional symtab_data =
+GetDynsymDataFromDynamic(num_symbols);
+std::optional strtab_data = GetDynstrData();
+if (symtab_data && strtab_data) {
+  auto [num_symbols_parsed, address_class_map] =
+  ParseSymbols(&lldb_symtab, symbol_id, section_list, num_symbols,
+symtab_data.value(), strtab_data.value());
+  symbol_id += num_symbols_parsed;
+  m_address_class_map.merge(address_class_map);
+}
+  }
 
   // DT_JMPREL
   //  If present, this entry's d_ptr member holds the address of
@@ -3811,6 +3829,33 @@ ObjectFileELF::MapFileDataWritable(const FileSpec &file, 
uint64_t Size,
  Offset);
 }
 
+std::optional
+ObjectFileELF::ReadDataFromDynamic(const ELFDynamic *dyn, uint64_t length,
+   uint64_t offset) {
+  // ELFDynamic values contain a "d_ptr" member that will be a load address if
+  // we have an ELF file read from memory, or it will be a file address if it
+  // was read from a ELF file. This function will correctly fetch data pointed
+  // to by the ELFDynamic::d_ptr, or return std::nullopt if the data isn't
+  // available.
+  const lldb::addr_t d_ptr_addr = dyn->d_ptr + offset;
+  if (ProcessSP process_sp = m_process_wp.lock()) {
+if (DataBufferSP data_sp = ReadMemory(process_sp, d_ptr_addr, length))
+  return DataExtractor(data_sp, GetByteOrder(), GetAddressByteSize());
+  } else {
+// We have an ELF file with no section headers or we didn't find the
+// .dynamic section. Try and find the .dynstr section.
+Address addr;
+if (!addr.ResolveAddressUsingFileSections(d_ptr_addr, GetSectionList()))
+  return std::nullopt;
+DataExtractor data;
+addr.GetSection()->GetSectionData(data);
+return DataExtractor(data,
+ d_ptr_addr - addr.GetSection()->GetFileAddress(),
+ length);
+  }
+  return std::nullopt;
+}
+
 std::optional ObjectFileELF::GetDynstrData() {
   if (SectionList *section_list = GetSectionList()) {
 // Find the SHT_DYNAMIC section.
@@ -3846,23 +3891,7 @@ std::optional 
ObjectFileELF::GetDynstrData() {
   if (strtab == nullptr || strsz == nullptr)
 return std::nullopt;
 
-  if (ProcessSP process_sp = m_process_wp.lock()) {
-if (DataBufferSP data_sp =
-ReadMemory(process_s

[Lldb-commits] [lldb] eac2c18 - Remove a flaky and unnecessary check (#114251)

2024-10-30 Thread via lldb-commits

Author: Adrian Prantl
Date: 2024-10-30T08:59:08-07:00
New Revision: eac2c182c6f852fc187af9952250a43d6fb17b28

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

LOG: Remove a flaky and unnecessary check (#114251)

The order in which the libraries appear is not always stable and even if
it were, this test is not the right place to check for this.

Added: 


Modified: 

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
index 0919eb3c5dd812..93d5392830b508 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
@@ -40,5 +40,3 @@ def test(self):
 "frame variable ils",
 substrs=['[4] = "surprise it is a long string!! yay!!"'],
 )
-
-self.expect("image list", substrs=self.getLibcPlusPlusLibs())



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


[Lldb-commits] [lldb] [lldb] Add a link to LLDB's Discord channel on the website (PR #114289)

2024-10-30 Thread Adrian Prantl via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Add a link to LLDB's Discord channel on the website (PR #114289)

2024-10-30 Thread Aaron Ballman via lldb-commits

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

LGTM!

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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread Michael Buch via lldb-commits

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

Think the intention was to originally make sure that we're debugging libc++. 
Checking this here is unnecessary (and should really be asserted at the 
Makefile layer, which do on Apple platforms)

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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl commented:

Can you add a test (perhaps using lldb-test and a .ll or .s file)?

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


[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)

2024-10-30 Thread via lldb-commits

jeffreytan81 wrote:

I haven't had time to look into your example in details. 

But to share high level context about the bug behavior, we have observed cases 
that, there is real world scenarios using `std::vector&` object, which data 
formatters, and "v obj" reports this vector "size=13", but there is another 
function accepting `std::vector *` as parameter, so `&obj` is passed. In 
both locals window for "&obj" and "v &obj" reports "size=0" which is apparently 
very confusing to end users. 
To make things even worse, in VSCode, if your mouse hover "&obj", it will try 
to "frame var &obj" instead of "frame var obj" which makes this bug behavior 
even more prevalent.

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Augusto Noronha via lldb-commits

augusto2112 wrote:

Ok, I was able to add a test

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


[Lldb-commits] [lldb] [lldb] Use LLVM's helper for Unicode conversion (NFC) (PR #112582)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/112582

>From de19f43fbee9aff2a99106a23b7f264012ab5485 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Mon, 21 Oct 2024 13:40:02 -0700
Subject: [PATCH 1/2] [lldb] Use LLVM's helper for Unicode conversion (NFC)

The codecvt header has been deprecated in C++17. Use LLVM's unicode
helpers to convert between UTF-8 and UTF-16.
---
 lldb/include/lldb/Host/Editline.h| 25 ---
 lldb/source/Host/common/Editline.cpp | 48 
 2 files changed, 28 insertions(+), 45 deletions(-)

diff --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h
index a02f90891599ad..57e2c831e3499d 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -30,9 +30,6 @@
 
 #include "lldb/Host/Config.h"
 
-#if LLDB_EDITLINE_USE_WCHAR
-#include 
-#endif
 #include 
 #include 
 #include 
@@ -57,23 +54,6 @@
 
 #include "llvm/ADT/FunctionExtras.h"
 
-#if defined(__clang__) && defined(__has_warning)
-#if __has_warning("-Wdeprecated-declarations")
-#define LLDB_DEPRECATED_WARNING_DISABLE
\
-  _Pragma("clang diagnostic push") 
\
-  _Pragma("clang diagnostic ignored \"-Wdeprecated-declarations\"")
-#define LLDB_DEPRECATED_WARNING_RESTORE _Pragma("clang diagnostic pop")
-#endif
-#elif defined(__GNUC__) && __GNUC__ > 6
-#define LLDB_DEPRECATED_WARNING_DISABLE
\
-  _Pragma("GCC diagnostic push")   
\
-  _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
-#define LLDB_DEPRECATED_WARNING_RESTORE _Pragma("GCC diagnostic pop")
-#else
-#define LLDB_DEPRECATED_WARNING_DISABLE
-#define LLDB_DEPRECATED_WARNING_RESTORE
-#endif
-
 namespace lldb_private {
 namespace line_editor {
 
@@ -383,11 +363,6 @@ class Editline {
   void SetEditLinePromptCallback(EditlinePromptCallbackType callbackFn);
   void SetGetCharacterFunction(EditlineGetCharCallbackType callbackFn);
 
-#if LLDB_EDITLINE_USE_WCHAR
-  LLDB_DEPRECATED_WARNING_DISABLE
-  std::wstring_convert> m_utf8conv;
-  LLDB_DEPRECATED_WARNING_RESTORE
-#endif
   ::EditLine *m_editline = nullptr;
   EditlineHistorySP m_history_sp;
   bool m_in_history = false;
diff --git a/lldb/source/Host/common/Editline.cpp 
b/lldb/source/Host/common/Editline.cpp
index 60117cb5f0e615..b568ede4fa0322 100644
--- a/lldb/source/Host/common/Editline.cpp
+++ b/lldb/source/Host/common/Editline.cpp
@@ -12,6 +12,8 @@
 
 #include "lldb/Host/Editline.h"
 
+#include 
+
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
@@ -23,6 +25,7 @@
 #include "lldb/Utility/StreamString.h"
 #include "lldb/Utility/StringList.h"
 #include "lldb/Utility/Timeout.h"
+#include "llvm/Support/ConvertUTF.h"
 
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Locale.h"
@@ -444,7 +447,9 @@ StringList Editline::GetInputAsStringList(int line_count) {
 if (line_count == 0)
   break;
 #if LLDB_EDITLINE_USE_WCHAR
-lines.AppendString(m_utf8conv.to_bytes(line));
+std::string buffer;
+llvm::convertWideToUTF8(line, buffer);
+lines.AppendString(buffer);
 #else
 lines.AppendString(line);
 #endif
@@ -636,7 +641,9 @@ unsigned char Editline::BreakLineCommand(int ch) {
 if (m_fix_indentation_callback) {
   StringList lines = GetInputAsStringList(m_current_line_index + 1);
 #if LLDB_EDITLINE_USE_WCHAR
-  lines.AppendString(m_utf8conv.to_bytes(new_line_fragment));
+  std::string buffer;
+  llvm::convertWideToUTF8(new_line_fragment, buffer);
+  lines.AppendString(buffer);
 #else
   lines.AppendString(new_line_fragment);
 #endif
@@ -684,8 +691,9 @@ unsigned char Editline::EndOrAddLineCommand(int ch) {
   m_input_lines.clear();
   for (unsigned index = 0; index < lines.GetSize(); index++) {
 #if LLDB_EDITLINE_USE_WCHAR
-m_input_lines.insert(m_input_lines.end(),
- m_utf8conv.from_bytes(lines[index]));
+std::wstring wbuffer;
+llvm::ConvertUTF8toWide(lines[index], wbuffer);
+m_input_lines.insert(m_input_lines.end(), wbuffer);
 #else
 m_input_lines.insert(m_input_lines.end(), lines[index]);
 #endif
@@ -869,7 +877,9 @@ unsigned char Editline::FixIndentationCommand(int ch) {
 currentLine = currentLine.erase(0, -indent_correction);
   }
 #if LLDB_EDITLINE_USE_WCHAR
-  m_input_lines[m_current_line_index] = m_utf8conv.from_bytes(currentLine);
+  std::wstring wbuffer;
+  llvm::ConvertUTF8toWide(currentLine, wbuffer);
+  m_input_lines[m_current_line_index] = wbuffer;
 #else
   m_input_lines[m_current_line_index] = currentLine;
 #endif
@@ -1502,7 +1512,7 @@ bool Editline::GetLine(std::string &line, bool 
&interrupted) {
 } else {
   m_history_sp->Enter(input);
 #if LLDB_EDITLINE_USE_WCHAR
-  line = m_utf8conv.to_b

[Lldb-commits] [lldb] 45f420e - [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

2024-10-30 Thread via lldb-commits

Author: Jonas Devlieghere
Date: 2024-10-30T08:41:30-07:00
New Revision: 45f420e34476d2963e13b2f916be1e5a73ec95ae

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

LOG: [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..6158083a982801 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home);
+#else
+  Py_SetPythonHome(g_python_home);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,32 +180,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
-
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
 // so there is no way to determine whether the embedded interpreter



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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)

2024-10-30 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/113398

>From 0b88de8fe7f5e4ea7f4089be403b271cd7b086d0 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Tue, 22 Oct 2024 16:29:50 -0700
Subject: [PATCH 1/2] Add a compiler/interpreter of LLDB data formatter
 bytecode to examples

---
 lldb/docs/index.rst   |   1 +
 lldb/docs/resources/formatterbytecode.rst | 221 
 lldb/examples/formatter-bytecode/Makefile |   8 +
 lldb/examples/formatter-bytecode/compiler.py  | 486 ++
 .../formatter-bytecode/test/MyOptional.cpp|  23 +
 .../formatter-bytecode/test/formatter.py  | 131 +
 6 files changed, 870 insertions(+)
 create mode 100644 lldb/docs/resources/formatterbytecode.rst
 create mode 100644 lldb/examples/formatter-bytecode/Makefile
 create mode 100644 lldb/examples/formatter-bytecode/compiler.py
 create mode 100644 lldb/examples/formatter-bytecode/test/MyOptional.cpp
 create mode 100644 lldb/examples/formatter-bytecode/test/formatter.py

diff --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..c3c2fb36eb541a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -164,6 +164,7 @@ interesting areas to contribute to lldb.
resources/fuzzing
resources/sbapi
resources/dataformatters
+   resources/formatterbytecode
resources/extensions
resources/lldbgdbremote
resources/lldbplatformpackets
diff --git a/lldb/docs/resources/formatterbytecode.rst 
b/lldb/docs/resources/formatterbytecode.rst
new file mode 100644
index 00..e6a52a2bdddcdb
--- /dev/null
+++ b/lldb/docs/resources/formatterbytecode.rst
@@ -0,0 +1,221 @@
+Formatter Bytecode
+==
+
+Background
+--
+
+LLDB provides very rich customization options to display data types (see 
:doc:`/use/variable/`). To use custom data formatters, developers need to edit 
the global `~/.lldbinit` file to make sure they are found and loaded. In 
addition to this rather manual workflow, developers or library authors can ship 
ship data formatters with their code in a format that allows LLDB automatically 
find them and run them securely.
+
+An end-to-end example of such a workflow is the Swift `DebugDescription` macro 
(see https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates 
Swift string interpolation into LLDB summary strings, and puts them into a 
`.lldbsummaries` section, where LLDB can find them.
+
+This document describes a minimal bytecode tailored to running LLDB 
formatters. It defines a human-readable assembler representation for the 
language, an efficient binary encoding, a virtual machine for evaluating it, 
and format for embedding formatters into binary containers.
+
+Goals
+~
+
+Provide an efficient and secure encoding for data formatters that can be used 
as a compilation target from user-friendly representations (such as DIL, Swift 
DebugDescription, or NatVis).
+
+Non-goals
+~
+
+While humans could write the assembler syntax, making it user-friendly is not 
a goal.
+
+Design of the virtual machine
+-
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable 
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control 
stack is kept separate to make it easier to reason about the security aspects 
of the virtual machine.
+
+Data types
+~~
+
+All objects on the data stack must have one of the following data types. These 
data types are "host" data types, in LLDB parlance.
+
+* *String* (UTF-8)
+* *Int* (64 bit)
+* *UInt* (64 bit)
+* *Object* (Basically an `SBValue`)
+* *Type* (Basically an `SBType`)
+* *Selector* (One of the predefine functions)
+
+*Object* and *Type* are opaque, they can only be used as a parameters of 
`call`.
+
+Instruction set
+---
+
+Stack operations
+
+
+These instructions manipulate the data stack directly.
+
+  ==  ===
+ OpcodeMnemonicStack effect  
+  --  ---
+ 0x00  `dup`   `(x -> x x)`  
+ 0x01  `drop`  `(x y -> x)`   
+ 0x02  `pick`  `(x ... UInt -> x ... x)`  
+ 0x03  `over`  `(x y -> x y x)`   
+ 0x04  `swap`  `(x y -> y x)` 
+ 0x05  `rot`   `(x y z -> z x y)` 
+===  ==  ===
+
+Control flow
+
+
+These manipulate the control stack and program counter.
+
+  ==  

+ OpcodeMnemonicDescription  
+  --  

+ 0x10   `{`push a code block address onto the control stack
+  --`}`(technically not an opcode) syntax for end

[Lldb-commits] [lldb] Fix a couple of tests that were incorrectly using configuration.dwarf_version (PR #114161)

2024-10-30 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl commented:

Thanks!

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


[Lldb-commits] [lldb] [lldb] Add a fuzzer for the DWARF Expression Evaluator (PR #114286)

2024-10-30 Thread Alex Langford via lldb-commits


@@ -0,0 +1,34 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+add_llvm_fuzzer(lldb-dwarf-expression-fuzzer
+  EXCLUDE_FROM_ALL
+  lldb-dwarf-expression-fuzzer.cpp
+  )
+
+include_directories(${LLDB_SOURCE_ROOT})

bulbazord wrote:

suggestion: Use `target_include_directories` instead of a naked 
`include_directories`

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


[Lldb-commits] [lldb] Skip one inline stepping test for arm-ubuntu. (PR #114295)

2024-10-30 Thread via lldb-commits

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114295

>From c152f18b0c0436891eeb172700a4b7b84e5a0a1c Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 12:41:52 -0700
Subject: [PATCH 1/2] Skip one inline stepping test for arm-ubuntu.

The test is currently passing everywhere but this 32-bit arm ubuntu
bot.  I don't have an easy way to debug this, so I'm skipping the
test on that platform till we get a chance to figure this out.
---
 .../API/functionalities/inline-stepping/TestInlineStepping.py   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..d3d00bca36b920 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -14,6 +14,8 @@ class TestInlineStepping(TestBase):
 compiler="icc",
 bugnumber="# Not really a bug.  ICC combines two inlined functions.",
 )
+
+@skipIf(oslist=["ubuntu"], archs=["arm"]) # Fails for 32 bit arm
 def test_with_python_api(self):
 """Test stepping over and into inlined functions."""
 self.build()

>From effa929cd73cde63e31dbedf8c5fadcb767aae37 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 12:58:22 -0700
Subject: [PATCH 2/2] Use "linux" not "ubuntu" for to os.

---
 .../API/functionalities/inline-stepping/TestInlineStepping.py   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index d3d00bca36b920..4878bda23bb6ec 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -15,7 +15,7 @@ class TestInlineStepping(TestBase):
 bugnumber="# Not really a bug.  ICC combines two inlined functions.",
 )
 
-@skipIf(oslist=["ubuntu"], archs=["arm"]) # Fails for 32 bit arm
+@skipIf(oslist=["linux"], archs=["arm"]) # Fails for 32 bit arm
 def test_with_python_api(self):
 """Test stepping over and into inlined functions."""
 self.build()

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


[Lldb-commits] [lldb] Skip one inline stepping test for arm-ubuntu. (PR #114295)

2024-10-30 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 
5545f76dc94e76ef6800823bdd1e107ad2264717...effa929cd73cde63e31dbedf8c5fadcb767aae37
 lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
``





View the diff from darker here.


``diff
--- TestInlineStepping.py   2024-10-30 19:58:22.00 +
+++ TestInlineStepping.py   2024-10-30 20:02:02.390605 +
@@ -12,12 +12,11 @@
 @skipIf(oslist=["windows"], archs=["aarch64"])  # Flaky on buildbot
 @expectedFailureAll(
 compiler="icc",
 bugnumber="# Not really a bug.  ICC combines two inlined functions.",
 )
-
-@skipIf(oslist=["linux"], archs=["arm"]) # Fails for 32 bit arm
+@skipIf(oslist=["linux"], archs=["arm"])  # Fails for 32 bit arm
 def test_with_python_api(self):
 """Test stepping over and into inlined functions."""
 self.build()
 self.inline_stepping()
 

``




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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread David Spickett via lldb-commits

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

LGTM

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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread David Spickett via lldb-commits


@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)

DavidSpickett wrote:

Same here, `|| (PY_MAJOR_VERSION > 3)`.

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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Prantl (adrian-prantl)


Changes

The order in which the libraries appear is not always stable and even if it 
were, this test is not the right place to check for this.

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


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
 (-2) 


``diff
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
index 0919eb3c5dd812..93d5392830b508 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
@@ -40,5 +40,3 @@ def test(self):
 "frame variable ils",
 substrs=['[4] = "surprise it is a long string!! yay!!"'],
 )
-
-self.expect("image list", substrs=self.getLibcPlusPlusLibs())

``




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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread Jonas Devlieghere via lldb-commits


@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)

JDevlieghere wrote:

Yes, here it's actually missing. 

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


[Lldb-commits] [lldb] [LLDB] Finish implementing support for DW_FORM_data16 (PR #113508)

2024-10-30 Thread Walter Erquinigo via lldb-commits


@@ -165,6 +172,11 @@
 .long   .Lulong_ptr-.Lcu_begin0 # DW_AT_type
 .uleb128 0xdeadbeefbaadf00d # DW_AT_const_value
 
+.byte   18  # Abbrev DW_TAG_variable
+.asciz  "data16"# DW_AT_name
+.long   .Lu128-.Lcu_begin0  # DW_AT_type
+.asciz 
""
 # DW_AT_const_value

walter-erquinigo wrote:

That's a good idea. I'll try that out!

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


[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

2024-10-30 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`cross-project-tests-sie-ubuntu-dwarf5` running on `doug-worker-1b` while 
building `lldb` at step 6 "test-build-unified-tree-check-cross-project".

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


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

```
Step 6 (test-build-unified-tree-check-cross-project) failure: test (failure)
 TEST 'cross-project-tests :: 
debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp' FAILED 

Exit Code: 2

Command Output (stdout):
--
optnone-struct-and-methods.cpp: nan/nan (nan) [Command '['/usr/bin/python3.10', 
'/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dex/../dexter.py',
 'run-debugger-internal-', 
'/tmp/lit-tmp-_vp9d6sj/dexter/tmpk746v0a3/tmphl_l3bho', 
'--working-directory=/tmp/lit-tmp-_vp9d6sj/dexter/tmpk746v0a3', 
'--unittest=off', '--indent-timer-level=3']' returned non-zero exit status 1.]
Command '['/usr/bin/python3.10', 
'/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dex/../dexter.py',
 'run-debugger-internal-', 
'/tmp/lit-tmp-_vp9d6sj/dexter/tmpk746v0a3/tmphl_l3bho', 
'--working-directory=/tmp/lit-tmp-_vp9d6sj/dexter/tmpk746v0a3', 
'--unittest=off', '--indent-timer-level=3']' returned non-zero exit status 1.
--
Command Output (stderr):
--
RUN: at line 1: 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/clang++
 -std=gnu++11 -O2 -g 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
+ 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/clang++
 -std=gnu++11 -O2 -g 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp:69:22:
 warning: first argument in call to '__builtin_memset' is a pointer to 
non-trivially copyable type '(anonymous namespace)::A' [-Wnontrivial-memaccess]
   69 | __builtin_memset(this, 0xFF, sizeof(*this));
  |  ^
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp:69:22:
 note: explicitly cast the pointer to silence this warning
   69 | __builtin_memset(this, 0xFF, sizeof(*this));
  |  ^
  |  (void*)
1 warning generated.
RUN: at line 2: "/usr/bin/python3.10" 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py"
 test --lldb-executable 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/lldb"
 --fail-lt 1.0 -w  --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
 --debugger 'lldb' -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
+ /usr/bin/python3.10 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py
 test --lldb-executable 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/lldb
 --fail-lt 1.0 -w --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
 --debugger lldb -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp





```



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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Augusto Noronha via lldb-commits

https://github.com/augusto2112 updated 
https://github.com/llvm/llvm-project/pull/113007

>From 7fc51bb1a812c5dd1bef8d96b51a17ff02eb23fc Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Tue, 22 Oct 2024 14:34:44 -0700
Subject: [PATCH] [lldb] Extend FindTypes to optionally search by mangled type
 name

Swift types have mangled type names. This adds functionality to look
up those types through the FindTypes API by searching for the mangled
type name instead of the regular name.
---
 lldb/include/lldb/Symbol/Type.h   | 16 +
 .../Plugins/SymbolFile/DWARF/DWARFDIE.cpp |  4 +-
 .../Plugins/SymbolFile/DWARF/DWARFDIE.h   |  2 +-
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 14 +
 .../DWARF/debug-types-mangled-name.ll | 63 +++
 lldb/tools/lldb-test/lldb-test.cpp| 35 +++
 6 files changed, 131 insertions(+), 3 deletions(-)
 create mode 100644 lldb/test/Shell/SymbolFile/DWARF/debug-types-mangled-name.ll

diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index 03d9f927997476..91188fe6ea4830 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -84,6 +84,9 @@ FLAGS_ENUM(TypeQueryOptions){
 /// matching type is found. When false, the type query should find all
 /// matching types.
 e_find_one = (1u << 4),
+// If set, treat TypeQuery::m_name as a mangled name that should be
+// searched.
+e_search_by_mangled_name = (1u << 5),
 };
 LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
 
@@ -300,6 +303,19 @@ class TypeQuery {
   m_options &= ~e_find_one;
   }
 
+  /// Returns true if the type query is supposed to treat the name to be
+  /// searched as a mangled name.
+  bool GetSearchByMangledName() const {
+return (m_options & e_search_by_mangled_name) != 0;
+  }
+
+  void SetSearchByMangledName(bool b) {
+if (b)
+  m_options |= e_search_by_mangled_name;
+else
+  m_options &= ~e_search_by_mangled_name;
+  }
+
   /// Access the internal compiler context array.
   ///
   /// Clients can use this to populate the context manually.
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
index d83740f8e2113b..4c9f1d8505f6e6 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
@@ -199,9 +199,9 @@ DWARFDIE::LookupDeepestBlock(lldb::addr_t address) const {
   return result;
 }
 
-const char *DWARFDIE::GetMangledName() const {
+const char *DWARFDIE::GetMangledName(bool substitute_name_allowed) const {
   if (IsValid())
-return m_die->GetMangledName(m_cu);
+return m_die->GetMangledName(m_cu, substitute_name_allowed);
   else
 return nullptr;
 }
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
index e1318953a384cd..077b78eb26d0c3 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
@@ -28,7 +28,7 @@ class DWARFDIE : public DWARFBaseDIE {
   // Accessors
 
   // Accessing information about a DIE
-  const char *GetMangledName() const;
+  const char *GetMangledName(bool substitute_name_allowed = true) const;
 
   const char *GetPubname() const;
 
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f23f8cc3d781d0..f39189b6cead42 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2758,6 +2758,20 @@ void SymbolFileDWARF::FindTypes(const TypeQuery &query, 
TypeResults &results) {
 return true; // Keep iterating over index types, language mismatch.
 }
 
+// Since mangled names are unique, we only need to check if the names are
+// the same.
+if (query.GetSearchByMangledName()) {
+  if (die.GetMangledName(/*substitute_name_allowed=*/false) !=
+  query.GetTypeBasename().GetStringRef())
+return true; // Keep iterating over index types, mangled name mismatch.
+  if (Type *matching_type = ResolveType(die, true, true)) {
+results.InsertUnique(matching_type->shared_from_this());
+return !results.Done(query); // Keep iterating if we aren't done.
+  }
+  return true; // Keep iterating over index types, weren't able to resolve
+   // this type
+}
+
 // Check the context matches
 std::vector die_context;
 if (query.GetModuleSearch())
diff --git a/lldb/test/Shell/SymbolFile/DWARF/debug-types-mangled-name.ll 
b/lldb/test/Shell/SymbolFile/DWARF/debug-types-mangled-name.ll
new file mode 100644
index 00..484e300b811f71
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/debug-types-mangled-name.ll
@@ -0,0 +1,63 @@
+; Test finding types by CompilerContext.
+; REQUIRES: aarch64
+; RUN: llc %s -filetype=obj -o %t.o
+; RUN: lldb-test symbols %t.

[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,42 @@
+// This test verifies that loading an ELF file that has no section headers can
+// load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+// the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+// segment.
+
+// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj \
+// RUN:   -o - - <<<".globl defined, undefined; defined:" | \
+// RUN:   ld.lld /dev/stdin -o - --hash-style=gnu -export-dynamic -shared \
+// RUN:   -z nosectionheader -o %t.gnu
+// RUN: %lldb %t.gnu -b \
+// RUN:   -o "image dump objfile" \
+// RUN:   | FileCheck %s --dump-input=always --check-prefix=GNU
+// GNU: (lldb) image dump objfile
+// GNU: Dumping headers for 1 module(s).
+// GNU: ObjectFileELF, file =
+// GNU: ELF Header
+// GNU: e_type  = 0x0003 ET_DYN
+// Make sure there are no section headers
+// GNU: e_shnum = 0x
+// Make sure we were able to load the symbols
+// GNU: Symtab, file = {{.*}}elf-dynsym.test.tmp.gnu, num_symbols = 2:
+// GNU-DAG: undefined
+// GNU-DAG: defined
+
+// RUN: llvm-mc -triple=x86_64-pc-linux -filetype=obj \
+// RUN:   -o - - <<<".globl defined, undefined; defined:" | \
+// RUN:   ld.lld /dev/stdin -o - --hash-style=sysv -export-dynamic -shared \
+// RUN:   -z nosectionheader -o %t.sysv
+// RUN: %lldb %t.sysv -b \
+// RUN:   -o "image dump objfile" \
+// RUN:   | FileCheck %s --dump-input=always --check-prefix=HASH
+// HASH: (lldb) image dump objfile
+// HASH: Dumping headers for 1 module(s).
+// HASH: ObjectFileELF, file =
+// HASH: ELF Header
+// HASH: e_type  = 0x0003 ET_DYN
+// Make sure there are no section headers
+// HASH: e_shnum = 0x
+// Make sure we were able to load the symbols
+// HASH: Symtab, file = {{.*}}elf-dynsym.test.tmp.sysv, num_symbols = 2:
+// HASH-DAG: undefined
+// HASH-DAG: defined

labath wrote:

In cases like this where the two outputs are (nearly) identical, I think its 
better to have a one check prefix for the common parts of the output -- it's 
less code and it better emphasizes the difference. This can be achieved by 
passing different sets of prefixes to the FileCheck command:
```
// RUN: ... | FileCheck --check-prefixes=BOTH,GNU
// RUN: ... | FileCheck --check-prefixes=BOTH,SYSV
// BOTH: This line is common for both formats
// GNU: This is gnu-specific output
// SYSV: This is sysv-specific output
```

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


[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #113787)

2024-10-30 Thread Walter Erquinigo via lldb-commits


@@ -238,9 +238,10 @@ def set_global(self, name, value, id=None):
 def stepIn(
 self, threadId=None, targetId=None, waitForStop=True, 
granularity="statement"
 ):
-self.dap_server.request_stepIn(
+response = self.dap_server.request_stepIn(
 threadId=threadId, targetId=targetId, granularity=granularity
 )
+assert response["success"] is True

walter-erquinigo wrote:

use `self.assertTrue`, which is more idiomatic in our codebase

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


[Lldb-commits] [lldb] [lldb] Expose structured command diagnostics via the SBAPI. (PR #112109)

2024-10-30 Thread Jordan Rupprecht via lldb-commits

rupprecht wrote:

Nevermind, 74e1554d7b4013a975cf5fb8df64a6419bb14a45 already fixed this, I was a 
bit behind trunk in my last test

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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread Adrian Prantl via lldb-commits

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


[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

2024-10-30 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

> Sorry to clarify. I think based on @felipepiovezan comment here: [#108870 
> (comment)](https://github.com/llvm/llvm-project/pull/108870#issuecomment-281588)
> 
> On Clang 17 we compile fine, just the assertion fails to find the expected 
> function name (because of the `std::__1` inline namespace):
> 
> ```
> FAIL: test_frame_recognizer 
> (TestLibcxxInternalsRecognizer.LibCxxInternalsRecognizerTestCase)
>Test that implementation details of libc++ are hidden
> --
> Traceback (most recent call last):
>   File 
> "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py",
>  line 60, in test_frame_recognizer
> self.assertIn(
> AssertionError: 'ranges::__sort::operator()' not found in 
> 'std::__1::__wrap_iter 
> std::__1::ranges::__sort::__fn::operator()[abi:ue170006],
>  std::__1::__wrap_iter, bool (*)(int, int), 
> std::__1::identity>(std::__1::__wrap_iter, std::__1::__wrap_iter, 
> bool (*)(int, int), std::__1::identity) const'
> Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1706_build/bin/clang
> ```
> 
> So really we should skip for <= 15. And fix the assertion for 17+

Yeah, I'm just now hitting this assertion on our downstream fork tests too

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


[Lldb-commits] [lldb] Remove a flaky and unnecessary check (PR #114251)

2024-10-30 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl created 
https://github.com/llvm/llvm-project/pull/114251

The order in which the libraries appear is not always stable and even if it 
were, this test is not the right place to check for this.

>From 553d4742e6972a068105177aafd47b3da2c01d8f Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Wed, 30 Oct 2024 08:44:58 -0700
Subject: [PATCH] Remove a flaky and unnecessary check

The order in which the libraries appear is not always stable and even
if it were, this test is not the right place to check for this.
---
 .../libcxx/initializerlist/TestInitializerList.py   | 2 --
 1 file changed, 2 deletions(-)

diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
index 0919eb3c5dd812..93d5392830b508 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py
@@ -40,5 +40,3 @@ def test(self):
 "frame variable ils",
 substrs=['[4] = "surprise it is a long string!! yay!!"'],
 )
-
-self.expect("image list", substrs=self.getLibcPlusPlusLibs())

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


[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

2024-10-30 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`cross-project-tests-sie-ubuntu` running on `doug-worker-1a` while building 
`lldb` at step 6 "test-build-unified-tree-check-cross-project".

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


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

```
Step 6 (test-build-unified-tree-check-cross-project) failure: test (failure)
 TEST 'cross-project-tests :: 
debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp' FAILED 

Exit Code: 2

Command Output (stdout):
--
optnone-struct-and-methods.cpp: nan/nan (nan) [Command '['/usr/bin/python3.8', 
'/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dex/../dexter.py',
 'run-debugger-internal-', 
'/tmp/lit-tmp-rsuqe0cc/dexter/tmpfx0batho/tmpuu6b_dj2', 
'--working-directory=/tmp/lit-tmp-rsuqe0cc/dexter/tmpfx0batho', 
'--unittest=off', '--indent-timer-level=3']' returned non-zero exit status 1.]
Command '['/usr/bin/python3.8', 
'/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dex/../dexter.py',
 'run-debugger-internal-', 
'/tmp/lit-tmp-rsuqe0cc/dexter/tmpfx0batho/tmpuu6b_dj2', 
'--working-directory=/tmp/lit-tmp-rsuqe0cc/dexter/tmpfx0batho', 
'--unittest=off', '--indent-timer-level=3']' returned non-zero exit status 1.
--
Command Output (stderr):
--
RUN: at line 1: 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/clang++ 
-std=gnu++11 -O2 -g 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
+ /home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/clang++ 
-std=gnu++11 -O2 -g 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp:69:22:
 warning: first argument in call to '__builtin_memset' is a pointer to 
non-trivially copyable type '(anonymous namespace)::A' [-Wnontrivial-memaccess]
   69 | __builtin_memset(this, 0xFF, sizeof(*this));
  |  ^
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp:69:22:
 note: explicitly cast the pointer to silence this warning
   69 | __builtin_memset(this, 0xFF, sizeof(*this));
  |  ^
  |  (void*)
1 warning generated.
RUN: at line 2: "/usr/bin/python3.8" 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py"
 test --lldb-executable 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/lldb" 
--fail-lt 1.0 -w  --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
 --debugger 'lldb' -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp
+ /usr/bin/python3.8 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py
 test --lldb-executable 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/lldb 
--fail-lt 1.0 -w --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter-tests/Output/optnone-struct-and-methods.cpp.tmp
 --debugger lldb -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp





```



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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Adrian Prantl via lldb-commits


@@ -0,0 +1,63 @@
+; Test finding types by CompilerContext.
+; REQUIRES: aarch64
+; RUN: llc %s -filetype=obj -o %t.o
+; RUN: lldb-test symbols %t.o -find=type --mangled-name=UniqueDifferentName | 
FileCheck %s 
+;
+; NORESULTS: Found 0 types
+; CHECK: Found 1 types:
+; CHECK: struct DifferentName {
+; CHECK-NEXT: int i;
+; CHECK-NEXT: }
+
+source_filename = "t.c"
+target datalayout = 
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32"
+target triple = "arm64-unknown-linux-gnu"
+
+%struct.SameName = type { i32 }
+%struct.DifferentName = type { i32 }
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local i32 @main() #0 !dbg !10 {
+entry:
+  %retval = alloca i32, align 4
+  %s = alloca %struct.SameName, align 4
+  %d = alloca %struct.DifferentName, align 4
+  store i32 0, ptr %retval, align 4
+#dbg_declare(ptr %s, !16, !DIExpression(), !20)
+#dbg_declare(ptr %d, !21, !DIExpression(), !25)
+  ret i32 0, !dbg !26
+}
+
+attributes #0 = { noinline nounwind optnone uwtable "frame-pointer"="non-leaf" 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="generic" "target-features"="+fp-armv8,+neon,+v8a,-fmv" }

adrian-prantl wrote:

Can you try to remove most of the attributes?

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


[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)

2024-10-30 Thread Adrian Prantl via lldb-commits

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


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


[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #113787)

2024-10-30 Thread Walter Erquinigo via lldb-commits


@@ -281,12 +270,11 @@ def test_clear_breakpoints_unset_breakpoints(self):
 self.assertEqual(
 len(breakpoints), len(lines), "expect %u source breakpoints" % 
(len(lines))
 )
-for breakpoint, index in zip(breakpoints, range(len(lines))):
+for index, breakpoint in enumerate(breakpoints):

walter-erquinigo wrote:

+1

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


[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #113787)

2024-10-30 Thread Walter Erquinigo via lldb-commits

https://github.com/walter-erquinigo approved this pull request.

beautiful

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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread Pavel Labath via lldb-commits


@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)

labath wrote:

[#if 
PY_VERSION_HEX>=0x0302](https://github.com/python/cpython/blob/dcad8fecbd5c8f1542f7a46e0c7bb7e1f27ab115/Include/patchlevel.h#L31)
 ?

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


[Lldb-commits] [lldb] [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (PR #114112)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/114112

>From c58438160c016841c6a72e53cd5c4985ebd1e521 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 11:19:33 -0700
Subject: [PATCH 1/3] [lldb] Use Py_InitializeFromConfig with Python >= 3.8
 (NFC)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475
---
 .../Python/ScriptInterpreterPython.cpp| 67 +++
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..d7734c5e199058 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,38 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+typedef wchar_t *str_type;
+static str_type g_python_home = []() -> str_type {
+  const char *lldb_python_home = LLDB_PYTHON_HOME;
+  const char *absolute_python_home = nullptr;
+  llvm::SmallString<64> path;
+  if (llvm::sys::path::is_absolute(lldb_python_home)) {
+absolute_python_home = lldb_python_home;
+  } else {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return nullptr;
+spec.GetPath(path);
+llvm::sys::path::append(path, lldb_python_home);
+absolute_python_home = path.c_str();
+  }
+  size_t size = 0;
+  return Py_DecodeLocale(absolute_python_home, &size);
+}();
+if (g_python_home != nullptr) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home);
+#else
+  Py_SetPythonHome(g_python_home);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +148,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  config.install_signal_handlers = 0;
+  Py_InitializeFromConfig(&config);
+  PyConfig_Clear(&config);
+  InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,31 +180,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
 
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,

>From 35d76ac118a4b900e28b33c1d958d44c7b22c21c Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Tue, 29 Oct 2024 11:36:42 -0700
Subject: [PATCH 2/3] Fix formatting

---
 .../ScriptInterpreter/Python/ScriptInterpreterPython.cpp | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index d7734c5e199058..cde1e707cd1cec 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -149,10 +149,10 @@ struct InitializePythonRAII {
 }
 
 #if (PY_MAJOR_VERSION == 3 && PY_MINOR_VER

[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)

2024-10-30 Thread Pavel Labath via lldb-commits

labath wrote:

Let's back up a bit. Before this patch, both the ValueObject class and the 
"frame var" command treated references essentially as pointers (in the example, 
`xp` is a pointer to `x` and `xpr` is a reference to `xp`):
```
(lldb) v *x x &x
(int) ::x = 47
(int *) &::x = 0x8010
error: not a pointer or reference type: (int) ::x
(lldb) v *xp xp &xp
(int) *xp = 47
(int *) ::xp = 0x8010
(int **) &::xp = 0x8018
(lldb) v *xpr xpr &xpr
(int *) *xpr = 0x8010
(int *&) ::xpr = 0x8018: {
  &::xpr = 0x8010
}
(int *&*) &::xpr = 0x7dc8
```

Now, you may or may not agree with that behavior, but at least its consistent: 
notice how "dereferencing" `xpr` gives you the value of `xp` and taking the 
address of `xpr` gives you its "address" (in spite of what the C++ standard 
says, the reference does exist somewhere and that place has an address).

After this patch, we get this:

```
(lldb) v *xpr xpr &xpr
(int *) *xpr = 0x8010
(int *&) ::xpr = 0x8018: {
  &::xpr = 0x8010
}
(int **) &&::xpr = 0x8018
```
I.e. taking the "address of" the reference gives you the same thing as its 
"value", "dereferencing" the reference still gives you the object that is being 
referenced (it does *not* dereference the pointer behind it like you would 
expect according to the c++ rules), and there's no way to determine the 
location of the reference.

So, either this patch is incorrect (if you believe that the current behavior 
was intentional) or incomplete (if you believe that we should follow the c++ 
rules). Either way, I believe we should revert this and discuss the problem in 
more detail.

FWIW, I agree with what you're trying to achieve (making "frame var" follow c++ 
rules for references). I just think this needs to be handled more 
wholistically. And I'm not entirely sure that the fix belongs in the 
ValueObject class.(*)  I also believe there should be a way to get the 
"location" of the reference (but that doesn't have to be exposed through "frame 
var")

(*) I'm not saying it does *not* belong there either, but I think you could 
make a stronger case for treating references like "fancy pointers" in the 
ValueObject class -- i.e. maintaining the status quo there.

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


[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-30 Thread Zequan Wu via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Add a link to LLDB's Discord channel on the website (PR #114289)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-debuginfo

Author: Zequan Wu (ZequanWu)


Changes

This is the second half of https://github.com/llvm/llvm-project/pull/90008.

Essentially, it replaces the work of resolving template types when we just need 
the qualified names with walking the DIE tree using `DWARFTypePrinter`.

### Result
For an internal target, the time spent on `expr *this` for the first time 
reduced from 28 secs to 17 secs.

---

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


13 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+14-7) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h (+7) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp (+35) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h (+15) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp (+25) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h (+3) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+9-27) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (-20) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (-4) 
- (added) lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp 
(+31) 
- (modified) llvm/include/llvm/DebugInfo/DWARF/DWARFDie.h (+2) 
- (modified) llvm/include/llvm/DebugInfo/DWARF/DWARFTypePrinter.h (+20-11) 
- (modified) llvm/lib/DebugInfo/DWARF/DWARFDie.cpp (+9) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index a30d898a93cc4d..41cb11f94a45e8 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -44,6 +44,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Type.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/DebugInfo/DWARF/DWARFTypePrinter.h"
 #include "llvm/Demangle/Demangle.h"
 
 #include 
@@ -825,11 +826,11 @@ std::string 
DWARFASTParserClang::GetDIEClassTemplateParams(DWARFDIE die) {
   if (llvm::StringRef(die.GetName()).contains("<"))
 return {};
 
-  TypeSystemClang::TemplateParameterInfos template_param_infos;
-  if (ParseTemplateParameterInfos(die, template_param_infos))
-return m_ast.PrintTemplateParams(template_param_infos);
-
-  return {};
+  std::string name;
+  llvm::raw_string_ostream os(name);
+  llvm::DWARFTypePrinter type_printer(os);
+  type_printer.appendAndTerminateTemplateParameters(die);
+  return name;
 }
 
 void DWARFASTParserClang::MapDeclDIEToDefDIE(
@@ -1617,9 +1618,9 @@ void DWARFASTParserClang::GetUniqueTypeNameAndDeclaration(
 case DW_TAG_structure_type:
 case DW_TAG_union_type: {
   if (const char *class_union_struct_name = parent_decl_ctx_die.GetName()) 
{
-qualified_name.insert(
-0, GetDIEClassTemplateParams(parent_decl_ctx_die));
 qualified_name.insert(0, "::");
+qualified_name.insert(0,
+  GetDIEClassTemplateParams(parent_decl_ctx_die));
 qualified_name.insert(0, class_union_struct_name);
   }
   parent_decl_ctx_die = parent_decl_ctx_die.GetParentDeclContextDIE();
@@ -1672,6 +1673,12 @@ DWARFASTParserClang::ParseStructureLikeDIE(const 
SymbolContext &sc,
   if (attrs.name) {
 GetUniqueTypeNameAndDeclaration(die, cu_language, unique_typename,
 unique_decl);
+if (log) {
+  dwarf->GetObjectFile()->GetModule()->LogMessage(
+  log, "SymbolFileDWARF({0:p}) - {1:x16}: {2} has unique name: {3} ",
+  static_cast(this), die.GetID(), DW_TAG_value_to_name(tag),
+  unique_typename.AsCString());
+}
 if (UniqueDWARFASTType *unique_ast_entry_type =
 dwarf->GetUniqueDWARFASTTypeMap().Find(
 unique_typename, die, unique_decl, byte_size,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
index 235343d2271223..ca25801137be38 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
@@ -24,9 +24,11 @@ class DWARFUnit;
 class DWARFDebugInfoEntry;
 class DWARFDeclContext;
 class SymbolFileDWARF;
+class DWARFFormValue;
 
 class DWARFBaseDIE {
 public:
+  using DWARFFormValue = dwarf::DWARFFormValue;
   DWARFBaseDIE() = default;
 
   DWARFBaseDIE(DWARFUnit *cu, DWARFDebugInfoEntry *die)
@@ -46,6 +48,7 @@ class DWARFBaseDIE {
   explicit operator bool() const { return IsValid(); }
 
   bool IsValid() const { return m_cu && m_die; }
+  bool isValid() const { return IsValid(); }
 
   bool HasChildren() const;
 
@@ -85,6 +88,8 @@ class DWARFBaseDIE {
   // Accessing information about a DIE
   dw_tag_t Tag() const;
 
+  dw_tag_t getTag() const { return Tag(); }
+
   dw_offset_t GetOffset() const;

[Lldb-commits] [lldb] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on clang <= 17 (PR #114122)

2024-10-30 Thread Adrian Vogelsgesang via lldb-commits

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

>From 00d136ed33cdc4362f7f23804ee184ddb1fb2539 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Tue, 29 Oct 2024 20:23:13 +
Subject: [PATCH 1/2] [lldb][test] Skip `LibCxxInternalsRecognizerTestCase` on
 clang <= 17

Because of a build failure with libc++17.
See 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/912/execution/node/107/log/
---
 .../libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
index ad48208f21e502..0270e78808c646 100644
--- 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
+++ 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
@@ -8,6 +8,7 @@ class LibCxxInternalsRecognizerTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @add_test_categories(["libc++"])
+@skipIf(compiler="clang", compiler_version=["<", "18.0"])
 def test_frame_recognizer(self):
 """Test that implementation details of libc++ are hidden"""
 self.build()

>From f59335ac2e4d69811ad5257a0954f42a86236843 Mon Sep 17 00:00:00 2001
From: Adrian Vogelsgesang 
Date: Wed, 30 Oct 2024 23:26:57 +
Subject: [PATCH 2/2] Correctly fix the issue

---
 .../TestLibcxxInternalsRecognizer.py| 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
index 0270e78808c646..5a26c045a312e8 100644
--- 
a/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
+++ 
b/lldb/test/API/lang/cpp/libcxx-internals-recognizer/TestLibcxxInternalsRecognizer.py
@@ -3,12 +3,13 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
+import re
 
 class LibCxxInternalsRecognizerTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @add_test_categories(["libc++"])
-@skipIf(compiler="clang", compiler_version=["<", "18.0"])
+@skipIf(compiler="clang", compiler_version=["<", "16.0"])
 def test_frame_recognizer(self):
 """Test that implementation details of libc++ are hidden"""
 self.build()
@@ -22,7 +23,7 @@ def test_frame_recognizer(self):
 # We never hide the frame of the entry-point into the standard 
library, even
 # if the name starts with `__` which usually indicates an internal 
function.
 "ranges_sort_less(int, int)": [
-"ranges::__sort::operator()",
+re.compile("ranges::__sort::(__fn::)?operator\(\)"),
 "test_algorithms",
 ],
 # `ranges::views::transform` internally uses `std::invoke`, and 
that
@@ -58,9 +59,11 @@ def test_frame_recognizer(self):
 ):
 frame_id = frame_id + 1
 # Expect the correct parent frame
-self.assertIn(
-expected_parent, 
thread.GetFrameAtIndex(frame_id).GetFunctionName()
-)
+func_name = thread.GetFrameAtIndex(frame_id).GetFunctionName()
+if isinstance(expected_parent, re.Pattern):
+self.assertTrue(expected_parent.search(func_name) is not 
None, f"'{expected_parent}' not found in '{func_name}'")
+else:
+self.assertIn(expected_parent, func_name)
 frame_id = frame_id + 1
 process.Continue()
 

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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 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 f582cd3dc70fa8c9519f74f16ab0a33ad663038e 
48c51370545165095867c480ddf8b7fdbb312630 --extensions cpp -- 
lldb/source/Target/ThreadPlanStepInRange.cpp 
lldb/test/API/functionalities/inline-stepping/calling.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index 7ed88a872c..ba71c25a3c 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1; // After caller_trivial_inline_3
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {

``




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


[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

2024-10-30 Thread via lldb-commits

jimingham wrote:

That's fixed in:



https://github.com/llvm/llvm-project/pull/114337
Fix stepping away from the bottom-most frame of a virtual inlined call stack. 
by jimingham · Pull Request #114337 · llvm/llvm-project
github.com

which is waiting on review.  Would have fixed this sooner but dexter is a 
pretty opaque test harness...

Jim


> On Oct 30, 2024, at 4:07 PM, dyung ***@***.***> wrote:
> 
> 
> @jimingham  your change is causing two 
> cross-project-test failures, can you take a look or revert if you need time 
> to investigate?
> 
> —
> 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/114158
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114337

>From 48c51370545165095867c480ddf8b7fdbb312630 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 17:18:39 -0700
Subject: [PATCH 1/2] Fix stepping away from the bottom-most frame of a virtual
 inlined call stack.

---
 lldb/source/Target/ThreadPlanStepInRange.cpp  |  3 ++-
 .../inline-stepping/TestInlineStepping.py | 11 ++-
 .../API/functionalities/inline-stepping/calling.cpp   |  2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lldb/source/Target/ThreadPlanStepInRange.cpp 
b/lldb/source/Target/ThreadPlanStepInRange.cpp
index 325a70619908b6..224a17d896ccf0 100644
--- a/lldb/source/Target/ThreadPlanStepInRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepInRange.cpp
@@ -489,7 +489,8 @@ bool ThreadPlanStepInRange::DoWillResume(lldb::StateType 
resume_state,
 bool ThreadPlanStepInRange::IsVirtualStep() {
   if (m_virtual_step == eLazyBoolCalculate) {
 Thread &thread = GetThread();
-if (thread.GetCurrentInlinedDepth() == UINT32_MAX)
+uint32_t cur_inline_depth = thread.GetCurrentInlinedDepth();
+if (cur_inline_depth == UINT32_MAX || cur_inline_depth == 0)
   m_virtual_step = eLazyBoolNo;
 else
   m_virtual_step = eLazyBoolYes;
diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..fe61b8e48f6d6d 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,7 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos):
+def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -408,6 +408,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos):
 # stepping for this function...
 break
 
+if one_more_step_loc:
+thread.StepInto()
+frame_0 = thread.frame[0]
+self.assertEqual(frame_0.line_entry.line, 
line_number(self.main_source, one_more_step_loc),
+  "Was able to 
step one more time")
 process.Kill()
 target.Clear()
 
@@ -420,3 +425,7 @@ def virtual_inline_stepping(self):
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
+self.run_to_call_site_and_step(
+"In caller_trivial_inline_3", "caller_trivial_inline_3", 4, "After 
caller_trivial_inline_3"
+)
+
diff --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index d7ee56b3c07909..7ed88a872c4eba 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1;
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {

>From 3617a91f4e85a7a8de09dacfd3931abc729e44f2 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 18:01:20 -0700
Subject: [PATCH 2/2] uglification

---
 .../inline-stepping/TestInlineStepping.py   | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index fe61b8e48f6d6d..3283918f852743 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,9 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
+def run_to_call_site_and_step(
+self, source_regex, func_name, start_pos, one_more_step_loc=None
+):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -411,8 +413,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos, one_more
 if one_more_step_l

[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/114337

>From 48c51370545165095867c480ddf8b7fdbb312630 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 17:18:39 -0700
Subject: [PATCH 1/3] Fix stepping away from the bottom-most frame of a virtual
 inlined call stack.

---
 lldb/source/Target/ThreadPlanStepInRange.cpp  |  3 ++-
 .../inline-stepping/TestInlineStepping.py | 11 ++-
 .../API/functionalities/inline-stepping/calling.cpp   |  2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lldb/source/Target/ThreadPlanStepInRange.cpp 
b/lldb/source/Target/ThreadPlanStepInRange.cpp
index 325a70619908b6..224a17d896ccf0 100644
--- a/lldb/source/Target/ThreadPlanStepInRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepInRange.cpp
@@ -489,7 +489,8 @@ bool ThreadPlanStepInRange::DoWillResume(lldb::StateType 
resume_state,
 bool ThreadPlanStepInRange::IsVirtualStep() {
   if (m_virtual_step == eLazyBoolCalculate) {
 Thread &thread = GetThread();
-if (thread.GetCurrentInlinedDepth() == UINT32_MAX)
+uint32_t cur_inline_depth = thread.GetCurrentInlinedDepth();
+if (cur_inline_depth == UINT32_MAX || cur_inline_depth == 0)
   m_virtual_step = eLazyBoolNo;
 else
   m_virtual_step = eLazyBoolYes;
diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..fe61b8e48f6d6d 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,7 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos):
+def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -408,6 +408,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos):
 # stepping for this function...
 break
 
+if one_more_step_loc:
+thread.StepInto()
+frame_0 = thread.frame[0]
+self.assertEqual(frame_0.line_entry.line, 
line_number(self.main_source, one_more_step_loc),
+  "Was able to 
step one more time")
 process.Kill()
 target.Clear()
 
@@ -420,3 +425,7 @@ def virtual_inline_stepping(self):
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
+self.run_to_call_site_and_step(
+"In caller_trivial_inline_3", "caller_trivial_inline_3", 4, "After 
caller_trivial_inline_3"
+)
+
diff --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index d7ee56b3c07909..7ed88a872c4eba 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1;
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {

>From 3617a91f4e85a7a8de09dacfd3931abc729e44f2 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 18:01:20 -0700
Subject: [PATCH 2/3] uglification

---
 .../inline-stepping/TestInlineStepping.py   | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index fe61b8e48f6d6d..3283918f852743 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,9 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
+def run_to_call_site_and_step(
+self, source_regex, func_name, start_pos, one_more_step_loc=None
+):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -411,8 +413,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos, one_more
 if one_more_step_l

[Lldb-commits] [lldb] [llvm] [lldb-dap] Support column breakpoints (PR #113787)

2024-10-30 Thread John Harrison via lldb-commits


@@ -910,6 +911,183 @@ void request_attach(const llvm::json::Object &request) {
   }
 }
 
+// "BreakpointLocationsRequest": {
+//   "allOf": [ { "$ref": "#/definitions/Request" }, {
+// "type": "object",
+// "description": "The `breakpointLocations` request returns all possible
+// locations for source breakpoints in a given range.\nClients should only
+// call this request if the corresponding capability
+// `supportsBreakpointLocationsRequest` is true.",
+// "properties": {
+//   "command": {
+// "type": "string",
+// "enum": [ "breakpointLocations" ]
+//   },
+//   "arguments": {
+// "$ref": "#/definitions/BreakpointLocationsArguments"
+//   }
+// },
+// "required": [ "command" ]
+//   }]
+// },
+// "BreakpointLocationsArguments": {
+//   "type": "object",
+//   "description": "Arguments for `breakpointLocations` request.",
+//   "properties": {
+// "source": {
+//   "$ref": "#/definitions/Source",
+//   "description": "The source location of the breakpoints; either
+//   `source.path` or `source.sourceReference` must be specified."
+// },
+// "line": {
+//   "type": "integer",
+//   "description": "Start line of range to search possible breakpoint
+//   locations in. If only the line is specified, the request returns all
+//   possible locations in that line."
+// },
+// "column": {
+//   "type": "integer",
+//   "description": "Start position within `line` to search possible
+//   breakpoint locations in. It is measured in UTF-16 code units and the
+//   client capability `columnsStartAt1` determines whether it is 0- or
+//   1-based. If no column is given, the first position in the start line 
is
+//   assumed."
+// },
+// "endLine": {
+//   "type": "integer",
+//   "description": "End line of range to search possible breakpoint
+//   locations in. If no end line is given, then the end line is assumed to
+//   be the start line."
+// },
+// "endColumn": {
+//   "type": "integer",
+//   "description": "End position within `endLine` to search possible
+//   breakpoint locations in. It is measured in UTF-16 code units and the
+//   client capability `columnsStartAt1` determines whether it is 0- or
+//   1-based. If no end column is given, the last position in the end line
+//   is assumed."
+// }
+//   },
+//   "required": [ "source", "line" ]
+// },
+// "BreakpointLocationsResponse": {
+//   "allOf": [ { "$ref": "#/definitions/Response" }, {
+// "type": "object",
+// "description": "Response to `breakpointLocations` request.\nContains
+// possible locations for source breakpoints.",
+// "properties": {
+//   "body": {
+// "type": "object",
+// "properties": {
+//   "breakpoints": {
+// "type": "array",
+// "items": {
+//   "$ref": "#/definitions/BreakpointLocation"
+// },
+// "description": "Sorted set of possible breakpoint locations."
+//   }
+// },
+// "required": [ "breakpoints" ]
+//   }
+// },
+// "required": [ "body" ]
+//   }]
+// },
+// "BreakpointLocation": {
+//   "type": "object",
+//   "description": "Properties of a breakpoint location returned from the
+//   `breakpointLocations` request.",
+//   "properties": {
+// "line": {
+//   "type": "integer",
+//   "description": "Start line of breakpoint location."
+// },
+// "column": {
+//   "type": "integer",
+//   "description": "The start position of a breakpoint location. Position
+//   is measured in UTF-16 code units and the client capability
+//   `columnsStartAt1` determines whether it is 0- or 1-based."
+// },
+// "endLine": {
+//   "type": "integer",
+//   "description": "The end line of breakpoint location if the location
+//   covers a range."
+// },
+// "endColumn": {
+//   "type": "integer",
+//   "description": "The end position of a breakpoint location (if the
+//   location covers a range). Position is measured in UTF-16 code units 
and
+//   the client capability `columnsStartAt1` determines whether it is 0- or
+//   1-based."
+// }
+//   },
+//   "required": [ "line" ]
+// },
+void request_breakpointLocations(const llvm::json::Object &request) {

ashgti wrote:

That sounds reasonable to me

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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 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 
f582cd3dc70fa8c9519f74f16ab0a33ad663038e...48c51370545165095867c480ddf8b7fdbb312630
 lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
``





View the diff from darker here.


``diff
--- TestInlineStepping.py   2024-10-31 00:52:33.00 +
+++ TestInlineStepping.py   2024-10-31 00:58:17.241211 +
@@ -362,11 +362,13 @@
 self.thread = threads[0]
 
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
+def run_to_call_site_and_step(
+self, source_regex, func_name, start_pos, one_more_step_loc=None
+):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
 call_site_line_num = line_number(self.main_source, source_regex)
 target, process, thread, bkpt = lldbutil.run_to_line_breakpoint(
@@ -409,12 +411,15 @@
 break
 
 if one_more_step_loc:
 thread.StepInto()
 frame_0 = thread.frame[0]
-self.assertEqual(frame_0.line_entry.line, 
line_number(self.main_source, one_more_step_loc),
-  "Was able to 
step one more time")
+self.assertEqual(
+frame_0.line_entry.line,
+line_number(self.main_source, one_more_step_loc),
+"Was able to step one more time",
+)
 process.Kill()
 target.Clear()
 
 def virtual_inline_stepping(self):
 """Use the Python API's to step through a virtual inlined stack"""
@@ -424,8 +429,10 @@
 )
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
 self.run_to_call_site_and_step(
-"In caller_trivial_inline_3", "caller_trivial_inline_3", 4, "After 
caller_trivial_inline_3"
-)
-
+"In caller_trivial_inline_3",
+"caller_trivial_inline_3",
+4,
+"After caller_trivial_inline_3",
+)

``




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


[Lldb-commits] [lldb] 3243e3d - Fix stepping away from the bottom-most frame of a virtual inlined call stack. (#114337)

2024-10-30 Thread via lldb-commits

Author: jimingham
Date: 2024-10-30T18:26:38-07:00
New Revision: 3243e3d8872585091d65ea7ff0639155b4c1dd7a

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

LOG: Fix stepping away from the bottom-most frame of a virtual inlined call 
stack. (#114337)

The computation of 'Thread::IsVirtualStep" was wrong - it called being
at the bottom of a virtual call stack a "virtual step" but that is
actually when you've gotten to concrete code and need to step for real.

I also added a test for this.

Added: 


Modified: 
lldb/source/Target/ThreadPlanStepInRange.cpp
lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
lldb/test/API/functionalities/inline-stepping/calling.cpp

Removed: 




diff  --git a/lldb/source/Target/ThreadPlanStepInRange.cpp 
b/lldb/source/Target/ThreadPlanStepInRange.cpp
index 325a70619908b6..224a17d896ccf0 100644
--- a/lldb/source/Target/ThreadPlanStepInRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepInRange.cpp
@@ -489,7 +489,8 @@ bool ThreadPlanStepInRange::DoWillResume(lldb::StateType 
resume_state,
 bool ThreadPlanStepInRange::IsVirtualStep() {
   if (m_virtual_step == eLazyBoolCalculate) {
 Thread &thread = GetThread();
-if (thread.GetCurrentInlinedDepth() == UINT32_MAX)
+uint32_t cur_inline_depth = thread.GetCurrentInlinedDepth();
+if (cur_inline_depth == UINT32_MAX || cur_inline_depth == 0)
   m_virtual_step = eLazyBoolNo;
 else
   m_virtual_step = eLazyBoolYes;

diff  --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..3283918f852743 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,9 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos):
+def run_to_call_site_and_step(
+self, source_regex, func_name, start_pos, one_more_step_loc=None
+):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -408,6 +410,14 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos):
 # stepping for this function...
 break
 
+if one_more_step_loc:
+thread.StepInto()
+frame_0 = thread.frame[0]
+self.assertEqual(
+frame_0.line_entry.line,
+line_number(self.main_source, one_more_step_loc),
+"Was able to step one more time",
+)
 process.Kill()
 target.Clear()
 
@@ -420,3 +430,9 @@ def virtual_inline_stepping(self):
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
+self.run_to_call_site_and_step(
+"In caller_trivial_inline_3",
+"caller_trivial_inline_3",
+4,
+"After caller_trivial_inline_3",
+)

diff  --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index d7ee56b3c07909..ba71c25a3c648f 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1;
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {



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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

jimingham wrote:

This is a fairly uncontroversial patch, and fixes a breakage in the dexter 
tests (part of the "cross-project-tests").  So I'm going to push this now even 
though folks haven't had a chance to review it yet.

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


[Lldb-commits] [lldb] [lldb] Set return status to Failed when Python command raises uncaught exception (PR #113996)

2024-10-30 Thread Dave Lee via lldb-commits


@@ -621,6 +623,9 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommand(
 pfunc(debugger_arg, PythonString(args),
   SWIGBridge::ToSWIGWrapper(std::move(exe_ctx_ref_sp)), 
cmd_retobj_arg.obj(), dict);
 
+  if (PyErr_Occurred())

kastiglione wrote:

I changed the message to include function or class name.

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


[Lldb-commits] [lldb] f7c36d2 - [lldb] Fix API test for file redirection to existing files (#114119)

2024-10-30 Thread via lldb-commits

Author: Wanyi
Date: 2024-10-30T17:00:40-04:00
New Revision: f7c36d2f88e05a1747fa7916ad2fefdd9d459a55

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

LOG: [lldb] Fix API test for file redirection to existing files (#114119)

API test failed for remote platform in
[#112657](https://github.com/llvm/llvm-project/pull/112657)

Previously when putting files onto remote platform, I used `platform
file write -d ` which actually required a `platform file open
` first in order to obtain a file descriptor.
eg. in file
[TestGDBRemotePlatformFile.py](https://github.com/llvm/llvm-project/blob/94e7d9c0bfe517507ea08b00fb00c32fb2837a82/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py#L24-L32)
To fix this, use the `platform put-file` method, which is used in the
`redirect_stdin` from this test already.

Added: 


Modified: 
lldb/test/API/python_api/process/io/TestProcessIO.py

Removed: 




diff  --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 3b5c7c48c51f4d..5d9727add399b5 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -99,31 +99,38 @@ def test_stdout_stderr_redirection(self):
 @expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
 @skipIfDarwinEmbedded  # debugserver can't create/write files on the device
 def test_stdout_stderr_redirection_to_existing_files(self):
-"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
redirect to output files already exist."""
 self.setup_test()
 self.build()
 self.create_target()
-self.write_file_with_placeholder(self.output_file)
-self.write_file_with_placeholder(self.error_file)
-self.redirect_stdout()
-self.redirect_stderr()
-self.run_process(True)
-output = self.read_output_file_and_delete()
-error = self.read_error_file_and_delete()
-self.check_process_output(output, error)
 
-def write_file_with_placeholder(self, target_file):
+# Create the output and error files with placeholder
 placeholder = "This content should be overwritten."
+# Local file directory and working directory are the same for local 
debugging
+f = open(self.local_output_file, "w")
+f.write(placeholder)
+f.close()
+f = open(self.local_error_file, "w")
+f.write(placeholder)
+f.close()
 if lldb.remote_platform:
 self.runCmd(
-'platform file write "{target}" -d "{data}"'.format(
-target=target_file, data=placeholder
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_output_file, remote=self.output_file
+)
+)
+self.runCmd(
+'platform put-file "{local}" "{remote}"'.format(
+local=self.local_error_file, remote=self.error_file
 )
 )
-else:
-f = open(target_file, "w")
-f.write(placeholder)
-f.close()
+
+self.redirect_stdout()
+self.redirect_stderr()
+self.run_process(True)
+output = self.read_output_file_and_delete()
+error = self.read_error_file_and_delete()
+self.check_process_output(output, error)
 
 # target_file - path on local file system or remote file system if running 
remote
 # local_file - path on local system



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


[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Zequan Wu (ZequanWu)


Changes

This is the second half of https://github.com/llvm/llvm-project/pull/90008.

Essentially, it replaces the work of resolving template types when we just need 
the qualified names with walking the DIE tree using `DWARFTypePrinter`.

### Result
For an internal target, the time spent on `expr *this` for the first time 
reduced from 28 secs to 17 secs.

---

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


13 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+14-7) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h (+7) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp (+35) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h (+15) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp (+25) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h (+3) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+9-27) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (-20) 
- (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (-4) 
- (added) lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp 
(+31) 
- (modified) llvm/include/llvm/DebugInfo/DWARF/DWARFDie.h (+2) 
- (modified) llvm/include/llvm/DebugInfo/DWARF/DWARFTypePrinter.h (+20-11) 
- (modified) llvm/lib/DebugInfo/DWARF/DWARFDie.cpp (+9) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index a30d898a93cc4d..41cb11f94a45e8 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -44,6 +44,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Type.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/DebugInfo/DWARF/DWARFTypePrinter.h"
 #include "llvm/Demangle/Demangle.h"
 
 #include 
@@ -825,11 +826,11 @@ std::string 
DWARFASTParserClang::GetDIEClassTemplateParams(DWARFDIE die) {
   if (llvm::StringRef(die.GetName()).contains("<"))
 return {};
 
-  TypeSystemClang::TemplateParameterInfos template_param_infos;
-  if (ParseTemplateParameterInfos(die, template_param_infos))
-return m_ast.PrintTemplateParams(template_param_infos);
-
-  return {};
+  std::string name;
+  llvm::raw_string_ostream os(name);
+  llvm::DWARFTypePrinter type_printer(os);
+  type_printer.appendAndTerminateTemplateParameters(die);
+  return name;
 }
 
 void DWARFASTParserClang::MapDeclDIEToDefDIE(
@@ -1617,9 +1618,9 @@ void DWARFASTParserClang::GetUniqueTypeNameAndDeclaration(
 case DW_TAG_structure_type:
 case DW_TAG_union_type: {
   if (const char *class_union_struct_name = parent_decl_ctx_die.GetName()) 
{
-qualified_name.insert(
-0, GetDIEClassTemplateParams(parent_decl_ctx_die));
 qualified_name.insert(0, "::");
+qualified_name.insert(0,
+  GetDIEClassTemplateParams(parent_decl_ctx_die));
 qualified_name.insert(0, class_union_struct_name);
   }
   parent_decl_ctx_die = parent_decl_ctx_die.GetParentDeclContextDIE();
@@ -1672,6 +1673,12 @@ DWARFASTParserClang::ParseStructureLikeDIE(const 
SymbolContext &sc,
   if (attrs.name) {
 GetUniqueTypeNameAndDeclaration(die, cu_language, unique_typename,
 unique_decl);
+if (log) {
+  dwarf->GetObjectFile()->GetModule()->LogMessage(
+  log, "SymbolFileDWARF({0:p}) - {1:x16}: {2} has unique name: {3} ",
+  static_cast(this), die.GetID(), DW_TAG_value_to_name(tag),
+  unique_typename.AsCString());
+}
 if (UniqueDWARFASTType *unique_ast_entry_type =
 dwarf->GetUniqueDWARFASTTypeMap().Find(
 unique_typename, die, unique_decl, byte_size,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
index 235343d2271223..ca25801137be38 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
@@ -24,9 +24,11 @@ class DWARFUnit;
 class DWARFDebugInfoEntry;
 class DWARFDeclContext;
 class SymbolFileDWARF;
+class DWARFFormValue;
 
 class DWARFBaseDIE {
 public:
+  using DWARFFormValue = dwarf::DWARFFormValue;
   DWARFBaseDIE() = default;
 
   DWARFBaseDIE(DWARFUnit *cu, DWARFDebugInfoEntry *die)
@@ -46,6 +48,7 @@ class DWARFBaseDIE {
   explicit operator bool() const { return IsValid(); }
 
   bool IsValid() const { return m_cu && m_die; }
+  bool isValid() const { return IsValid(); }
 
   bool HasChildren() const;
 
@@ -85,6 +88,8 @@ class DWARFBaseDIE {
   // Accessing information about a DIE
   dw_tag_t Tag() const;
 
+  dw_tag_t getTag() const { return Tag(); }
+
   dw_offset_t GetOffset() const;
 
  

[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-30 Thread Zequan Wu via lldb-commits

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


[Lldb-commits] [lldb] [lldb][NativePDB] Parse global variables. (PR #114303)

2024-10-30 Thread Zequan Wu via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

2024-10-30 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Fix API test for file redirection to existing files (PR #114119)

2024-10-30 Thread via lldb-commits

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


[Lldb-commits] [lldb] [lldb][NativePDB] Parse global variables. (PR #114303)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Zequan Wu (ZequanWu)


Changes

This doesn't parse S_CONSTANT case yet, because I found that 
`std::strong_ordering::equal` being a S_CONSTANT and has type of LF_STRUCTURE 
which is not currently handled when creating dwarf expression for the variable. 
Left a TODO for it to be finish later.

This makes `lldb/test/Shell/SymbolFile/PDB/ast-restore.test` passes on windows 
with native pdb plugin.


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


5 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
(+31-8) 
- (modified) lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h 
(+1) 
- (modified) lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp (+3-2) 
- (modified) lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp (+6-5) 
- (modified) lldb/test/Shell/SymbolFile/PDB/ast-restore.test (+2-7) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 7fded6a31a3af5..3536599693cb46 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -365,18 +365,20 @@ void SymbolFileNativePDB::InitializeObject() {
 }
 
 uint32_t SymbolFileNativePDB::CalculateNumCompileUnits() {
+  if (m_cu_count)
+return *m_cu_count;
   const DbiModuleList &modules = m_index->dbi().modules();
-  uint32_t count = modules.getModuleCount();
-  if (count == 0)
-return count;
+  m_cu_count = modules.getModuleCount();
+  if (*m_cu_count == 0)
+return 0;
 
   // The linker can inject an additional "dummy" compilation unit into the
   // PDB. Ignore this special compile unit for our purposes, if it is there.
   // It is always the last one.
-  DbiModuleDescriptor last = modules.getModuleDescriptor(count - 1);
+  DbiModuleDescriptor last = modules.getModuleDescriptor(*m_cu_count - 1);
   if (last.getModuleName() == "* Linker *")
---count;
-  return count;
+--*m_cu_count;
+  return *m_cu_count;
 }
 
 Block &SymbolFileNativePDB::CreateBlock(PdbCompilandSymId block_id) {
@@ -888,7 +890,8 @@ VariableSP 
SymbolFileNativePDB::CreateGlobalVariable(PdbGlobalSymId var_id) {
 
   CompUnitSP comp_unit;
   std::optional modi = m_index->GetModuleIndexForVa(addr);
-  if (!modi) {
+  // Some globals has modi points to the linker module, ignore them.
+  if (!modi || modi >= CalculateNumCompileUnits()) {
 return nullptr;
   }
 
@@ -1810,7 +1813,27 @@ 
SymbolFileNativePDB::ParseVariablesForCompileUnit(CompileUnit &comp_unit,
   VariableList &variables) {
   PdbSymUid sym_uid(comp_unit.GetID());
   lldbassert(sym_uid.kind() == PdbSymUidKind::Compiland);
-  return 0;
+  for (const uint32_t gid : m_index->globals().getGlobalsTable()) {
+PdbGlobalSymId global{gid, false};
+CVSymbol sym = m_index->ReadSymbolRecord(global);
+// TODO: Handle S_CONSTANT which might be a record type (e.g.
+// std::strong_ordering::equal). Currently
+// lldb_private::npdb::MakeConstantLocationExpression doesn't handle this
+// case and will crash if we do create global variables from it.
+switch (sym.kind()) {
+case SymbolKind::S_GDATA32:
+case SymbolKind::S_LDATA32:
+case SymbolKind::S_GTHREAD32:
+case SymbolKind::S_LTHREAD32: {
+  if (VariableSP var = GetOrCreateGlobalVariable(global))
+variables.AddVariable(var);
+  break;
+}
+default:
+  break;
+}
+  }
+  return variables.GetSize();
 }
 
 VariableSP SymbolFileNativePDB::CreateLocalVariable(PdbCompilandSymId scope_id,
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
index 669c44aa131edc..6e384b2b17873f 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
@@ -265,6 +265,7 @@ class SymbolFileNativePDB : public SymbolFileCommon {
   // UID for anonymous union and anonymous struct as they don't have entities 
in
   // pdb debug info.
   lldb::user_id_t anonymous_id = LLDB_INVALID_UID - 1;
+  std::optional m_cu_count = 0;
 
   std::unique_ptr m_file_up;
   std::unique_ptr m_index;
diff --git a/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp 
b/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
index f2be33aae8163b..ff6e0ddb20f9eb 100644
--- a/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
+++ b/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
@@ -44,8 +44,7 @@ int main(int argc, char **argv) {
 // AST: |   |-ParmVarDecl {{.*}} 'char'
 // AST: |   `-ParmVarDecl {{.*}} 'int'
 
-// SYMBOL:  int main(int argc, char **argv);
-// SYMBOL-NEXT: struct Struct {
+// SYMBOL:  struct Struct {
 // SYMBOL-NEXT: void simple_method();
 // SYMBOL-NEXT: static void s

[Lldb-commits] [lldb] [lldb][NativePDB] Parse global variables. (PR #114303)

2024-10-30 Thread Zequan Wu via lldb-commits

https://github.com/ZequanWu created 
https://github.com/llvm/llvm-project/pull/114303

This doesn't parse S_CONSTANT case yet, because I found that 
`std::strong_ordering::equal` being a S_CONSTANT and has type of LF_STRUCTURE 
which is not currently handled when creating dwarf expression for the variable. 
Left a TODO for it to be finish later.

This makes `lldb/test/Shell/SymbolFile/PDB/ast-restore.test` passes on windows 
with native pdb plugin.


>From 215c36a380946a0c8cab63605bd0a9da13e642cd Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Tue, 29 Oct 2024 13:19:50 -0700
Subject: [PATCH] [lldb][NativePDB] Parse global variables.

---
 .../NativePDB/SymbolFileNativePDB.cpp | 39 +++
 .../NativePDB/SymbolFileNativePDB.h   |  1 +
 .../SymbolFile/NativePDB/ast-methods.cpp  |  5 ++-
 .../SymbolFile/NativePDB/global-ctor-dtor.cpp | 11 +++---
 .../Shell/SymbolFile/PDB/ast-restore.test |  9 +
 5 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 7fded6a31a3af5..3536599693cb46 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -365,18 +365,20 @@ void SymbolFileNativePDB::InitializeObject() {
 }
 
 uint32_t SymbolFileNativePDB::CalculateNumCompileUnits() {
+  if (m_cu_count)
+return *m_cu_count;
   const DbiModuleList &modules = m_index->dbi().modules();
-  uint32_t count = modules.getModuleCount();
-  if (count == 0)
-return count;
+  m_cu_count = modules.getModuleCount();
+  if (*m_cu_count == 0)
+return 0;
 
   // The linker can inject an additional "dummy" compilation unit into the
   // PDB. Ignore this special compile unit for our purposes, if it is there.
   // It is always the last one.
-  DbiModuleDescriptor last = modules.getModuleDescriptor(count - 1);
+  DbiModuleDescriptor last = modules.getModuleDescriptor(*m_cu_count - 1);
   if (last.getModuleName() == "* Linker *")
---count;
-  return count;
+--*m_cu_count;
+  return *m_cu_count;
 }
 
 Block &SymbolFileNativePDB::CreateBlock(PdbCompilandSymId block_id) {
@@ -888,7 +890,8 @@ VariableSP 
SymbolFileNativePDB::CreateGlobalVariable(PdbGlobalSymId var_id) {
 
   CompUnitSP comp_unit;
   std::optional modi = m_index->GetModuleIndexForVa(addr);
-  if (!modi) {
+  // Some globals has modi points to the linker module, ignore them.
+  if (!modi || modi >= CalculateNumCompileUnits()) {
 return nullptr;
   }
 
@@ -1810,7 +1813,27 @@ 
SymbolFileNativePDB::ParseVariablesForCompileUnit(CompileUnit &comp_unit,
   VariableList &variables) {
   PdbSymUid sym_uid(comp_unit.GetID());
   lldbassert(sym_uid.kind() == PdbSymUidKind::Compiland);
-  return 0;
+  for (const uint32_t gid : m_index->globals().getGlobalsTable()) {
+PdbGlobalSymId global{gid, false};
+CVSymbol sym = m_index->ReadSymbolRecord(global);
+// TODO: Handle S_CONSTANT which might be a record type (e.g.
+// std::strong_ordering::equal). Currently
+// lldb_private::npdb::MakeConstantLocationExpression doesn't handle this
+// case and will crash if we do create global variables from it.
+switch (sym.kind()) {
+case SymbolKind::S_GDATA32:
+case SymbolKind::S_LDATA32:
+case SymbolKind::S_GTHREAD32:
+case SymbolKind::S_LTHREAD32: {
+  if (VariableSP var = GetOrCreateGlobalVariable(global))
+variables.AddVariable(var);
+  break;
+}
+default:
+  break;
+}
+  }
+  return variables.GetSize();
 }
 
 VariableSP SymbolFileNativePDB::CreateLocalVariable(PdbCompilandSymId scope_id,
diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
index 669c44aa131edc..6e384b2b17873f 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
@@ -265,6 +265,7 @@ class SymbolFileNativePDB : public SymbolFileCommon {
   // UID for anonymous union and anonymous struct as they don't have entities 
in
   // pdb debug info.
   lldb::user_id_t anonymous_id = LLDB_INVALID_UID - 1;
+  std::optional m_cu_count = 0;
 
   std::unique_ptr m_file_up;
   std::unique_ptr m_index;
diff --git a/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp 
b/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
index f2be33aae8163b..ff6e0ddb20f9eb 100644
--- a/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
+++ b/lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
@@ -44,8 +44,7 @@ int main(int argc, char **argv) {
 // AST: |   |-ParmVarDecl {{.*}} 'char'
 // AST: |   `-ParmVarDecl {{.*}} 'int'
 
-// SYMBOL:  int main(int argc, char **argv);
-// SYMBOL-NEXT: struct Struct {
+// SYMBOL:  struct Struct {
 // SYMBOL-NEXT: void simple_

[Lldb-commits] [lldb] Fix stepping away from the bottom most level of the inline call stack (PR #114335)

2024-10-30 Thread via lldb-commits

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


[Lldb-commits] [lldb] Fix stepping away from the bottom most level of the inline call stack (PR #114335)

2024-10-30 Thread via lldb-commits

jimingham wrote:

I have to redo this, the repo I started from had an older change as well.

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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/114337

The computation of 'Thread::IsVirtualStep" was wrong - it called being at the 
bottom of a virtual call stack a "virtual step" but that is actually when 
you've gotten to concrete code and need to step for real.

I also added a test for this.

>From 48c51370545165095867c480ddf8b7fdbb312630 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 30 Oct 2024 17:18:39 -0700
Subject: [PATCH] Fix stepping away from the bottom-most frame of a virtual
 inlined call stack.

---
 lldb/source/Target/ThreadPlanStepInRange.cpp  |  3 ++-
 .../inline-stepping/TestInlineStepping.py | 11 ++-
 .../API/functionalities/inline-stepping/calling.cpp   |  2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lldb/source/Target/ThreadPlanStepInRange.cpp 
b/lldb/source/Target/ThreadPlanStepInRange.cpp
index 325a70619908b6..224a17d896ccf0 100644
--- a/lldb/source/Target/ThreadPlanStepInRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepInRange.cpp
@@ -489,7 +489,8 @@ bool ThreadPlanStepInRange::DoWillResume(lldb::StateType 
resume_state,
 bool ThreadPlanStepInRange::IsVirtualStep() {
   if (m_virtual_step == eLazyBoolCalculate) {
 Thread &thread = GetThread();
-if (thread.GetCurrentInlinedDepth() == UINT32_MAX)
+uint32_t cur_inline_depth = thread.GetCurrentInlinedDepth();
+if (cur_inline_depth == UINT32_MAX || cur_inline_depth == 0)
   m_virtual_step = eLazyBoolNo;
 else
   m_virtual_step = eLazyBoolYes;
diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..fe61b8e48f6d6d 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,7 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos):
+def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -408,6 +408,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos):
 # stepping for this function...
 break
 
+if one_more_step_loc:
+thread.StepInto()
+frame_0 = thread.frame[0]
+self.assertEqual(frame_0.line_entry.line, 
line_number(self.main_source, one_more_step_loc),
+  "Was able to 
step one more time")
 process.Kill()
 target.Clear()
 
@@ -420,3 +425,7 @@ def virtual_inline_stepping(self):
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
+self.run_to_call_site_and_step(
+"In caller_trivial_inline_3", "caller_trivial_inline_3", 4, "After 
caller_trivial_inline_3"
+)
+
diff --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index d7ee56b3c07909..7ed88a872c4eba 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1;
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {

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


[Lldb-commits] [lldb] Fix stepping away from the bottom-most frame of a virtual inlined call stack. (PR #114337)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

The computation of 'Thread::IsVirtualStep" was wrong - it called being at the 
bottom of a virtual call stack a "virtual step" but that is actually when 
you've gotten to concrete code and need to step for real.

I also added a test for this.

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


3 Files Affected:

- (modified) lldb/source/Target/ThreadPlanStepInRange.cpp (+2-1) 
- (modified) 
lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py (+10-1) 
- (modified) lldb/test/API/functionalities/inline-stepping/calling.cpp (+1-1) 


``diff
diff --git a/lldb/source/Target/ThreadPlanStepInRange.cpp 
b/lldb/source/Target/ThreadPlanStepInRange.cpp
index 325a70619908b6..224a17d896ccf0 100644
--- a/lldb/source/Target/ThreadPlanStepInRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepInRange.cpp
@@ -489,7 +489,8 @@ bool ThreadPlanStepInRange::DoWillResume(lldb::StateType 
resume_state,
 bool ThreadPlanStepInRange::IsVirtualStep() {
   if (m_virtual_step == eLazyBoolCalculate) {
 Thread &thread = GetThread();
-if (thread.GetCurrentInlinedDepth() == UINT32_MAX)
+uint32_t cur_inline_depth = thread.GetCurrentInlinedDepth();
+if (cur_inline_depth == UINT32_MAX || cur_inline_depth == 0)
   m_virtual_step = eLazyBoolNo;
 else
   m_virtual_step = eLazyBoolYes;
diff --git 
a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py 
b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
index f52e0f0fd5bcfe..fe61b8e48f6d6d 100644
--- a/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
+++ b/lldb/test/API/functionalities/inline-stepping/TestInlineStepping.py
@@ -364,7 +364,7 @@ def step_in_template(self):
 step_sequence = [["// In max_value specialized", "into"]]
 self.run_step_sequence(step_sequence)
 
-def run_to_call_site_and_step(self, source_regex, func_name, start_pos):
+def run_to_call_site_and_step(self, source_regex, func_name, start_pos, 
one_more_step_loc = None):
 main_spec = lldb.SBFileSpec("calling.cpp")
 # Set the breakpoint by file and line, not sourced regex because
 # we want to make sure we can set breakpoints on call sites:
@@ -408,6 +408,11 @@ def run_to_call_site_and_step(self, source_regex, 
func_name, start_pos):
 # stepping for this function...
 break
 
+if one_more_step_loc:
+thread.StepInto()
+frame_0 = thread.frame[0]
+self.assertEqual(frame_0.line_entry.line, 
line_number(self.main_source, one_more_step_loc),
+  "Was able to 
step one more time")
 process.Kill()
 target.Clear()
 
@@ -420,3 +425,7 @@ def virtual_inline_stepping(self):
 self.run_to_call_site_and_step(
 "In caller_trivial_inline_2", "caller_trivial_inline_2", 3
 )
+self.run_to_call_site_and_step(
+"In caller_trivial_inline_3", "caller_trivial_inline_3", 4, "After 
caller_trivial_inline_3"
+)
+
diff --git a/lldb/test/API/functionalities/inline-stepping/calling.cpp 
b/lldb/test/API/functionalities/inline-stepping/calling.cpp
index d7ee56b3c07909..7ed88a872c4eba 100644
--- a/lldb/test/API/functionalities/inline-stepping/calling.cpp
+++ b/lldb/test/API/functionalities/inline-stepping/calling.cpp
@@ -95,7 +95,7 @@ void caller_trivial_inline_1() {
 
 void caller_trivial_inline_2() {
   caller_trivial_inline_3(); // In caller_trivial_inline_2.
-  inline_value += 1;
+  inline_value += 1; // After caller_trivial_inline_3
 }
 
 void caller_trivial_inline_3() {

``




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


[Lldb-commits] [lldb] [lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (PR #114346)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

Use PY_VERSION_HEX to simplify conditional compilation depending on the Python 
version.

This also adds a static_assert to lldb-python to error out with a meaningful 
diagnostic when you try building LLDB with an older Python version in 
preparation for [1].

[1] 
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15

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


4 Files Affected:

- (modified) lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
(+6-6) 
- (modified) 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp (+8-9) 
- (modified) lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h (+4) 
- (modified) lldb/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp 
(+1-1) 


``diff
diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
index 90ccd1055199a0..a0f8cf954f8040 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -71,12 +71,12 @@ Expected 
python::As(Expected &&obj) {
 }
 
 static bool python_is_finalizing() {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 13) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x030d
   return Py_IsFinalizing();
-#elif PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION < 7
-  return _Py_Finalizing != nullptr;
-#else
+#elif PY_VERSION_HEX >= 0x0307
   return _Py_IsFinalizing();
+#else
+  return _Py_Finalizing != nullptr;
 #endif
 }
 
@@ -810,7 +810,7 @@ bool PythonCallable::Check(PyObject *py_obj) {
   return PyCallable_Check(py_obj);
 }
 
-#if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 3
+#if PY_VERSION_HEX >= 0x0303
 static const char get_arg_info_script[] = R"(
 from inspect import signature, Parameter, ismethod
 from collections import namedtuple
@@ -839,7 +839,7 @@ Expected 
PythonCallable::GetArgInfo() const {
   if (!IsValid())
 return nullDeref();
 
-#if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 3
+#if PY_VERSION_HEX >= 0x0303
 
   // no need to synchronize access to this global, we already have the GIL
   static PythonScript get_arg_info(get_arg_info_script);
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7c2b6517468ff4..ef3c53ca5698db 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -71,8 +71,7 @@ extern "C" PyObject *PyInit__lldb(void);
 #define LLDB_USE_PYTHON_SET_INTERRUPT 0
 #else
 // PyErr_SetInterrupt was introduced in 3.2.
-#define LLDB_USE_PYTHON_SET_INTERRUPT  
\
-  (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#define LLDB_USE_PYTHON_SET_INTERRUPT PY_VERSION_HEX >= 0x0302
 #endif
 
 static ScriptInterpreterPythonImpl *GetPythonInterpreter(Debugger &debugger) {
@@ -92,7 +91,7 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
 PyConfig config;
 PyConfig_InitPythonConfig(&config);
 #endif
@@ -109,7 +108,7 @@ struct InitializePythonRAII {
   return spec.GetPath();
 }();
 if (!g_python_home.empty()) {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
   PyConfig_SetBytesString(&config, &config.home, g_python_home.c_str());
 #else
   size_t size = 0;
@@ -143,7 +142,7 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
 config.install_signal_handlers = 0;
 Py_InitializeFromConfig(&config);
 PyConfig_Clear(&config);
@@ -152,7 +151,7 @@ struct InitializePythonRAII {
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
+#if PY_VERSION_HEX >= 0x0302
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
@@ -182,7 +181,7 @@ struct InitializePythonRAII {
 // would always return `true` and `PyGILState_Ensure/Release` flow would be
 // executed instead of unlocking GIL with `PyEval_SaveThread`. When
 // an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 7) || (PY_MAJOR_VERSION > 3)
+#if

[Lldb-commits] [lldb] 75aaa31 - [lldb] Fix formatting and whitespace in ScriptInterpreterPython (NFC)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2024-10-30T20:33:28-07:00
New Revision: 75aaa312ffa9aa044b84bd1b32491937795c110a

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

LOG: [lldb] Fix formatting and whitespace in ScriptInterpreterPython (NFC)

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 44fd05150ebc0f..7c2b6517468ff4 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -453,8 +453,9 @@ 
ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(Debugger &debugger)
   // Reloading modules requires a 
diff erent syntax in Python 2 and Python 3.
   // This provides a consistent syntax no matter what version of Python.
   run_string.Clear();
-  run_string.Printf("run_one_line (%s, 'from importlib import reload as 
reload_module')",
-m_dictionary_name.c_str());
+  run_string.Printf(
+  "run_one_line (%s, 'from importlib import reload as reload_module')",
+  m_dictionary_name.c_str());
   PyRun_SimpleString(run_string.GetData());
 
   // WARNING: temporary code that loads Cocoa formatters - this should be done
@@ -770,21 +771,19 @@ llvm::Expected
 ScriptInterpreterPythonImpl::GetMaxPositionalArgumentsForCallable(
 const llvm::StringRef &callable_name) {
   if (callable_name.empty()) {
-return llvm::createStringError(
-llvm::inconvertibleErrorCode(),
-"called with empty callable name.");
-  }
-  Locker py_lock(this, Locker::AcquireLock |
- Locker::InitSession |
- Locker::NoSTDIN);
-  auto dict = PythonModule::MainModule()
-  .ResolveName(m_dictionary_name);
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "called with empty callable name.");
+  }
+  Locker py_lock(this,
+ Locker::AcquireLock | Locker::InitSession | Locker::NoSTDIN);
+  auto dict = PythonModule::MainModule().ResolveName(
+  m_dictionary_name);
   auto pfunc = PythonObject::ResolveNameWithDictionary(
   callable_name, dict);
   if (!pfunc.IsAllocated()) {
-return llvm::createStringError(
-llvm::inconvertibleErrorCode(),
-"can't find callable: %s", callable_name.str().c_str());
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "can't find callable: %s",
+   callable_name.str().c_str());
   }
   llvm::Expected arg_info = pfunc.GetArgInfo();
   if (!arg_info)
@@ -1266,8 +1265,7 @@ Status 
ScriptInterpreterPythonImpl::SetBreakpointCommandCallback(
 
 // Set a Python one-liner as the callback for the watchpoint.
 void ScriptInterpreterPythonImpl::SetWatchpointCommandCallback(
-WatchpointOptions *wp_options, const char *user_input,
-bool is_callback) {
+WatchpointOptions *wp_options, const char *user_input, bool is_callback) {
   auto data_up = std::make_unique();
 
   // It's necessary to set both user_source and script_source to the oneliner.
@@ -1293,8 +1291,7 @@ Status 
ScriptInterpreterPythonImpl::ExportFunctionDefinitionToInterpreter(
   std::string function_def_string(function_def.CopyList());
 
   Status error = ExecuteMultipleLines(
-  function_def_string.c_str(),
-  ExecuteScriptOptions().SetEnableIO(false));
+  function_def_string.c_str(), ExecuteScriptOptions().SetEnableIO(false));
   return error;
 }
 
@@ -2075,7 +2072,8 @@ int ScriptInterpreterPythonImpl::GetIndexOfChildWithName(
   {
 Locker py_lock(this,
Locker::AcquireLock | Locker::InitSession | 
Locker::NoSTDIN);
-ret_val = SWIGBridge::LLDBSwigPython_GetIndexOfChildWithName(implementor, 
child_name);
+ret_val = SWIGBridge::LLDBSwigPython_GetIndexOfChildWithName(implementor,
+ child_name);
   }
 
   return ret_val;
@@ -2467,7 +2465,8 @@ bool ScriptInterpreterPythonImpl::LoadScriptingModule(
   // the lifetime of the process in which this LLDB framework is living.
   const bool does_contain_executed = ExecuteOneLineWithReturn(
   command_stream.GetData(),
-  ScriptInterpreterPythonImpl::eScriptReturnTypeBool, &does_contain, 
exc_options);
+  ScriptInterpreterPythonImpl::eScriptReturnTypeBool, &does_contain,
+  exc_options);
 
   const bool was_imported_globally = does_contain_executed && does_contain;
   const bool was_imported_locally =
@@ -2684,7 +2683,7 @@ bool 
ScriptInterpreterPythonImpl::RunScriptBasedParsedCommand(

[Lldb-commits] [lldb] [lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (PR #114346)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/114346

Use PY_VERSION_HEX to simplify conditional compilation depending on the Python 
version.

This also adds a static_assert to lldb-python to error out with a meaningful 
diagnostic when you try building LLDB with an older Python version in 
preparation for [1].

[1] 
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15

>From 2d4b486202194166471ccafd97ff63c399b2e822 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Wed, 30 Oct 2024 20:34:04 -0700
Subject: [PATCH] [lldb] Use PY_VERSION_HEX to simplify conditional compilation
 (NFC)

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_assert to lldb-python to error out with a
meaningful diagnostic when you try building LLDB with an older Python
version in preparation for [1].

[1] 
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15
---
 .../Python/PythonDataObjects.cpp| 12 ++--
 .../Python/ScriptInterpreterPython.cpp  | 17 -
 .../ScriptInterpreter/Python/lldb-python.h  |  4 
 .../Python/PythonDataObjectsTests.cpp   |  2 +-
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
index 90ccd1055199a0..a0f8cf954f8040 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
@@ -71,12 +71,12 @@ Expected 
python::As(Expected &&obj) {
 }
 
 static bool python_is_finalizing() {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 13) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x030d
   return Py_IsFinalizing();
-#elif PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION < 7
-  return _Py_Finalizing != nullptr;
-#else
+#elif PY_VERSION_HEX >= 0x0307
   return _Py_IsFinalizing();
+#else
+  return _Py_Finalizing != nullptr;
 #endif
 }
 
@@ -810,7 +810,7 @@ bool PythonCallable::Check(PyObject *py_obj) {
   return PyCallable_Check(py_obj);
 }
 
-#if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 3
+#if PY_VERSION_HEX >= 0x0303
 static const char get_arg_info_script[] = R"(
 from inspect import signature, Parameter, ismethod
 from collections import namedtuple
@@ -839,7 +839,7 @@ Expected 
PythonCallable::GetArgInfo() const {
   if (!IsValid())
 return nullDeref();
 
-#if PY_MAJOR_VERSION >= 3 && PY_MINOR_VERSION >= 3
+#if PY_VERSION_HEX >= 0x0303
 
   // no need to synchronize access to this global, we already have the GIL
   static PythonScript get_arg_info(get_arg_info_script);
diff --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7c2b6517468ff4..ef3c53ca5698db 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -71,8 +71,7 @@ extern "C" PyObject *PyInit__lldb(void);
 #define LLDB_USE_PYTHON_SET_INTERRUPT 0
 #else
 // PyErr_SetInterrupt was introduced in 3.2.
-#define LLDB_USE_PYTHON_SET_INTERRUPT  
\
-  (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#define LLDB_USE_PYTHON_SET_INTERRUPT PY_VERSION_HEX >= 0x0302
 #endif
 
 static ScriptInterpreterPythonImpl *GetPythonInterpreter(Debugger &debugger) {
@@ -92,7 +91,7 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
 PyConfig config;
 PyConfig_InitPythonConfig(&config);
 #endif
@@ -109,7 +108,7 @@ struct InitializePythonRAII {
   return spec.GetPath();
 }();
 if (!g_python_home.empty()) {
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
   PyConfig_SetBytesString(&config, &config.home, g_python_home.c_str());
 #else
   size_t size = 0;
@@ -143,7 +142,7 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+#if PY_VERSION_HEX >= 0x0308
 config.install_signal_handlers = 0;
 Py_InitializeFromConfig(&config);
 PyConfig_Clear(&config);
@@ -152,7 +151,7 @@ struct InitializePythonRAII {
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
+#if PY_VERSION_HEX >= 0x

[Lldb-commits] [lldb] [llvm] [lldb] Change lldb's breakpoint detection behavior [WIP] (PR #105594)

2024-10-30 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

Looking at this again.  The last issue that I needed to investigate was 
Martin's mingw testsuite that had a regression when I landed it.  The test 
program was 
https://github.com/mstorsjo/llvm-mingw/blob/master/test/hello-exception.cpp and 
when run
```
bin/lldb -x -b -o 'b done' -o r -o fin /tmp/a.out -- -noop
```

put a breakpoint on `done()`, run to it, `finish`.  On arm64 darwin, where 
`done()` is a single `ret` instruction, I can reproduce this failure with my 
stepping PR.  The thread plan stack when I do `finish` has a "step over 
breakpoint" thread plan, and a "step out" thread plan.  We do the step over 
breakpoint thread plan, correctly pop both thread plans from the stack, but 
with my patch we're asking if either thread plan says we should resume 
execution, and one of them voted yes and won.  (or possibly returned should 
stop == 0)  It's been a while since i looked into that logic, need to dig back 
in.

Important thing is that the failure is not mingw specific, I'll probably add 
this as an API test in lldb, maybe updated to not require a flag to run `done`.

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


[Lldb-commits] [lldb] 3a782ef - [lldb] Add a link to LLDB's Discord channel on the website (#114289)

2024-10-30 Thread via lldb-commits

Author: Jonas Devlieghere
Date: 2024-10-30T15:47:48-07:00
New Revision: 3a782ef97de771af9fd565e0043d49bdd0f2c850

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

LOG: [lldb] Add a link to LLDB's Discord channel on the website (#114289)

Looking at #114276, I realized we have a link to Discourse on the
website, but not Discord. I think it would be helpful to have that link
there for real-time community discussion.

Added: 


Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index e2c15d872b4be2..fb22bdecad37e7 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -181,6 +181,7 @@ interesting areas to contribute to lldb.
 
Source Code 
Releases 
+   Discord 
Discussion Forums 
Developer Policy 
Bug Reports 




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


[Lldb-commits] [lldb] Fix call site breakpoint patch (PR #114158)

2024-10-30 Thread via lldb-commits

dyung wrote:

@jimingham your change is causing two cross-project-test failures, can you take 
a look or revert if you need time to investigate?

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


[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)

2024-10-30 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl created 
https://github.com/llvm/llvm-project/pull/114333

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.

See https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 for 
more context!

This is currently a draft, I still want to add more tests and also extend the 
metadata with (show children) flag and potentially others.

>From c9a4d24f222a70c7c108deebb6c25222893d7159 Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Wed, 24 Jan 2024 12:42:45 -0800
Subject: [PATCH 1/2] [lldb] Load embedded type summary section (#7859) (#8040)

Add support for type summaries embedded into the binary.

These embedded summaries will typically be generated by Swift macros,
but can also be generated by any other means.

rdar://115184658
---
 lldb/include/lldb/lldb-enumerations.h |  1 +
 lldb/source/Core/Section.cpp  |  3 +
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  |  1 +
 .../ObjectFile/Mach-O/ObjectFileMachO.cpp |  4 ++
 .../ObjectFile/PECOFF/ObjectFilePECOFF.cpp|  1 +
 lldb/source/Symbol/ObjectFile.cpp |  1 +
 lldb/source/Target/Target.cpp | 72 +++
 .../data-formatter/embedded-summary/Makefile  |  2 +
 .../TestEmbeddedTypeSummary.py| 12 
 .../data-formatter/embedded-summary/main.c| 22 ++
 10 files changed, 119 insertions(+)
 create mode 100644 
lldb/test/API/functionalities/data-formatter/embedded-summary/Makefile
 create mode 100644 
lldb/test/API/functionalities/data-formatter/embedded-summary/TestEmbeddedTypeSummary.py
 create mode 100644 
lldb/test/API/functionalities/data-formatter/embedded-summary/main.c

diff --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index 938f6e3abe8f2a..1ca4aa62218c09 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -761,6 +761,7 @@ enum SectionType {
   eSectionTypeDWARFDebugLocListsDwo,
   eSectionTypeDWARFDebugTuIndex,
   eSectionTypeCTF,
+  eSectionTypeLLDBTypeSummaries,
   eSectionTypeSwiftModules,
 };
 
diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f4..ee01b4ce06ca1e 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -147,6 +147,8 @@ const char *Section::GetTypeAsCString() const {
 return "dwarf-gnu-debugaltlink";
   case eSectionTypeCTF:
 return "ctf";
+  case eSectionTypeLLDBTypeSummaries:
+return "lldb-type-summaries";
   case eSectionTypeOther:
 return "regular";
   case eSectionTypeSwiftModules:
@@ -457,6 +459,7 @@ bool Section::ContainsOnlyDebugInfo() const {
   case eSectionTypeDWARFAppleObjC:
   case eSectionTypeDWARFGNUDebugAltLink:
   case eSectionTypeCTF:
+  case eSectionTypeLLDBTypeSummaries:
   case eSectionTypeSwiftModules:
 return true;
   }
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 10d09662c0a47a..ad4a84ef02bf72 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1678,6 +1678,7 @@ static SectionType GetSectionTypeFromName(llvm::StringRef 
Name) {
   .Case(".gnu_debugaltlink", eSectionTypeDWARFGNUDebugAltLink)
   .Case(".gosymtab", eSectionTypeGoSymtab)
   .Case(".text", eSectionTypeCode)
+  .Case(".lldbsummaries", lldb::eSectionTypeLLDBTypeSummaries)
   .Case(".swift_ast", eSectionTypeSwiftModules)
   .Default(eSectionTypeOther);
 }
diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index b542e237f023d4..d6bec5d84aea19 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1209,6 +1209,7 @@ AddressClass 
ObjectFileMachO::GetAddressClass(lldb::addr_t file_addr) {
 case eSectionTypeDWARFAppleObjC:
 case eSectionTypeDWARFGNUDebugAltLink:
 case eSectionTypeCTF:
+case eSectionTypeLLDBTypeSummaries:
 case eSectionTypeSwiftModules:
   return AddressClass::eDebug;
 
@@ -1484,6 +1485,7 @@ static lldb::SectionType GetSectionType(uint32_t flags,
   static ConstString g_sect_name_data("__data");
   static ConstString g_sect_name_go_symtab("__gosymtab");
   static ConstString g_sect_name_ctf("__ctf");
+  static ConstString g_sect_name_lldb_summaries("__lldbsummaries");
   static ConstString g_sect_name_swift_ast("__swift_ast");
 
   if (section_name == g_sect_name_dwarf_debug_abbrev)
@@ -1564,6 +1566,8 @@ static lldb::SectionType GetSectionType(uint32_t flags,
 return eSectionTypeGoSymtab;
   if (section_name == g_sect_name_ctf)
 return eSectionTypeCTF;
+  if (section_name == g_sect_name_lldb_summaries)
+return lldb::eSectionTypeLLDBTypeSummar

[Lldb-commits] [lldb] [lldb] Implement a formatter bytecode interpreter in C++ (PR #114333)

2024-10-30 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Prantl (adrian-prantl)


Changes

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.

See https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696 for 
more context!

This is currently a draft, I still want to add more tests and also extend the 
metadata with (show children) flag and potentially others.

---

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


19 Files Affected:

- (modified) lldb/include/lldb/DataFormatters/TypeSummary.h (+21-1) 
- (modified) lldb/include/lldb/lldb-enumerations.h (+2) 
- (modified) lldb/source/Core/Section.cpp (+4) 
- (modified) lldb/source/DataFormatters/CMakeLists.txt (+1) 
- (added) lldb/source/DataFormatters/FormatterBytecode.cpp (+576) 
- (added) lldb/source/DataFormatters/FormatterBytecode.def (+101) 
- (added) lldb/source/DataFormatters/FormatterBytecode.h (+63) 
- (modified) lldb/source/DataFormatters/TypeSummary.cpp (+71-3) 
- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (+2) 
- (modified) lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (+8) 
- (modified) lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp (+2) 
- (modified) lldb/source/Symbol/ObjectFile.cpp (+1) 
- (modified) lldb/source/Target/Target.cpp (+151) 
- (added) 
lldb/test/API/functionalities/data-formatter/bytecode-summary/Makefile (+2) 
- (added) 
lldb/test/API/functionalities/data-formatter/bytecode-summary/TestBytecodeSummary.py
 (+14) 
- (added) 
lldb/test/API/functionalities/data-formatter/bytecode-summary/main.cpp (+36) 
- (added) 
lldb/test/API/functionalities/data-formatter/embedded-summary/Makefile (+2) 
- (added) 
lldb/test/API/functionalities/data-formatter/embedded-summary/TestEmbeddedTypeSummary.py
 (+12) 
- (added) lldb/test/API/functionalities/data-formatter/embedded-summary/main.c 
(+22) 


``diff
diff --git a/lldb/include/lldb/DataFormatters/TypeSummary.h 
b/lldb/include/lldb/DataFormatters/TypeSummary.h
index 382824aa2813da..0d8e46fa0b1598 100644
--- a/lldb/include/lldb/DataFormatters/TypeSummary.h
+++ b/lldb/include/lldb/DataFormatters/TypeSummary.h
@@ -22,6 +22,10 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StructuredData.h"
 
+namespace llvm {
+class MemoryBuffer;
+}
+
 namespace lldb_private {
 class TypeSummaryOptions {
 public:
@@ -44,7 +48,7 @@ class TypeSummaryOptions {
 
 class TypeSummaryImpl {
 public:
-  enum class Kind { eSummaryString, eScript, eCallback, eInternal };
+  enum class Kind { eSummaryString, eScript, eBytecode, eCallback, eInternal };
 
   virtual ~TypeSummaryImpl() = default;
 
@@ -409,6 +413,22 @@ struct ScriptSummaryFormat : public TypeSummaryImpl {
   ScriptSummaryFormat(const ScriptSummaryFormat &) = delete;
   const ScriptSummaryFormat &operator=(const ScriptSummaryFormat &) = delete;
 };
+
+/// A summary formatter that is defined in LLDB formmater bytecode.
+class BytecodeSummaryFormat : public TypeSummaryImpl {
+  std::unique_ptr m_bytecode;
+public:
+  BytecodeSummaryFormat(const TypeSummaryImpl::Flags &flags,
+std::unique_ptr bytecode);
+  bool FormatObject(ValueObject *valobj, std::string &dest,
+const TypeSummaryOptions &options) override;
+  std::string GetDescription() override;
+  std::string GetName() override;
+  static bool classof(const TypeSummaryImpl *S) {
+return S->GetKind() == Kind::eBytecode;
+  }
+};
+
 } // namespace lldb_private
 
 #endif // LLDB_DATAFORMATTERS_TYPESUMMARY_H
diff --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index 938f6e3abe8f2a..b2f0943d5a9260 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -761,6 +761,8 @@ enum SectionType {
   eSectionTypeDWARFDebugLocListsDwo,
   eSectionTypeDWARFDebugTuIndex,
   eSectionTypeCTF,
+  eSectionTypeLLDBTypeSummaries,
+  eSectionTypeLLDBFormatters,
   eSectionTypeSwiftModules,
 };
 
diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f4..3b5ca2c6785ef0 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -147,6 +147,8 @@ const char *Section::GetTypeAsCString() const {
 return "dwarf-gnu-debugaltlink";
   case eSectionTypeCTF:
 return "ctf";
+  case eSectionTypeLLDBTypeSummaries:
+return "lldb-type-summaries";
   case eSectionTypeOther:
 return "regular";
   case eSectionTypeSwiftModules:
@@ -457,6 +459,8 @@ bool Section::ContainsOnlyDebugInfo() const {
   case eSectionTypeDWARFAppleObjC:
   case eSectionTypeDWARFGNUDebugAltLink:
   case eSectionTypeCTF:
+  case eSectionTypeLLDBTypeSummaries:
+  case eSectionTypeLLDBFormatters:
   case eSectionTypeSwiftModules:
 return true;
   }
diff --git a/lldb/source/DataFormatters/CMakeLists.txt 
b/lldb/source/DataFor

[Lldb-commits] [lldb] de7ad6b - [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2024-10-30T18:48:43-07:00
New Revision: de7ad6b6820a265160507f8c6cf8ce5e07c4d5d8

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

LOG: [lldb] Use Py_InitializeFromConfig with Python >= 3.8 (NFC) (#114112)

This fixes the deprecation warning for Py_SetPythonHome, which was
deprecated in Python 3.11. With this patch, when building against Python
3.8 or later, we now use Py_InitializeFromConfig instead.

Fixes #113475

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 7cc38da6a6a94b..44fd05150ebc0f 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -92,7 +92,33 @@ namespace {
 struct InitializePythonRAII {
 public:
   InitializePythonRAII() {
-InitializePythonHome();
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+PyConfig config;
+PyConfig_InitPythonConfig(&config);
+#endif
+
+#if LLDB_EMBED_PYTHON_HOME
+static std::string g_python_home = []() -> std::string {
+  if (llvm::sys::path::is_absolute(LLDB_PYTHON_HOME))
+return LLDB_PYTHON_HOME;
+
+  FileSpec spec = HostInfo::GetShlibDir();
+  if (!spec)
+return {};
+  spec.AppendPathComponent(LLDB_PYTHON_HOME);
+  return spec.GetPath();
+}();
+if (!g_python_home.empty()) {
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+  PyConfig_SetBytesString(&config, &config.home, g_python_home.c_str());
+#else
+  size_t size = 0;
+  wchar_t *python_home_w = Py_DecodeLocale(g_python_home.c_str(), &size);
+  Py_SetPythonHome(python_home_w);
+  PyMem_RawFree(python_home_w);
+#endif
+}
+#endif
 
 // The table of built-in modules can only be extended before Python is
 // initialized.
@@ -117,15 +143,22 @@ struct InitializePythonRAII {
   PyImport_AppendInittab("_lldb", LLDBSwigPyInit);
 }
 
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 8) || (PY_MAJOR_VERSION > 3)
+config.install_signal_handlers = 0;
+Py_InitializeFromConfig(&config);
+PyConfig_Clear(&config);
+InitializeThreadsPrivate();
+#else
 // Python < 3.2 and Python >= 3.2 reversed the ordering requirements for
 // calling `Py_Initialize` and `PyEval_InitThreads`.  < 3.2 requires that you
 // call `PyEval_InitThreads` first, and >= 3.2 requires that you call it last.
-#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2) || (PY_MAJOR_VERSION > 3)
+#if (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 2)
 Py_InitializeEx(0);
 InitializeThreadsPrivate();
 #else
 InitializeThreadsPrivate();
 Py_InitializeEx(0);
+#endif
 #endif
   }
 
@@ -142,32 +175,6 @@ struct InitializePythonRAII {
   }
 
 private:
-  void InitializePythonHome() {
-#if LLDB_EMBED_PYTHON_HOME
-typedef wchar_t *str_type;
-static str_type g_python_home = []() -> str_type {
-  const char *lldb_python_home = LLDB_PYTHON_HOME;
-  const char *absolute_python_home = nullptr;
-  llvm::SmallString<64> path;
-  if (llvm::sys::path::is_absolute(lldb_python_home)) {
-absolute_python_home = lldb_python_home;
-  } else {
-FileSpec spec = HostInfo::GetShlibDir();
-if (!spec)
-  return nullptr;
-spec.GetPath(path);
-llvm::sys::path::append(path, lldb_python_home);
-absolute_python_home = path.c_str();
-  }
-  size_t size = 0;
-  return Py_DecodeLocale(absolute_python_home, &size);
-}();
-if (g_python_home != nullptr) {
-  Py_SetPythonHome(g_python_home);
-}
-#endif
-  }
-
   void InitializeThreadsPrivate() {
 // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
 // so there is no way to determine whether the embedded interpreter



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


[Lldb-commits] [lldb] [lldb] Add a fuzzer for the DWARF Expression Evaluator (PR #114286)

2024-10-30 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere updated 
https://github.com/llvm/llvm-project/pull/114286

>From cb898b4f2f0cedfa7674f5b5cdcf2963dce377e4 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Wed, 30 Oct 2024 11:22:20 -0700
Subject: [PATCH 1/2] [lldb] Add a fuzzer for the DWARF Expression Evaluator

This adds a fuzzer for the DWARF expression evaluator. It does pretty
much the same thing as what we do in the corresponding unit test but
with data generated by libfuzzer.
---
 lldb/tools/lldb-fuzzer/CMakeLists.txt |  1 +
 .../CMakeLists.txt| 34 
 .../lldb-dwarf-expression-fuzzer.cpp  | 83 +++
 3 files changed, 118 insertions(+)
 create mode 100644 
lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/CMakeLists.txt
 create mode 100644 
lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/lldb-dwarf-expression-fuzzer.cpp

diff --git a/lldb/tools/lldb-fuzzer/CMakeLists.txt 
b/lldb/tools/lldb-fuzzer/CMakeLists.txt
index 4c081a9de53e2d..e384ca18583981 100644
--- a/lldb/tools/lldb-fuzzer/CMakeLists.txt
+++ b/lldb/tools/lldb-fuzzer/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_subdirectory(lldb-commandinterpreter-fuzzer)
+add_subdirectory(lldb-dwarf-expression-fuzzer)
 add_subdirectory(lldb-expression-fuzzer)
 add_subdirectory(lldb-target-fuzzer)
 add_subdirectory(utils)
diff --git a/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/CMakeLists.txt 
b/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/CMakeLists.txt
new file mode 100644
index 00..374a80b7bb83af
--- /dev/null
+++ b/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/CMakeLists.txt
@@ -0,0 +1,34 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+add_llvm_fuzzer(lldb-dwarf-expression-fuzzer
+  EXCLUDE_FROM_ALL
+  lldb-dwarf-expression-fuzzer.cpp
+  )
+
+include_directories(${LLDB_SOURCE_ROOT})
+
+if(TARGET lldb-dwarf-expression-fuzzer)
+  target_include_directories(lldb-dwarf-expression-fuzzer PRIVATE ..)
+  target_link_libraries(lldb-dwarf-expression-fuzzer
+PRIVATE
+lldbCore
+lldbPluginExpressionParserClang
+lldbPluginPlatformLinux
+lldbPluginTypeSystemClang
+lldbFuzzerUtils
+)
+
+  add_custom_command(TARGET lldb-dwarf-expression-fuzzer PRE_BUILD
+COMMAND ${CMAKE_COMMAND} -E make_directory 
${CMAKE_BINARY_DIR}/fuzzer-artifacts/dwarf-expression-artifacts
+)
+
+  add_custom_target(fuzz-lldb-dwarf-expression
+COMMENT "Running the LLDB target fuzzer..."
+WORKING_DIRECTORY 
${CMAKE_BINARY_DIR}/fuzzer-artifacts/dwarf-expression-artifacts
+COMMAND $ 
-artifact_prefix=dwarf-expression-
+USES_TERMINAL
+)
+  set_target_properties(fuzz-lldb-dwarf-expression PROPERTIES FOLDER 
"LLDB/Fuzzer")
+endif()
diff --git 
a/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/lldb-dwarf-expression-fuzzer.cpp
 
b/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/lldb-dwarf-expression-fuzzer.cpp
new file mode 100644
index 00..65c160d7b731c1
--- /dev/null
+++ 
b/lldb/tools/lldb-fuzzer/lldb-dwarf-expression-fuzzer/lldb-dwarf-expression-fuzzer.cpp
@@ -0,0 +1,83 @@
+//===-- lldb-target-fuzzer.cpp - Fuzz target creation 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "utils/TempFile.h"
+
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Value.h"
+#include "lldb/Expression/DWARFExpression.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Target/Target.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::plugin::dwarf;
+using namespace lldb_fuzzer;
+
+extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) {
+  FileSystem::Initialize();
+  HostInfo::Initialize();
+  platform_linux::PlatformLinux::Initialize();
+  return 0;
+}
+
+static void Evaluate(llvm::ArrayRef expr,
+ lldb::ModuleSP module_sp = {}, DWARFUnit *unit = nullptr,
+ ExecutionContext *exe_ctx = nullptr) {
+  DataExtractor extractor(expr.data(), expr.size(), lldb::eByteOrderLittle,
+  /*addr_size*/ 4);
+
+  llvm::Expected result =
+  DWARFExpression::Evaluate(exe_ctx, /*reg_ctx*/ nullptr, module_sp,
+extractor, unit, lldb::eRegisterKindLLDB,
+/*initial_value_ptr*/ nullptr,
+/*object_address_ptr*/ nullptr);
+
+  if (!result)
+llvm::consumeError(result.takeError());
+}
+
+class MockTarget : public Target {
+public:
+  MockTarget(Debugger &debugger, const ArchSpec &target_arch,
+ const lldb::PlatformSP &platform_sp, llvm::ArrayRef data)
+  : Target(debugger, target_arch, platform_sp, true),