[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

[Fangrui Song via lldb-commits]

MaskRay wrote:

I'm not familiar with lldb, but I can make some comments as @tschuett invited 
me:)

Parsing PT_NOTE is a great step, as program headers are sufficient for 
executables, shared objects, and core dumps.
The section header table isn't needed and the relevant code could be dropped 
(unless relocatable file debugging is required).

Has the code been updated to handle p_align=8 PT_LOAD correctly? 
https://reviews.llvm.org/D150022 might be a related change from LLVMObject.


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

[Lldb-commits] [lldb] [lldb] Support new libc++ __compressed_pair layout (PR #96538)

[Michael Buch via lldb-commits]

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

>From 294246a77e1bb16a34e9451bae65ad340c7ef7a9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Mon, 29 Jan 2024 16:23:16 +
Subject: [PATCH 1/4] [lldb] Support new libc++ __compressed_pair layout

---
 lldb/examples/synthetic/libcxx.py |  26 ++-
 .../Plugins/Language/CPlusPlus/LibCxx.cpp |  85 ++---
 .../Plugins/Language/CPlusPlus/LibCxx.h   |   3 +-
 .../Plugins/Language/CPlusPlus/LibCxxList.cpp |  72 +---
 .../Plugins/Language/CPlusPlus/LibCxxMap.cpp  |  41 +++--
 .../Language/CPlusPlus/LibCxxUnorderedMap.cpp | 166 +++---
 .../Language/CPlusPlus/LibCxxVector.cpp   |  38 ++--
 .../list/TestDataFormatterGenericList.py  |   2 +-
 8 files changed, 282 insertions(+), 151 deletions(-)

diff --git a/lldb/examples/synthetic/libcxx.py 
b/lldb/examples/synthetic/libcxx.py
index 474aaa428fa23..060ff90100849 100644
--- a/lldb/examples/synthetic/libcxx.py
+++ b/lldb/examples/synthetic/libcxx.py
@@ -721,6 +721,12 @@ def _get_value_of_compressed_pair(self, pair):
 def update(self):
 logger = lldb.formatters.Logger.Logger()
 try:
+has_compressed_pair_layout = True
+alloc_valobj = self.valobj.GetChildMemberWithName("__alloc_")
+size_valobj = self.valobj.GetChildMemberWithName("__size_")
+if alloc_valobj.IsValid() and size_valobj.IsValid():
+has_compressed_pair_layout = False
+
 # A deque is effectively a two-dim array, with fixed width.
 # 'map' contains pointers to the rows of this array. The
 # full memory area allocated by the deque is delimited
@@ -734,9 +740,13 @@ def update(self):
 # variable tells which element in this NxM array is the 0th
 # one, and the 'size' element gives the number of elements
 # in the deque.
-count = self._get_value_of_compressed_pair(
-self.valobj.GetChildMemberWithName("__size_")
-)
+if has_compressed_pair_layout:
+count = self._get_value_of_compressed_pair(
+self.valobj.GetChildMemberWithName("__size_")
+)
+else:
+count = size_valobj.GetValueAsUnsigned(0)
+
 # give up now if we cant access memory reliably
 if self.block_size < 0:
 logger.write("block_size < 0")
@@ -748,9 +758,13 @@ def update(self):
 self.map_begin = map_.GetChildMemberWithName("__begin_")
 map_begin = self.map_begin.GetValueAsUnsigned(0)
 map_end = 
map_.GetChildMemberWithName("__end_").GetValueAsUnsigned(0)
-map_endcap = self._get_value_of_compressed_pair(
-map_.GetChildMemberWithName("__end_cap_")
-)
+
+if has_compressed_pair_layout:
+map_endcap = self._get_value_of_compressed_pair(
+map_.GetChildMemberWithName("__end_cap_")
+)
+else:
+map_endcap = 
map_.GetChildMemberWithName("__end_cap_").GetValueAsUnsigned(0)
 
 # check consistency
 if not map_first <= map_begin <= map_end <= map_endcap:
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index feaa51a96843a..7d3b2410a7296 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -27,6 +27,7 @@
 #include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
 #include 
 #include 
 
@@ -34,6 +35,32 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
+static void consumeInlineNamespace(llvm::StringRef &name) {
+  // Delete past an inline namespace, if any: __[a-zA-Z0-9_]+::
+  auto scratch = name;
+  if (scratch.consume_front("__") && std::isalnum(scratch[0])) {
+scratch = scratch.drop_while([](char c) { return std::isalnum(c); });
+if (scratch.consume_front("::")) {
+  // Successfully consumed a namespace.
+  name = scratch;
+}
+  }
+}
+
+bool lldb_private::formatters::isOldCompressedPairLayout(
+ValueObject &pair_obj) {
+  return isStdTemplate(pair_obj.GetTypeName(), "__compressed_pair");
+}
+
+bool lldb_private::formatters::isStdTemplate(ConstString type_name,
+ llvm::StringRef type) {
+  llvm::StringRef name = type_name.GetStringRef();
+  // The type name may be prefixed with `std::__::`.
+  if (name.consume_front("std::"))
+consumeInlineNamespace(name);
+  return name.consume_front(type) && name.starts_with("<");
+}
+
 lldb::ValueObjectSP lldb_private::formatters::GetChildMemberWithName(
 ValueObject &obj, llvm::ArrayRef alternative_names) 

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

That *may* be how things works on windows(*), but I'm pretty sure it's not how 
things work on linux. A much more likely scenario is:
1. thread 1 opens a file for writing (file descriptor A) and starts writing it
2. thread 2 starts launching a gdb server. It calls fork(), which creates 
another process with a copy of fd A (the fd has the CLOEXEC flag set, but not 
CLOFORK (the flag doesn't exist))
3. thread 1 finishes writing, closes fd A (in its/parent process)
4. thread 1launches gdb-server, gdb-server tries to launch the file it has just 
written, gets ETXTBSY because the fd is still open in the child process

This isn't "operating system keeping the file open longer", this is us doing it 
(to be fair, the operating system is making it pretty hard to avoid doing 
that). And while this isn't an absolute thing (the workaround isn't as bad as 
the `select` thing, and it may also be possible to implement this in a way that 
the workaround isn't needed), I think this is a good reason to prefer a 
multiprocess implementation (where this situation does not occur because the fd 
cannot leak into another process).

> All tests are green with the current (single thread) lldb-server.

Does this refer the the forking implementation you get with the `--server` 
flag, or the serial implementation which only handles one connection at a time 
(without the flag)? Because if it's the former, this is a good proof that the 
scenario above is the (only) problem here.

(*) I just don't know enough about the system to have an informed opinion. This 
isn't the first time I've heard about the antivirus hypothesis, but I find that 
somewhat surprising, as that could mean that something like `$CC hello.cc && 
./a.out` could fail (what we're doing here isn't fundamentally different than 
that).

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

> * thread 1 opens a file for writing (file descriptor A) and starts writing it
> 
> * thread 2 starts launching a gdb server. It calls fork(), which creates 
> another process with a copy of fd A (the fd has the CLOEXEC flag set, but not 
> CLOFORK (the flag doesn't exist))
> 
> * thread 1 finishes writing, closes fd A (in its/parent process)
> 
> * thread 1launches gdb-server, gdb-server tries to launch the file it has 
> just written, gets ETXTBSY because the fd is still open in the child process

In this scenario, waiting does make the exec succeed, because the FD in the 
forked process will not stay open very long. It will get closed as soon as the 
process runs `execve` (due to CLOEXEC).

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

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)

[Pavel Labath via lldb-commits]

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


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

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

[Pavel Labath via lldb-commits]

@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
 endif
 CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem 
$(SDKROOT)/usr/include/c++/v1
 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++
+else
+ifneq (,$(findstring clang,$(CC)))
+# Force clang looking for the gcc's headers at specific rootfs 
folder.
+CXXFLAGS += -stdlib=libstdc++ $(GCC_TOOLCHAIN_FLAGS)

labath wrote:

That makes sense. The fix sounds good to me, but what does that mean for #99589 
? Is that compatible with this? Should we drop it?

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

[Lldb-commits] [lldb] d72c8b0 - [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (#100710)

[via lldb-commits]

Author: Michael Buch
Date: 2024-07-29T09:35:00+01:00
New Revision: d72c8b02802c87386f5db3c7de6c79e921618fa3

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

LOG: [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as 
ConstantArrayType (#100710)

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

Currently, we treat VLAs declared as `int[]` and `int[0]` identically.
I.e., we create them as `IncompleteArrayType`s. However, the
`DW_AT_count` for `int[0]` *does* exist, and is retrievable without an
execution context. This patch decouples the notion of "has 0 elements"
from "has no known `DW_AT_count`".

This aligns with how Clang represents `int[0]` in the AST (it treats it
as a `ConstantArrayType` of 0 size).

This issue was surfaced when adapting LLDB to
https://github.com/llvm/llvm-project/issues/93069. There, the
`__compressed_pair_padding` type has a `char[0]` member. If we
previously got the `__compressed_pair_padding` out of a module (where
clang represents `char[0]` as a `ConstantArrayType`), and try to merge
the AST with one we got from DWARF (where LLDB used to represent
`char[0]` as an `IncompleteArrayType`), the AST structural equivalence
check fails, resulting in silent ASTImporter failures. This manifested
in a failure in `TestNonModuleTypeSeparation.py`.

**Implementation**
1. Adjust `ParseChildArrayInfo` to store the element counts of each VLA
dimension as an `optional`, instead of a regular `uint64_t`.
So when we pass this down to `CreateArrayType`, we have a better
heuristic for what is an `IncompleteArrayType`.
2. In `TypeSystemClang::GetBitSize`, if we encounter a
`ConstantArrayType` simply return the size that it was created with. If
we couldn't determine the authoritative bound from DWARF during parsing,
we would've created an `IncompleteArrayType`. This ensures that
`GetBitSize` on arrays with `DW_AT_count 0x0` returns `0` (whereas
previously it would've returned a `std::nullopt`, causing that
`FieldDecl` to just get dropped during printing)

Added: 
lldb/test/Shell/SymbolFile/DWARF/vla.cpp

Modified: 
lldb/include/lldb/Symbol/SymbolFile.h
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
lldb/test/API/lang/c/struct_types/main.c

Removed: 




diff  --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index d20766788192f..8419495da73a2 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -211,7 +211,15 @@ class SymbolFile : public PluginInterface {
   /// The characteristics of an array type.
   struct ArrayInfo {
 int64_t first_index = 0;
-llvm::SmallVector element_orders;
+
+///< Each entry belongs to a distinct DW_TAG_subrange_type.
+///< For multi-dimensional DW_TAG_array_types we would have
+///< an entry for each dimension. An entry represents the
+///< optional element count of the subrange.
+///
+///< The order of entries follows the order of the DW_TAG_subrange_type
+///< children of this DW_TAG_array_type.
+llvm::SmallVector, 1> element_orders;
 uint32_t byte_stride = 0;
 uint32_t bit_stride = 0;
   };

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
index 409e9bb37ab28..4ed523bbb9e76 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.cpp
@@ -37,7 +37,7 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE 
&parent_die,
 if (attributes.Size() == 0)
   continue;
 
-uint64_t num_elements = 0;
+std::optional num_elements;
 uint64_t lower_bound = 0;
 uint64_t upper_bound = 0;
 bool upper_bound_valid = false;
@@ -91,7 +91,7 @@ DWARFASTParser::ParseChildArrayInfo(const DWARFDIE 
&parent_die,
   }
 }
 
-if (num_elements == 0) {
+if (!num_elements || *num_elements == 0) {
   if (upper_bound_valid && upper_bound >= lower_bound)
 num_elements = upper_bound - lower_bound + 1;
 }

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 85c59a605c675..a4dcde1629fc2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1395,20 +1395,20 @@ DWARFASTParserClang::ParseArrayType(const DWARFDIE &die,
   uint64_t array_element_bit_stride = byte_stride * 8 + bit_stride;
   CompilerType clang_type;
   if (array_info && array_info->element_orders.

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Create VLAs of explicitly 0-size as ConstantArrayType (PR #100710)

[Michael Buch via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

[David Spickett via lldb-commits]

DavidSpickett wrote:

This seems fine, but what happens currently? Does it try to use a tool that's 
built for the remote not the host?

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

[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

[Thorsten Schütt via lldb-commits]

tschuett wrote:

I heard rumours that you know a bit about ELF :)

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Pavel Labath via lldb-commits]

@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
 bytes_read += result;
 if (bytes_read == size || result == 0)
   break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() https://bugzilla.kernel.org/show_bug.cgi?id=546
+// ReadWithTimeout() with a non-zero timeout is used only to
+// read the port number from the gdbserver pipe
+// in GDBRemoteCommunication::StartDebugserverProcess().
+// The port number may be "1024\0".."65535\0".
+if (timeout.count() > 0 && size == 6 && bytes_read == 5 &&
+static_cast(buf)[4] == '\0') {
+  break;
+}

labath wrote:

I'm sorry, but I find this extremely hard to believe. Pipes and the ability to 
read them until EOF are as old as UNIX. We're not doing anything special here. 
It's going to take a lot more than a reference to a 20 year old `REJECTED 
INVALID` bug to convince me this is a kernel issue.

Also note that the situation mentioned in that bug is different from what (I 
think) you're describing here. In their case, the pipe is NOT closed on the 
*other* side. The pipe is closed on the side that's doing the `select`ing:

```
Consider a multithreaded program (pthreads). One thread reads from
a file descriptor (typically a TCP or UDP socket). At some time,
another thread decides to close(2) the file descriptor while the
first thread is blocked, waiting for input data.
```

In other words, this is your basic race in the application code, and it's the 
applications (ours) responsibility to fix it. While I'm not a kernel 
maintainer, I think I have a pretty good idea why they said the application is 
buggy, and why they didn't want to fix it -- it's because fixing it probably 
will not make the application correct.

The problem there is that the application has calls (`select` (or friends) and 
`close`) on two threads with no synchronization between them. Now if select 
happens to run first, then it's not completely unreasonable to expect that 
`close` will terminate that `select`, and the kernel could in theory make sure 
it does that (apparently, some operating systems do just that). The problem is 
what happens if `select` does not run first. What if `close` does ? In this 
case, `select` will return an error (as the bug reporter expects), but 
***only*** if the FD hasn't been reused in the mean time. And since linux 
always assigns the lowest FD available (I think POSIX mandates that), it's very 
likely that the very next operation (perhaps on a third thread) which creates 
an fd will get the same FD as we've just closed. If that happens, then the 
select will NOT return an error (the kernel has no way to know that it's 
referring to the old fd) and will happily start listening on the new fd. Since 
you usually aren't able to control all operations that could possibly create a 
new FD, this kind of pattern would be buggy except in extremely limited 
circumstances.

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Pavel Labath via lldb-commits]

labath wrote:

> @labath
> 
> > I wanted to change this code to use threads for a long time, but the idea 
> > of using a per-thread virtual file system absolutely terrifies me. That 
> > only works is all of the accesses go through the file system (no direct 
> > syscalls) and if we're very strict about which code executes on which 
> > thread. Right now, I don't think we're either, and I don't see how we could 
> > ever achieve it. (That's not exactly true for the code in the lldb-server, 
> > but we also don't really have enforcable rules for which code can be run in 
> > the lldb-server, and the code this is changing affects all of lldb).
> 
> We need the virtual working directory only for few requests via the platform 
> protocol. It is necessary to just resolve the path. Note I have added only 2 
> updates for that. All the rest code already uses lldb::FileSystem correctly. 

I believe that the code that's necessary to run `lldb-server platform` uses the 
filesystem correctly. I trust you've made sure of that by running the test 
suite. However, I don't think you can claim that for every usage of the 
FileSystem class in everywhere in lldb, because for most of those you can't 
even tell whether they'd want to use a "thread-local" filesystem or a global 
one.

I certainly can't do it, and that's kind of my point: I think this is a bad 
abstraction. Outside of a very limited use case, it's impossible to reason 
about this and/or prove that introducing a thread-local cwd is safe and 
correct. We're often optimizing code by moving it from one thread to another, 
or farming it out to a thread pool, and we also have code that can run on 
several threads in different contexts. All of these things could cause 
"correct" code  to suddenly stop working because a completely unrelated code 
has been changed to run on a different thread.

If this is only really used for a "only for few requests via the platform 
protocol", then why not make the CWD a property of the platform object? (Either 
through a virtual filesystem, or just by having it as a string, and resolving 
things explicitly)

> Once a process (`lldb-server gdbserver` or test app) is started, its process 
> uses its own working directory.

Ack.

> 
> > (Also, I guess this is the reason for the ETXTBSY workaround)
> 
> I don't see the connection. See more details in #100659 discussion.
> 
> > to replace the fork with spawning a new process (fork+execve) instead. Have 
> > you considered that?
> 
> To fix all gdb port mapping issues we need a common port mapping available in 
> all platform connection handlers. It is possible only with the multithreading.

I think that using threads for the management of a common port resource is a 
very elegant solution. I did not realize you're trying to solve that, for which 
I apologise. That said, I think it's a stretch to say this is the only way to 
solve this issue. I can think at least four other potential solutions (with 
different tradeoffs) right now. This is my favourite:

**Don't use port mappings** (at least in the multi-process `--server` mode). 
AFAICT, the only reason it exists is because lldb uses an FTP-like connection 
that's incompatible with firewals/NATs/etc. This means that every user has to 
first discover this problem, then learn about the port map flags to lldb, and 
then to configure their firewall to let these ports through. We get questions 
about this regularly. Everything would be a lot simpler if everything went 
through a single port.

The way this would work is by letting the platform instance 
delegate/upgrate/convert the platform connection into a gdbserver one. The way 
this would work would be something like this:
1. `lldb-server platform` would advertise (say in `qSupported`) its support for 
this new mode.
2. Before asking the platform to launch a new gdb server, lldb would query this 
feature. If present, instead of the usual action (`qLaunchGDBServer`), it would 
create *another* platform connection, using the same port as the original one. 
As we're using the same port, we'd go through all the nats just like the 
original connection.
3. On this new connection it would send a new special packet (let's call it 
`qUpgradeToGdbConnection`)
4. `lldb server platform` would launch an gdbserver instance and everything 
else would proceed as before.

On non-darwin platform (darwin uses `debugserver`) we could optimize to avoid 
spawning a new process, and just call the relevant gdb-server code directly. 
This might be nice cause then we could use `execve` (unsupported on windows) 
for calling the debugserver on darwin, and all other platforms would work the 
same way as windows. But this is still just an optimization, and passing the 
socket through fork+exec/CreateProcess could still work everywhere.

> And I don't see a way to delegate the accepted incoming connection to a 
> spawned process on Windows.

Though I'm not a windows expert, I'm pretty sure that's possible. Windows has 

[Lldb-commits] [lldb] [WIP][lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

[Pavel Labath via lldb-commits]

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


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

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

Could we standardize on `$(OBJCOPY) --strip-debug` instead?

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> If this is only really used for a "only for few requests via the platform 
> protocol", then why not make the CWD a property of the platform object? 
> (Either through a virtual filesystem, or just by having it as a string, and 
> resolving things explicitly)

It is possible to store an own FileSystem object in the platform handler, but 
it requires to update 80% of GDBRemoteCommunicationServerCommon.cpp and 
implement some behavior switch in inherited classes.

I tried to minimize changes.  I have added the new 
FileSystem::InitializePerThread() which is used only in 
GDBRemoteCommunicationServerPlatform and its base clases in case of 
multithreading. All other code uses the same FileSystem, nothing changed. 
FileSystem::InitializePerThread() uses the CWD of the app. So the behavior for 
the thread is the same as for a forked child process.

I don't see any other threads where FileSystem is used. `lldb-server platform` 
creates only one additional thread to monitor a child process. But it does not 
use any file system operations. 

Anyway if FileSystem::InitializePerThread() was not called, any new thread uses 
the common app's FileSystem. It is safe.

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

[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

[Pavel Labath via lldb-commits]

labath wrote:

I like this idea a lot, but I have some reservations about the implementation.

For one, I think this patch is too big. I once heard someone say "if you have 
bullet points in your patch description, then the patch is doing too much". 
While I don't think we should go as far as to create a separate PR for each of 
your bullet points, I splitting it up into a couple of pieces would go along 
way towards making it easier to review.

I also see that some of the functionality is guarded by `IsInMemory()`, which 
doesn't sounds like the right thing to do, as the we should in principle be 
able to use the same code for parsing parsing section-header-less object files 
on disk. These aren't exactly common, but like @MaskRay said, section headers 
aren't strictly needed for linked object files, and it's much easier to make 
test using these.

Finally, I think that structuring some of this code as "fallback" is not ideal, 
as it can cause some data can be parsed twice (I think it happens at least with 
ELF notes in this patch). Even if that's innocuous , I don't think it's right 
because the two mechanisms (program and section headers) are just different 
ways of finding the same data. I think it'd be cleaner if this was implemented 
as a two-step process:
1. find the data (e.g., notes): This will look into section and program headers 
to find the appropriate bytes (I might even argue it should look at program 
headers first, as that's what the operating system will use)
2. use the data (regardless of where it comes from)

I realise this feedback isn't very specific, but that's because I found it very 
hard to follow everything that's going on in this patch. I'm sure I'll be able 
to be more specific on the partial patches (and maybe some of my assumptions 
will turn out to be incorrect). As a first patch in the series, I'd recommend 
teaching lldb to parse section-header-less object files. Right now, if I run 
lldb on such a file, it will tell me that it's empty (has zero sections). 
Making the program headers visible would lay the foundation for other changes, 
and it would also be the smallest testable piece of functionality (by dumping 
the section list).

@MaskRay can you recommend a good to create these kinds of files? I was 
thinking of a combination `yaml2obj` + `llvm-objcopy --strip-sections` (because 
IIRC yaml2obj always inserts some sections into the output), but maybe there's 
something better (?)

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> Does this refer the the forking implementation you get with the --server 
> flag, or the serial implementation which only handles one connection at a 
> time (without the flag)?

I mean the `--server` flag. It is very hard to reproduce this issue with the 
serial implementation because it is much slower.

> - thread 1 opens a file for writing (file descriptor A) and starts writing it
> - thread 2 starts launching a gdb server. It calls fork(), which creates 
> another process with a copy of fd A (the fd has the CLOEXEC flag set, but not 
> CLOFORK (the flag doesn't exist))
> - thread 1 finishes writing, closes fd A (in its/parent process)
> - thread 1launches gdb-server, gdb-server tries to launch the file it has 
> just written, gets ETXTBSY because the fd is still open in the child process

> In this scenario, waiting does make the exec succeed, because the FD in the 
> forked process will not stay open very long. It will get closed as soon as 
> the process runs execve (due to CLOEXEC).

Your scenario is impossible. How FD will be closed by execve() if execve() 
failed with ETXTBSY?

- `lldb-server platform` (a `thread 1` or just a process) creates, writes and 
closes the file. The FD is closed and may be reused by the system. The client 
lldb received the response OK for `vFile:close` request.
- The same `thread 1` launched `gdb server` (fork+execve). The FD of a created 
and closed file cannot be copied any way.
- The client lldb connects to `gdb server` and send the request `vRun`
- `gdb server` did not create or write the executable. It never had the FD of 
this file and did not inherit it. `gdb server` just fork a child process and 
try to call execve(), but it failed with ETXTBSY.

> `$CC hello.cc && ./a.out` could fail

May it work? How is it possible?


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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Pavel Labath via lldb-commits]

labath wrote:

> > If this is only really used for a "only for few requests via the platform 
> > protocol", then why not make the CWD a property of the platform object? 
> > (Either through a virtual filesystem, or just by having it as a string, and 
> > resolving things explicitly)
> 
> It is possible to store an own FileSystem object in the platform handler, but 
> it requires to update 80% of GDBRemoteCommunicationServerCommon.cpp and 
> implement some behavior switch in inherited classes.

That does not worry me. In fact, I would say that if *all* we need to update is 
GDBRemoteCommunicationServerCommon and its subclasses, then we're pretty good.


> 
> I tried to minimize changes. I have added the new 
> FileSystem::InitializePerThread() which is used only in 
> GDBRemoteCommunicationServerPlatform and its base clases in case of 
> multithreading. All other code uses the same FileSystem, nothing changed. 
> FileSystem::InitializePerThread() uses the CWD of the app. So the behavior 
> for the thread is the same as for a forked child process.
> 
> I don't see any other threads where FileSystem is used. `lldb-server 
> platform` creates only one additional thread to monitor a child process. But 
> it does not use any file system operations.
> 
> Anyway if FileSystem::InitializePerThread() was not called, any new thread 
> uses the common app's FileSystem. It is safe.

I realize all that, but I still don't think it's a good tradeoff -- 
complicating one low-level library (which is pretty complicated on its own), 
for the sake of one very specific user. I can see how someone might view it 
differently and you're welcome to find those people and get them on board with 
your approach. I just don't think I'm going to be one of them.

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> that could mean that something like `$CC hello.cc && ./a.out` could fail 
> (what we're doing here isn't fundamentally different than that).

The difference is that cc creates a.out and exits itself. But `lldb-server 
platform` is still running after creating the executable. Something must be 
flushed?

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

See also https://github.com/golang/go/issues/22315

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

> > Does this refer the the forking implementation you get with the --server 
> > flag, or the serial implementation which only handles one connection at a 
> > time (without the flag)?
> 
> I mean the `--server` flag. It is very hard to reproduce this issue with the 
> serial implementation because it is much slower.

Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors with 
the current implementation `--server` flag. Is that correct ?

> > * thread 1 opens a file for writing (file descriptor A) and starts writing 
> > it
> > * thread 2 starts launching a gdb server. It calls fork(), which creates 
> > another process with a copy of fd A (the fd has the CLOEXEC flag set, but 
> > not CLOFORK (the flag doesn't exist))
> > * thread 1 finishes writing, closes fd A (in its/parent process)
> > * thread 1launches gdb-server, gdb-server tries to launch the file it has 
> > just written, gets ETXTBSY because the fd is still open in the child process
> 
> > In this scenario, waiting does make the exec succeed, because the FD in the 
> > forked process will not stay open very long. It will get closed as soon as 
> > the process runs execve (due to CLOEXEC).

There are two threads and (at least two execve()s) happening here. I'm 
referring to the one on thread 2 (specifically, the fork child of thread 2).  
Your description describes what happens on one thread (well, one line of 
execution, corresponding to one e.g.  test). Let me try this again. I'm just 
going to take your description, copy it twice and interleave it (*italic* is 
for one line of execution **bold** is for the second one, regular text is my 
commentary):




1. *`lldb-server platform` (a `thread 1` or just a process) creates, writes* 
2. note that at this point the file remains open in the lldb-platform process. 
This is going to be our mythical FD
3. **`lldb-server platform` (a `thread 1` or just a process) creates, writes 
and closes the file. The FD is closed and may be reused by the system. The 
client lldb received the response OK for `vFile:close` request.**
4.  **The same `thread 1` launched `gdb server` (fork**
5. note the fork creates a new process. The process is going to have a copy of 
the mythical FD
6. *and closes the file. The FD is closed and may be reused by the system. The 
client lldb received the response OK for `vFile:close` request.*
7. note the mythical FD is only closed in the parent process. It still exists 
in the fork child
8. *The same `thread 1` launched `gdb server` (fork+execve). The FD of the 
created and closed file cannot be copied any way.*
9. We don't need to make a copy of the fd here. The copy was made earlier.
10. *`gdb server` did not create or write the executable. It never had the FD 
of this file and did not inherit it. `gdb server` just fork a child process and 
try to call execve(), but it failed with ETXTBSY.*
11. We get ETXTBSY because the FD is still open in the process forked on step 4
12. **+execve). The FD of the created and closed file cannot be copied any 
way.**
13. The mythical fd is fully closed after the execve() call
14. *`gdb server` waits little bit and try to call execve() again. It is 
successful after several attempts. No one closed the mythical FD during this 
time.*
15. Yes, they did.


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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

> > that could mean that something like `$CC hello.cc && ./a.out` could fail 
> > (what we're doing here isn't fundamentally different than that).
> 
> The difference is that cc creates a.out and exits itself. But `lldb-server 
> platform` is still running after creating the executable. Something must be 
> flushed?

Ok, this wasn't the best analogy. I still stand by my analysis of the problem 
though.



> See also [golang/go#22315](https://github.com/golang/go/issues/22315)

That's exactly the problem I'm describing here. And I'm considering something 
like https://github.com/golang/go/issues/22315#issuecomment-2188688461 as the 
solution (if we really do go through with this). The bug is that the FD gets 
leaked, and the fix is to make sure it doesn't get leaked. Waiting is a 
workaround because there's no guarantee that whoever we leak it to will close 
it.. ever. The only reason the workaround is here is because the bug was in 
third party code we can't change (everywhere.. we did change it, but only for 
new androids)

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors with 
> the current implementation --server flag. Is that correct ?

Right. Initially I have marked #100670 as dependent on this.

Ok, agreed. So, we can try to use O_CLOFORK. 
And simple solution is to call execve() as fast as possible and wait some time 
in case of ETXTBSY (this PR).

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Pavel Labath via lldb-commits]

labath wrote:

> > Ok, so if I'm reading this right you're saying you saw no ETXTBSY errors 
> > with the current implementation --server flag. Is that correct ?
> 
> Right. Initially I have marked #100670 as dependent on this.
> 
> Ok, agreed. So, we can try to use O_CLOFORK. And simple solution is to call 
> execve() as fast as possible and wait some time in case of ETXTBSY (this PR).

Umm.. by "current" I meant the current implementation that's in the llvm 
repository, so I'm not sure if we're agreeing to anything (yet).

O_CLOFORK doesn't exist (that's the really mythical part). I wish it did 
though...

I don't think we can call execve appreciably faster than we already do. I'm 
still not sure if I am ok with the wait workaround, but I think it could wait 
until we settle some other things first. For one, I'd like to hear your opinion 
on my port mapping alternative.

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

[Lldb-commits] [lldb] [lldb] Add format eFormatEnumWithValues to ensure raw enum value is always shown (PR #90059)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> So instead of using enum for the field why not a union of enum and unsigned.

The union idea sort of works, but it's clunky enough I'm not going to pursue 
it. The most verbose version:
```
fpcr = 0x
 = {
<...>
 RMode = (meaning = RN, value = 0)
```
Then you can set a decl printing helper and match on the generated type names 
to remove
some of it:
```
fpcr = 0x
 = {
<...>
 RMode = {
RN
   RMode = 0
 }
```
With a typedef I could remove the final "RMode", right now it's "unsigned 
int:2" so the
helper doesn't kick in.

Seems to force vertical layout, and the two values will always be on separate 
lines.
This looks awkward enough that I'd rather just keep the existing format.

Now I'll see if I can use the existing dump code for all but the enums, as you 
suggested.

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> The way this would work is by letting the platform instance 
> delegate/upgrate/convert the platform connection into a gdbserver one. The 
> way this would work would be something like this:
> 
> 1. `lldb-server platform` would advertise (say in `qSupported`) its support 
> for this new mode.
> 2. Before asking the platform to launch a new gdb server, lldb would query 
> this feature. If present, instead of the usual action (`qLaunchGDBServer`), 
> it would create _another_ platform connection, using the same port as the 
> original one. As we're using the same port, we'd go through all the nats just 
> like the original connection.
> 3. On this new connection it would send a new special packet (let's call it 
> `qUpgradeToGdbConnection`)
> 4. `lldb server platform` would launch an gdbserver instance and everything 
> else would proceed as before.
> 
> On non-darwin platform (darwin uses `debugserver`) we could optimize to avoid 
> spawning a new process, and just call the relevant gdb-server code directly.

But debugserver on darwin will not support this feauture. It will still require 
the port map or disabling firewall. 

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

> I'd like to hear your opinion on my port mapping alternative.

https://github.com/llvm/llvm-project/pull/100670#issuecomment-2255991921

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Pavel Labath via lldb-commits]

labath wrote:

> > The way this would work is by letting the platform instance 
> > delegate/upgrate/convert the platform connection into a gdbserver one. The 
> > way this would work would be something like this:
> > 
> > 1. `lldb-server platform` would advertise (say in `qSupported`) its support 
> > for this new mode.
> > 2. Before asking the platform to launch a new gdb server, lldb would query 
> > this feature. If present, instead of the usual action (`qLaunchGDBServer`), 
> > it would create _another_ platform connection, using the same port as the 
> > original one. As we're using the same port, we'd go through all the nats 
> > just like the original connection.
> > 3. On this new connection it would send a new special packet (let's call it 
> > `qUpgradeToGdbConnection`)
> > 4. `lldb server platform` would launch an gdbserver instance and everything 
> > else would proceed as before.
> > 
> > On non-darwin platform (darwin uses `debugserver`) we could optimize to 
> > avoid spawning a new process, and just call the relevant gdb-server code 
> > directly.
> 
> But debugserver on darwin will not support this feauture. It will still 
> require the port map or disabling firewall.

I think it should already [support 
that](https://github.com/llvm/llvm-project/blob/97c62b8f7501d1c6c2f507b075fbe45a31d2b9dc/lldb/tools/debugserver/source/debugserver.cpp#L1297).
 If it doesn't, and it comes down to this, I volunteer to help you with making 
sure that works.

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

[Lldb-commits] [lldb] [lldb] Add format eFormatEnumWithValues to ensure raw enum value is always shown (PR #90059)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Add format eFormatEnumWithValues to ensure raw enum value is always shown (PR #90059)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Custom printing code for just enums for registers would be possible but it 
means copying a lot of existing code. A callback reduces that to a copy of 
`DumpEnumValue` only. Or you can iterate the value object yourself but then you 
have to provide the surrounding format too for example the `{}` around a struct 
and so on.

I found I can modify the summary by changing 
`TypeFormatImpl_Format::FormatObject`, but this has the problem that it does 
not know if the enum value will match an enumerator ahead of time. So it works 
well for ` `, but not if you only sometimes 
want the extra stuff. So another lookahead or callback needed here.

None of the options are great and this is not a required feature so I'm going 
to drop this for now. Maybe one of them will stand out when I look again later.

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {

labath wrote:

Could we make this function always get a valid object? Perhaps even go so far 
as to pass a `ValueObject&` to it (if needed, you can get a shared pointer 
through the `GetSP` method)

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

I still have a lot of comments, but I think we're making progress.

The most important questions are about the parts where we appear to be 
reimplementing some existing lldb functionality. Basically all of the 
functionality for looking up names (for members, variables, types, etc.) 
appears to be more complex than necessary. For each of those things, we already 
have lldb functions, which one would (perhaps naively) expect to just call and 
have them do the right thing. I'd like to understand why that isn't the case, 
and whether we can do something about it (there are certainly bugs in those 
functions, and if that's the case it'd be better to fix those bugs than to work 
around them here).

At this point, perhaps the only way to figure that out is to strip them and see 
what breaks.

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.

labath wrote:

```suggestion
/// use_synthetic options passed.
```

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode

labath wrote:

Can we get rid of this as well (for the time being, at least)? It sounds like 
one of those things that may require rearchitecting to avoid smart pointer 
assumptions...

(And even we do end up adding it, I don't think it should be called "**smart 
pointer** decay", as, as far as this code is concerned, I think we shouldn't be 
making a difference between std::unique_ptr and say std::optional. I guess you 
could stretch the "smart pointer" definition to cover optionals, but that 
doesn't seem ideal)

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,

labath wrote:

This looks like a hidden reference to a `this` keyword.

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,560 @@
+//===-- DILAST.cpp 
===//
+//
+// 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 "lldb/Core/DILAST.h"
+#include "lldb/API/SBType.h"
+#include "lldb/Core/ValueObjectRegister.h"
+#include "lldb/Core/ValueObjectVariable.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Symbol/VariableList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Target/RegisterContext.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace lldb_private {
+
+namespace DIL {
+
+lldb::ValueObjectSP
+GetDynamicOrSyntheticValue(lldb::ValueObjectSP in_valobj_sp,
+   lldb::DynamicValueType use_dynamic,
+   bool use_synthetic) {
+  Status error;
+
+  if (!in_valobj_sp) {
+error.SetErrorString("invalid value object");
+return in_valobj_sp;
+  }
+
+  lldb::ValueObjectSP value_sp = in_valobj_sp;
+
+  Target *target = value_sp->GetTargetSP().get();
+  // If this ValueObject holds an error, then it is valuable for that.
+  if (value_sp->GetError().Fail())
+return value_sp;
+
+  if (!target)
+return lldb::ValueObjectSP();
+
+  if (use_dynamic != lldb::eNoDynamicValues) {
+lldb::ValueObjectSP dynamic_sp = value_sp->GetDynamicValue(use_dynamic);
+if (dynamic_sp)
+  value_sp = dynamic_sp;
+  }
+
+  if (use_synthetic) {
+lldb::ValueObjectSP synthetic_sp = value_sp->GetSyntheticValue();
+if (synthetic_sp)
+  value_sp = synthetic_sp;
+  }
+
+  if (!value_sp)
+error.SetErrorString("invalid value object");
+
+  return value_sp;
+}
+
+CompilerType DILASTNode::GetDereferencedResultType() const {
+  auto type = result_type();
+  return type.IsReferenceType() ? type.GetNonReferenceType() : type;
+}
+
+std::optional
+GetFieldWithNameIndexPath(lldb::ValueObjectSP lhs_val_sp, CompilerType type,
+  const std::string &name, std::vector *idx,
+  CompilerType empty_type, bool use_synthetic,
+  bool is_dynamic) {
+  bool is_synthetic = false;
+  // Go through the fields first.
+  uint32_t num_fields = type.GetNumFields();
+  lldb::ValueObjectSP empty_valobj_sp;
+  for (uint32_t i = 0; i < num_fields; ++i) {
+uint64_t bit_offset = 0;
+uint32_t bitfield_bit_size = 0;
+bool is_bitfield = false;
+std::string name_sstr;
+CompilerType field_type(type.GetFieldAtIndex(
+i, name_sstr, &bit_offset, &bitfield_bit_size, &is_bitfield));
+auto field_name =
+name_sstr.length() == 0 ? std::optional() : name_sstr;
+if (field_type.IsValid()) {
+  std::optional size_in_bits;
+  if (is_bitfield)
+size_in_bits = bitfield_bit_size;
+  struct MemberInfo field = {field_name,   field_type, size_in_bits,
+ is_synthetic, is_dynamic, empty_valobj_sp};
+
+  // Name can be null if this is a padding field.
+  if (field.name == name) {
+if (lhs_val_sp) {
+  lldb::ValueObjectSP child_valobj_sp =
+  lhs_val_sp->GetChildMemberWithName(name);
+  if (child_valobj_sp)
+field.val_obj_sp = child_valobj_sp;
+}
+
+if (idx) {
+  assert(idx->empty());
+  // Direct base classes are located before fields, so field members
+  // needs to be offset by the number of base classes.
+  idx->push_back(i + type.GetNumberOfNonEmptyBaseClasses());
+}
+return field;
+  } else if (field.type.IsAnonymousType()) {
+// Every member of an anonymous struct is considered to be a member of
+// the enclosing struct or union. This applies recursively if the
+// enclosing struct or union is also anonymous.
+
+assert(!field.name && "Field should be unnamed.");
+
+std::optional field_in_anon_type =
+GetFieldWithNameIndexPath(lhs_val_sp, field.type, name, idx,
+  empty_type, use_synthetic, is_dynamic);
+if (field_in_anon_type) {
+  if (idx) {
+idx->push_back(i + type.GetNumberOfNonEmptyBaseClasses());
+  }
+  return field_in_anon_type.value();
+}
+  }
+}
+  }
+
+  // LLDB can't access inherited fields of anonymous struct members.
+  if (type.IsAnonymousType()) {
+return {};
+  }
+
+  // Go through the base classes and look for the field there.
+  uint32_t num_non_empty_bases = 0;
+  uint32_t num_direct_bases = type.GetNumDirectBaseClasses();
+  for (uint32_t i = 0; i < num_direct_bases; ++i) {
+uint32_t bit_offset;
+auto base = type.GetDirectBaseClassAtIndex(i, &bit_offset);
+auto field = GetFieldWithNameIndexPath(
+lhs_val_sp, base

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;

labath wrote:

This would normally be outside of the class, so it can be used from other code 
as well. If you're only using it for internal code, then it probably doesn't 
need to exist (note you can get rid of about half of the uses of this name by 
using std::make_unique)

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,560 @@
+//===-- DILAST.cpp 
===//
+//
+// 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 "lldb/Core/DILAST.h"
+#include "lldb/API/SBType.h"
+#include "lldb/Core/ValueObjectRegister.h"
+#include "lldb/Core/ValueObjectVariable.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Symbol/VariableList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Target/RegisterContext.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace lldb_private {
+
+namespace DIL {
+
+lldb::ValueObjectSP
+GetDynamicOrSyntheticValue(lldb::ValueObjectSP in_valobj_sp,
+   lldb::DynamicValueType use_dynamic,
+   bool use_synthetic) {
+  Status error;
+
+  if (!in_valobj_sp) {
+error.SetErrorString("invalid value object");
+return in_valobj_sp;
+  }
+
+  lldb::ValueObjectSP value_sp = in_valobj_sp;
+
+  Target *target = value_sp->GetTargetSP().get();
+  // If this ValueObject holds an error, then it is valuable for that.
+  if (value_sp->GetError().Fail())
+return value_sp;
+
+  if (!target)
+return lldb::ValueObjectSP();
+
+  if (use_dynamic != lldb::eNoDynamicValues) {
+lldb::ValueObjectSP dynamic_sp = value_sp->GetDynamicValue(use_dynamic);
+if (dynamic_sp)
+  value_sp = dynamic_sp;
+  }
+
+  if (use_synthetic) {
+lldb::ValueObjectSP synthetic_sp = value_sp->GetSyntheticValue();
+if (synthetic_sp)
+  value_sp = synthetic_sp;
+  }
+
+  if (!value_sp)
+error.SetErrorString("invalid value object");
+
+  return value_sp;
+}
+
+CompilerType DILASTNode::GetDereferencedResultType() const {
+  auto type = result_type();
+  return type.IsReferenceType() ? type.GetNonReferenceType() : type;
+}
+
+std::optional

labath wrote:

Why doesn't this function just call `lhs_val_sp.GetChildMemberWithName(name)` 
(or something similar?

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,560 @@
+//===-- DILAST.cpp 
===//
+//
+// 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 "lldb/Core/DILAST.h"
+#include "lldb/API/SBType.h"
+#include "lldb/Core/ValueObjectRegister.h"
+#include "lldb/Core/ValueObjectVariable.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Symbol/VariableList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Target/RegisterContext.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace lldb_private {
+
+namespace DIL {
+
+lldb::ValueObjectSP
+GetDynamicOrSyntheticValue(lldb::ValueObjectSP in_valobj_sp,
+   lldb::DynamicValueType use_dynamic,
+   bool use_synthetic) {
+  Status error;
+
+  if (!in_valobj_sp) {
+error.SetErrorString("invalid value object");
+return in_valobj_sp;
+  }
+
+  lldb::ValueObjectSP value_sp = in_valobj_sp;
+
+  Target *target = value_sp->GetTargetSP().get();
+  // If this ValueObject holds an error, then it is valuable for that.
+  if (value_sp->GetError().Fail())
+return value_sp;
+
+  if (!target)
+return lldb::ValueObjectSP();
+
+  if (use_dynamic != lldb::eNoDynamicValues) {
+lldb::ValueObjectSP dynamic_sp = value_sp->GetDynamicValue(use_dynamic);
+if (dynamic_sp)
+  value_sp = dynamic_sp;
+  }
+
+  if (use_synthetic) {
+lldb::ValueObjectSP synthetic_sp = value_sp->GetSyntheticValue();
+if (synthetic_sp)
+  value_sp = synthetic_sp;
+  }
+
+  if (!value_sp)
+error.SetErrorString("invalid value object");
+
+  return value_sp;
+}
+
+CompilerType DILASTNode::GetDereferencedResultType() const {
+  auto type = result_type();
+  return type.IsReferenceType() ? type.GetNonReferenceType() : type;
+}
+
+std::optional
+GetFieldWithNameIndexPath(lldb::ValueObjectSP lhs_val_sp, CompilerType type,
+  const std::string &name, std::vector *idx,
+  CompilerType empty_type, bool use_synthetic,
+  bool is_dynamic) {
+  bool is_synthetic = false;
+  // Go through the fields first.
+  uint32_t num_fields = type.GetNumFields();
+  lldb::ValueObjectSP empty_valobj_sp;
+  for (uint32_t i = 0; i < num_fields; ++i) {
+uint64_t bit_offset = 0;
+uint32_t bitfield_bit_size = 0;
+bool is_bitfield = false;
+std::string name_sstr;
+CompilerType field_type(type.GetFieldAtIndex(
+i, name_sstr, &bit_offset, &bitfield_bit_size, &is_bitfield));
+auto field_name =
+name_sstr.length() == 0 ? std::optional() : name_sstr;
+if (field_type.IsValid()) {
+  std::optional size_in_bits;
+  if (is_bitfield)
+size_in_bits = bitfield_bit_size;
+  struct MemberInfo field = {field_name,   field_type, size_in_bits,
+ is_synthetic, is_dynamic, empty_valobj_sp};
+
+  // Name can be null if this is a padding field.
+  if (field.name == name) {
+if (lhs_val_sp) {
+  lldb::ValueObjectSP child_valobj_sp =
+  lhs_val_sp->GetChildMemberWithName(name);
+  if (child_valobj_sp)
+field.val_obj_sp = child_valobj_sp;
+}
+
+if (idx) {
+  assert(idx->empty());
+  // Direct base classes are located before fields, so field members
+  // needs to be offset by the number of base classes.
+  idx->push_back(i + type.GetNumberOfNonEmptyBaseClasses());
+}
+return field;
+  } else if (field.type.IsAnonymousType()) {
+// Every member of an anonymous struct is considered to be a member of
+// the enclosing struct or union. This applies recursively if the
+// enclosing struct or union is also anonymous.
+
+assert(!field.name && "Field should be unnamed.");
+
+std::optional field_in_anon_type =
+GetFieldWithNameIndexPath(lhs_val_sp, field.type, name, idx,
+  empty_type, use_synthetic, is_dynamic);
+if (field_in_anon_type) {
+  if (idx) {
+idx->push_back(i + type.GetNumberOfNonEmptyBaseClasses());
+  }
+  return field_in_anon_type.value();
+}
+  }
+}
+  }
+
+  // LLDB can't access inherited fields of anonymous struct members.
+  if (type.IsAnonymousType()) {
+return {};
+  }
+
+  // Go through the base classes and look for the field there.
+  uint32_t num_non_empty_bases = 0;
+  uint32_t num_direct_bases = type.GetNumDirectBaseClasses();
+  for (uint32_t i = 0; i < num_direct_bases; ++i) {
+uint32_t bit_offset;
+auto base = type.GetDirectBaseClassAtIndex(i, &bit_offset);
+auto field = GetFieldWithNameIndexPath(
+lhs_val_sp, base

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,446 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_DIL_AST_H_
+#define LLDB_DIL_AST_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+
+namespace lldb_private {

labath wrote:

It should really be a lowercase `dil`. All of our namespaces are like that. 
(That's one naming scheme consistent across all of llvm)

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

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }
+
+  CompilerType GetType() { return m_type; }
+  bool IsValid() const { return m_type.IsValid(); }
+
+  IdentifierInfo(Kind kind, CompilerType type, lldb::ValueObjectSP value,
+ MemberPath path)
+  : m_kind(kind), m_type(type), m_value(std::move(value)),
+m_path(std::move(path)) {}
+
+private:
+  Kind m_kind;
+  CompilerType m_type;
+  lldb::ValueObjectSP m_value;
+  MemberPath m_path;
+};
+
+/// Given the name of an identifier (variable name, member name, type name,
+/// etc.), find the ValueObject for that name (if it exists) and create and
+/// return an IdentifierInfo object containing all the relevant information
+/// about that object (for DIL parsing and evaluating).
+std::unique_ptr LookupIdentifier(
+const std::string &name, std::shared_ptr ctx_scope,
+lldb::DynamicValueType use_dynamic, CompilerType *scope_ptr = nullptr);
+
+/// Forward declaration, for use in DIL AST nodes. Definition is at the very
+/// end of this file.
+class Visitor;
+
+/// The rest of the classes in this file, except for the Visitor class at the
+/// very end, define all the types of AST nodes used by the DIL parser and
+/// expression evaluator. The DIL parser parses the input string and creates 
the
+/// A

[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,459 @@
+//===-- DILAST.h *- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional name;
+  CompilerType type;
+  std::optional bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+lldb::ValueObjectSP valobj_sp,
+lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
+};
+
+/// The C-Style casts for type promotion allowed by DIL.
+enum class TypePromotionCastKind {
+  eArithmetic,
+  ePointer,
+};
+
+/// The Unary operators recognized by DIL.
+enum class UnaryOpKind {
+  AddrOf, // "&"
+  Deref,  // "*"
+  Minus,  // "-"
+};
+
+/// Given a string representing a type, returns the CompilerType corresponding
+/// to the named type, if it exists.
+CompilerType
+ResolveTypeByName(const std::string &name,
+  std::shared_ptr ctx_scope);
+
+/// Class used to store & manipulate information about identifiers.
+class IdentifierInfo {
+private:
+  using MemberPath = std::vector;
+  using IdentifierInfoUP = std::unique_ptr;
+
+public:
+  enum class Kind {
+eValue,
+eContextArg,
+eMemberPath,
+eThisKeyword,
+  };
+
+  static IdentifierInfoUP FromValue(lldb::ValueObjectSP value_sp) {
+CompilerType type;
+if (value_sp)
+  type = value_sp->GetCompilerType();
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eValue, type, value_sp, {}));
+  }
+
+  static IdentifierInfoUP FromContextArg(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eContextArg, type, empty_value, {}));
+  }
+
+  static IdentifierInfoUP FromMemberPath(CompilerType type, MemberPath path) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(new IdentifierInfo(Kind::eMemberPath, type,
+   empty_value, std::move(path)));
+  }
+
+  static IdentifierInfoUP FromThisKeyword(CompilerType type) {
+lldb::ValueObjectSP empty_value;
+return IdentifierInfoUP(
+new IdentifierInfo(Kind::eThisKeyword, type, empty_value, {}));
+  }
+
+  Kind kind() const { return m_kind; }
+  lldb::ValueObjectSP value() const { return m_value; }
+  const MemberPath &path() const { return m_path; }

labath wrote:

This is mixing conventions. I'd probably call all of these `GetXxx`

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

[Lldb-commits] [lldb] [LLDB][test] Update Makefile.rules to support Windows host+Linux target (PR #99266)

[Vladislav Dzhidzhoev via lldb-commits]

@@ -456,21 +492,15 @@ ifeq (1, $(USE_SYSTEM_STDLIB))
 endif
 CXXFLAGS += -nostdlib++ -nostdinc++ -cxx-isystem 
$(SDKROOT)/usr/include/c++/v1
 LDFLAGS += -L$(SDKROOT)/usr/lib -Wl,-rpath,$(SDKROOT)/usr/lib -lc++
+else
+ifneq (,$(findstring clang,$(CC)))
+# Force clang looking for the gcc's headers at specific rootfs 
folder.
+CXXFLAGS += -stdlib=libstdc++ $(GCC_TOOLCHAIN_FLAGS)

dzhidzhoev wrote:

Seemingly we don't need it anymore. I launched the testing on our CI. As soon 
as it shows that it makes no difference without -lc++abi, I'll close #99589.

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

[Lldb-commits] [lldb] [lldb] Tolerate multiple compile units with the same DWO ID (PR #100577)

[Pavel Labath via lldb-commits]

@@ -97,12 +97,14 @@ void DWARFUnit::ExtractUnitDIEIfNeeded() {
 *m_dwo_id, m_first_die.GetOffset()));
 return; // Can't fetch the compile unit from the dwo file.
   }
-  // If the skeleton compile unit gets its unit DIE parsed first, then this
-  // will fill in the DWO file's back pointer to this skeleton compile unit.
-  // If the DWO files get parsed on their own first the skeleton back link
-  // can be done manually in DWARFUnit::GetSkeletonCompileUnit() which will
-  // do a reverse lookup and cache the result.
-  dwo_cu->SetSkeletonUnit(this);
+
+  // Link the DWO unit to this object, if it hasn't been linked already (this
+  // can happen when we have an index, and the DWO unit is parsed first).
+  if (!dwo_cu->LinkToSkeletonUnit(*this)) {
+SetDwoError(Status::createWithFormat(
+"multiple compile units with Dwo ID {0:x16}", *m_dwo_id));

labath wrote:

I don't think there's an easy way to do that. The problem is that the compile 
units aren't really empty (llvm already skips empty units). They could have 
arbitrarily many type definitions (typically enums, as those can't be homed) 
inside them, so we'd have to check if that's all they contain.

I've also thought about looking at the DW_AT_ranges attribute, but that doesn't 
cover variables, so we would misclassify compile units that only define 
variables.

The upshot of all this is that since the units don't contain any code, it's 
pretty hard (maybe impossible?) to actually end up "inside" them. Therefore, 
I'm not sure if the user would ever see this kind of error, and all that 
they'll do is slightly increase the error statistics (but then again, maybe we 
want this to show up in the statistics?)

What do you think?

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

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)

[Pavel Labath via lldb-commits]

labath wrote:

My idea for anonymous namespaces was basically to treat them as optional, so 
that you could get a match (even an "exact" match maybe?) for `(anonymous 
namespace)::Foo` with a pattern `Foo`. However, if a pattern explicitly 
contained an `(anonymous namespace)`, then this would have to be present in the 
type as well (*).

The reason I'm looking into this is because we got a bug report that dynamic 
type resolution isn't working. This works by demangling the type vtable, and 
then looking up the type with the demangled name. This doesn't didn't work for 
types in anonymous namespaces.

Now that you mention functions, I see that this also wouldn't work for types 
defined in functions. However, that isn't a bridge I want to cross right now.

(*) One of the annoying things about anonymous namespaces is that they can 
appear anywhere, and even multiple times, so you can end up with types like 
`A::(anonymous namespace)::B::(anonymous namespace)::T`. This should work with 
my patch.

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

[Lldb-commits] [lldb] [lldb] Refactor TypeQuery::ContextMatches (PR #99305)

[Pavel Labath via lldb-commits]

@@ -153,19 +127,89 @@ void TypeQuery::SetLanguages(LanguageSet languages) {
 
 bool TypeQuery::ContextMatches(
 llvm::ArrayRef context_chain) const {
-  if (GetExactMatch() || context_chain.size() == m_context.size())
-return ::contextMatches(context_chain, m_context);
-
-  // We don't have an exact match, we need to bottom m_context.size() items to
-  // match for a successful lookup.
-  if (context_chain.size() < m_context.size())
-return false; // Not enough items in context_chain to allow for a match.
-
-  size_t compare_count = context_chain.size() - m_context.size();
-  return ::contextMatches(
-  llvm::ArrayRef(context_chain.data() + compare_count,
-  m_context.size()),
-  m_context);
+  auto ctx = context_chain.rbegin(), ctx_end = context_chain.rend();
+  for (auto pat = m_context.rbegin(), pat_end = m_context.rend();
+   pat != pat_end;) {
+
+// Handle AnyModule matches. These are tricky as they can match any number

labath wrote:

I'll try to create simplified version of the patch (probably tomorrow). I'd 
appreciate if you could give it a spin.

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Dmitry Vasilyev via lldb-commits]

https://github.com/slydiman updated 
https://github.com/llvm/llvm-project/pull/100670

>From 0870140c8b8d465570a696b35b59fbf55610919a Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Thu, 25 Jul 2024 00:34:34 +0400
Subject: [PATCH 1/2] [lldb] Multithreading lldb-server works on Windows now;
 fixed gdb port mapping

Removed fork(). Used threads and the common thread-safe port map for all 
platform connections.

Updated lldb::FileSystem to use llvm::vfs::createPhysicalFileSystem() with an 
own virtual working directory per thread.

This patch depends on #100659, #100666.

This patch fixes #97537, #90923, #56346.

lldb-server has been tested on Windows with 50 connections and 100 processes 
launched simultaneously. Tested also the cross build with Linux x86_64 host and 
Linux Aarch64 target.
---
 lldb/include/lldb/Host/FileSystem.h   |   7 +
 lldb/source/Host/common/FileSystem.cpp|   8 +
 lldb/source/Host/posix/PipePosix.cpp  |  12 +
 .../GDBRemoteCommunicationServerCommon.cpp|  15 +-
 .../GDBRemoteCommunicationServerPlatform.cpp  | 309 --
 .../GDBRemoteCommunicationServerPlatform.h|  31 +-
 .../tools/lldb-server/LLDBServerUtilities.cpp |   2 +
 lldb/tools/lldb-server/lldb-platform.cpp  |  99 ++
 8 files changed, 300 insertions(+), 183 deletions(-)

diff --git a/lldb/include/lldb/Host/FileSystem.h 
b/lldb/include/lldb/Host/FileSystem.h
index 640f3846e448c..5e25414a894d3 100644
--- a/lldb/include/lldb/Host/FileSystem.h
+++ b/lldb/include/lldb/Host/FileSystem.h
@@ -47,6 +47,12 @@ class FileSystem {
 
   static FileSystem &Instance();
 
+  static void InitializePerThread() {
+lldbassert(!InstancePerThread() && "Already initialized.");
+
InstancePerThread().emplace(llvm::IntrusiveRefCntPtr(
+llvm::vfs::createPhysicalFileSystem().release()));
+  }
+
   template  static void Initialize(T &&...t) {
 lldbassert(!InstanceImpl() && "Already initialized.");
 InstanceImpl().emplace(std::forward(t)...);
@@ -206,6 +212,7 @@ class FileSystem {
 
 private:
   static std::optional &InstanceImpl();
+  static std::optional &InstancePerThread();
   llvm::IntrusiveRefCntPtr m_fs;
   std::unique_ptr m_tilde_resolver;
   std::string m_home_directory;
diff --git a/lldb/source/Host/common/FileSystem.cpp 
b/lldb/source/Host/common/FileSystem.cpp
index 5153a0a9ec513..cb76086616d6b 100644
--- a/lldb/source/Host/common/FileSystem.cpp
+++ b/lldb/source/Host/common/FileSystem.cpp
@@ -49,7 +49,15 @@ void FileSystem::Terminate() {
   InstanceImpl().reset();
 }
 
+std::optional &FileSystem::InstancePerThread() {
+  static thread_local std::optional t_fs;
+  return t_fs;
+}
+
 std::optional &FileSystem::InstanceImpl() {
+  std::optional &fs = InstancePerThread();
+  if (fs)
+return fs;
   static std::optional g_fs;
   return g_fs;
 }
diff --git a/lldb/source/Host/posix/PipePosix.cpp 
b/lldb/source/Host/posix/PipePosix.cpp
index f35c348990df6..1aa02efe86610 100644
--- a/lldb/source/Host/posix/PipePosix.cpp
+++ b/lldb/source/Host/posix/PipePosix.cpp
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
 bytes_read += result;
 if (bytes_read == size || result == 0)
   break;
+
+// This is the workaround for the following bug in Linux multithreading
+// select() https://bugzilla.kernel.org/show_bug.cgi?id=546
+// ReadWithTimeout() with a non-zero timeout is used only to
+// read the port number from the gdbserver pipe
+// in GDBRemoteCommunication::StartDebugserverProcess().
+// The port number may be "1024\0".."65535\0".
+if (timeout.count() > 0 && size == 6 && bytes_read == 5 &&
+static_cast(buf)[4] == '\0') {
+  break;
+}
+
   } else if (errno == EINTR) {
 continue;
   } else {
diff --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
index f9d37490e16ae..cef836e001adf 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -646,7 +646,9 @@ GDBRemoteCommunicationServerCommon::Handle_vFile_Size(
   packet.GetHexByteString(path);
   if (!path.empty()) {
 uint64_t Size;
-if (llvm::sys::fs::file_size(path, Size))
+FileSpec file_spec(path);
+FileSystem::Instance().Resolve(file_spec);
+if (llvm::sys::fs::file_size(file_spec.GetPath(), Size))
   return SendErrorResponse(5);
 StreamString response;
 response.PutChar('F');
@@ -725,7 +727,9 @@ GDBRemoteCommunicationServerCommon::Handle_vFile_unlink(
   packet.SetFilePos(::strlen("vFile:unlink:"));
   std::string path;
   packet.GetHexByteString(path);
-  Status error(llvm::sys::fs::remove(path));
+  FileSpec file_spec(path);
+  FileSystem::Instance().Resolve(file_spec);
+  Status error(llvm::sys::fs::rem

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

I have moved this patch to #100670.

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

[Lldb-commits] [lldb] [lldb] Improved lldb-server stability for remote launching (PR #100659)

[Dmitry Vasilyev via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere requested changes to this pull request.

Please don't use environment variables to pass options to the `make` 
invocation. It makes it really hard to reproduce build failures because you 
can't just copy-paste the failing invocation to debug the build. I went through 
an effort to clean that up a few years ago. If there are other instances that 
do this then they slipped in without my knowledge. 

A similar problem applies to the `dotest.py` invocation and the 
`lldb-dotest.py` wrapper configured by CMake that a bunch of folks rely on. 

TL;DR: instead of an environment variable, please add this as an option to 
`dotest.py` and pass it explicitly as part of the `make` invocation in 
`builder.py`.

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

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

[Jonas Devlieghere via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

jimingham wrote:

> > First off, for systems that do past motion and forward motion, there are 
> > things you really can't do effectively in the past, like set variable 
> > values and have that make any difference. So we probably will need to know 
> > whether we're executing in the immutable past or the mutable present.
> 
> Fair point, but AFAIK with all these backends when you try to change state in 
> a situation where that's not allowed, you just get an error from the backend. 
> The gdbserver protocol doesn't tell you in advance whether that will be 
> possible. I don't think this impacts LLDB really, as long as you don't crash 
> when a state change fails.
> 
> > I am running "for realz", and I do a forward "next" which hits a breakpoint 
> > before the next concludes.  I step over another function at that 
> > breakpoint.  I realize I wish I had stepped into it, so I do a "reverse 
> > next" - is that how you do it - or set a breakpoint in the function and 
> > reverse continue.
> 
> FWIW rr doesn't support this workflow, but UndoDB does.
> 
> > Then I step around in the past a bit till I see what I wanted to see.  Then 
> > I'm done with the past, and want to go back to the present.  Since the last 
> > persistent action I had done was the original next, then `continue` should 
> > take up that next (going forward) and complete it.  That is all pretty 
> > straightforward, the "TheadPlanStepOverRange" - which is the current plan 
> > on the plan stack - for that next knows it's going forward, so first it 
> > pushes a "ThreadPlanTakeMeToThePresent" and when that completes, it can 
> > continue with its forward motion.
> 
> In this case, I think ThreadPlanStepOverRange will just resume with a 
> forward-continue packet. The backend continues forward through the recorded 
> history until it reaches the end of the history, i.e. the current state of 
> the stopped debuggee. Then it automatically resumes the debuggee and keeps 
> going. There is no need for a ThreadPlanTakeMeToThePresent.

It's good that that's not needed.  If it ends up being needed, it would be 
trivial to add anyway.

> 
> > So for systems that support live reverse debugging, I do think we'll need a 
> > "reset to the present" gesture, and plans will need to know whether they 
> > are operating on the past or present.
> 
> I think we'll need to have per-plan directions in some way, yes, but not 
> "reset to the present". And I don't think we need per-direction plans in this 
> PR.

Since we really are in the end going to be instructing thread plans, I think 
explicitly passing the direction to the thread plans when you make them models 
better what you are doing.  So I do prefer passing the directions as your 
current patch does than adding a global "SetDirection" method.

As it stands, this will allow "reverse continue to a breakpoint", right?  But 
once "in the past" you wouldn't be able to do either forward or reverse steps, 
you are just going to navigate by breakpoint?  I'm just asking to clarify.  
That seems like a fine first stage.

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

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

[Kendal Harland via lldb-commits]

@@ -12,6 +12,7 @@
 class MultipleSlidesTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])

kendalharland wrote:

Looks like after my CMake chages,this one is passing now.  I'll remove it from 
the PR

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

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

[Kendal Harland via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Dmitry Vasilyev via lldb-commits]

slydiman wrote:

@labath It seems we do not need qSupported and qUpgradeToGdbConnection. We can 
run
`lldb-server platform --server --listen 1234 --gdbserver-port 1235`

Option 1:
On receiving qLaunchGDBServer we can
- fork the child process to know the new pid
- send the response with the pid and port 1235
- wait for the connection on the port 1235 for 10 seconds
  - kill the child process if no connection accepted in 10 seconds
  - execve `lldb-server gdbserver --fd x` where x is fd of the accepted 
connection
We need a pipe for communication between the main `lldb-server platform` 
process and the forked child process within 10 secconds. But unfortunately this 
scenario is impossible on Windows because of fork() is missing. 

Option 2:
It seems PlatformRemoteGDBServer uses `debugserver_pid` only to kill the 
gdbserver process if connection failed. 
It seems we can just do nothing and respond `pid:0;port:1235;` to 
`qLaunchGDBServer`. Then listen the port 1235 and launch `lldb-server gdbserver 
--fd x` when a connection is accepted. `lldb-server gdbserver` must exit if the 
connection x is closed.

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

[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

[Greg Clayton via lldb-commits]

clayborg wrote:

ok, I will break this up to make it easier to review.

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

https://github.com/YungRaj created 
https://github.com/llvm/llvm-project/pull/101062

This is a dummy pull request to demonstrate the changes I made in to get 
symbolication working using JSON Object/Symbol files

https://discourse.llvm.org/t/lldb-support-renaming-symbols-by-address-using-a-symbol-file-provided-by-json-or-other-formatted-data-to-assist-reverse-engineering-e-g-protobuf-plist-xml-etc/80355/8


>From 47af2b7229eaa6712fe5812e3d4dbea44bbb212b Mon Sep 17 00:00:00 2001
From: Ilhan Raja 
Date: Mon, 29 Jul 2024 11:43:47 -0700
Subject: [PATCH] ObjectFileJSON and Section changes to support section.address
 field in JSON object symmbol files

---
 lldb/source/Core/Section.cpp   | 2 +-
 lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f..f138d62fb356d 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -685,7 +685,7 @@ bool fromJSON(const llvm::json::Value &value,
   lldb_private::JSONSection §ion, llvm::json::Path path) {
   llvm::json::ObjectMapper o(value, path);
   return o && o.map("name", section.name) && o.map("type", section.type) &&
- o.map("size", section.address) && o.map("size", section.size);
+ o.map("address", section.address) && o.map("size", section.size);
 }
 
 bool fromJSON(const llvm::json::Value &value, lldb::SectionType &type,
diff --git a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp 
b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
index ffbd87714242c..0ee827355f060 100644
--- a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
+++ b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
@@ -183,7 +183,7 @@ void ObjectFileJSON::CreateSections(SectionList 
&unified_section_list) {
   for (const auto §ion : m_sections) {
 auto section_sp = std::make_shared(
 GetModule(), this, id++, ConstString(section.name),
-section.type.value_or(eSectionTypeCode), 0, section.size.value_or(0), 
0,
+section.type.value_or(eSectionTypeCode), section.address.value_or(0), 
section.size.value_or(0), 0,
 section.size.value_or(0), /*log2align*/ 0, /*flags*/ 0);
 m_sections_up->AddSection(section_sp);
 unified_section_list.AddSection(section_sp);

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[via lldb-commits]

github-actions[bot] wrote:



Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this 
page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using `@` followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from 
other developers.

If you have further questions, they may be answered by the [LLVM GitHub User 
Guide](https://llvm.org/docs/GitHub.html).

You can also ask questions in a comment on this PR, on the [LLVM 
Discord](https://discord.com/invite/xS7Z362) or on the 
[forums](https://discourse.llvm.org/).

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Ilhan Raja (YungRaj)


Changes

This is a dummy pull request to demonstrate the changes I made in to get 
symbolication working using JSON Object/Symbol files

https://discourse.llvm.org/t/lldb-support-renaming-symbols-by-address-using-a-symbol-file-provided-by-json-or-other-formatted-data-to-assist-reverse-engineering-e-g-protobuf-plist-xml-etc/80355/8


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


2 Files Affected:

- (modified) lldb/source/Core/Section.cpp (+1-1) 
- (modified) lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp (+1-1) 


``diff
diff --git a/lldb/source/Core/Section.cpp b/lldb/source/Core/Section.cpp
index 0763e88d4608f..f138d62fb356d 100644
--- a/lldb/source/Core/Section.cpp
+++ b/lldb/source/Core/Section.cpp
@@ -685,7 +685,7 @@ bool fromJSON(const llvm::json::Value &value,
   lldb_private::JSONSection §ion, llvm::json::Path path) {
   llvm::json::ObjectMapper o(value, path);
   return o && o.map("name", section.name) && o.map("type", section.type) &&
- o.map("size", section.address) && o.map("size", section.size);
+ o.map("address", section.address) && o.map("size", section.size);
 }
 
 bool fromJSON(const llvm::json::Value &value, lldb::SectionType &type,
diff --git a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp 
b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
index ffbd87714242c..0ee827355f060 100644
--- a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
+++ b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
@@ -183,7 +183,7 @@ void ObjectFileJSON::CreateSections(SectionList 
&unified_section_list) {
   for (const auto §ion : m_sections) {
 auto section_sp = std::make_shared(
 GetModule(), this, id++, ConstString(section.name),
-section.type.value_or(eSectionTypeCode), 0, section.size.value_or(0), 
0,
+section.type.value_or(eSectionTypeCode), section.address.value_or(0), 
section.size.value_or(0), 0,
 section.size.value_or(0), /*log2align*/ 0, /*flags*/ 0);
 m_sections_up->AddSection(section_sp);
 unified_section_list.AddSection(section_sp);

``




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

[Lldb-commits] [lldb] [LLDB] Improve ObjectFileELF files ability to load from memory. (PR #100900)

[Fangrui Song via lldb-commits]

MaskRay wrote:

> I like this idea a lot, but I have some reservations about the implementation.
> 
> For one, I think this patch is too big. I once heard someone say "if you have 
> bullet points in your patch description, then the patch is doing too much". 
> While I don't think we should go as far as to create a separate PR for each 
> of your bullet points, I do believe that splitting it up into a couple of 
> pieces would go along way towards making it easier to review.
> 
> I also see that some of the functionality is guarded by `IsInMemory()`, which 
> doesn't sounds like the right thing to do, as the we should in principle be 
> able to use the same code for parsing parsing section-header-less object 
> files on disk. These aren't exactly common, but like @MaskRay said, section 
> headers aren't strictly needed for linked object files, and it's much easier 
> to make test using these.
> 
> Finally, I think that structuring some of this code as "fallback" is not 
> ideal, as it can cause some data can be parsed twice (I think it happens at 
> least with ELF notes in this patch). Even if that's innocuous , I don't think 
> it's right because the two mechanisms (program and section headers) are just 
> different ways of finding the same data. I think it'd be cleaner if this was 
> implemented as a two-step process:
> 
> 1. find the data (e.g., notes): This will look into section and program 
> headers to find the appropriate bytes (I might even argue it should look at 
> program headers first, as that's what the operating system will use)
> 2. use the data (regardless of where it comes from)
> 
> I realise this feedback isn't very specific, but that's because I found it 
> very hard to follow everything that's going on in this patch. I'm sure I'll 
> be able to be more specific on the partial patches (and maybe some of my 
> assumptions will turn out to be incorrect). As a first patch in the series, 
> I'd recommend teaching lldb to parse section-header-less object files. Right 
> now, if I run lldb on such a file, it will tell me that it's empty (has zero 
> sections). Making the program headers visible would lay the foundation for 
> other changes, and it would also be the smallest testable piece of 
> functionality (by dumping the section list).
> 
> @MaskRay can you recommend a good to create these kinds of files? I was 
> thinking of a combination `yaml2obj` + `llvm-objcopy --strip-sections` 
> (because IIRC yaml2obj always inserts some sections into the output), but 
> maybe there's something better (?)

yaml2obj omits the section header table when `NoHeaders: true` is specified.
```
  - Type: SectionHeaderTable
NoHeaders: true
```

However, obj2yaml doesn't create `NoHeaders: true` yet. 

If the test utilizes `ld.lld`, `llvm-objcopy --strip-sections` will be needed. 
GNU ld 2.41 supports `-z nosectionheader`, which lld doesn't support yet (if 
there is enough interest I can add it).

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

[Lldb-commits] [lldb] [lldb][test] Add ABI library to Makefile.rules link flags (PR #99589)

[Vladislav Dzhidzhoev via lldb-commits]

dzhidzhoev wrote:

Closed since another libcxx linking method is used 
https://github.com/llvm/llvm-project/pull/99266#discussion_r1693409524.

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

[Lldb-commits] [lldb] [lldb][test] Add ABI library to Makefile.rules link flags (PR #99589)

[Vladislav Dzhidzhoev via lldb-commits]

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB][test] Provide a proper path to 'strip' utility for the LLDB API tests. (PR #100836)

[Vladislav Dzhidzhoev via lldb-commits]

dzhidzhoev wrote:

> Please don't use environment variables to pass options to the `make` 
> invocation. It makes it really hard to reproduce build failures because you 
> can't just copy-paste the failing invocation to debug the build. I went 
> through an effort to clean that up a few years ago. If there are other 
> instances that do this then they slipped in without my knowledge.
> 
> A similar problem applies to the `dotest.py` invocation and the 
> `lldb-dotest.py` wrapper configured by CMake that a bunch of folks rely on.
> 
> TL;DR: instead of an environment variable, please add this as an option to 
> `dotest.py` and pass it explicitly as part of the `make` invocation in 
> `builder.py`. You can look at `dsymutil` for inspiration.

Thank you!



> This seems fine, but what happens currently? Does it try to use a tool that's 
> built for the remote not the host?

Currently, it's not found on Windows and I see a couple of tests that are 
disabled because of that (e.g. 
https://github.com/llvm/llvm-project/blob/7b99b1d4f733ed5e1b206f0b392b0864e7a0d468/lldb/test/API/functionalities/json/symbol-file/TestSymbolFileJSON.py#L16).
 Yes, it can be installed externally added to PATH. But also llvm-strip from 
LLVM_TOOLS_BINARY_DIR can be utilized to reduce dependencies.

I'll try the solution proposed by @labath and replace strip usage with objcopy. 

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

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[Robert O'Callahan via lldb-commits]

rocallahan wrote:

> As it stands, this will allow "reverse continue to a breakpoint", right?

Using rr as the backend you can reverse-continue to any stop, including 
signals, watchpoints and the "history boundary" i.e. start of time. I expect 
the other stop types don't work well yet. I plan to work on them next. We can 
delay adding the CLI for reverse-continue until they work adequately.

> But once "in the past" you wouldn't be able to do either forward or reverse 
> steps, you are just going to navigate by breakpoint?

After reverse-continue you can do any kind of forward execution you want. With 
LLDB + rr, you're always "in the past" since during debugging rr always/only 
navigates history; when you're at a certain point in time the state of LLDB and 
rr is independent of whether you got there by forward or reverse execution. And 
LLDB + rr is pretty much fully functional already --- except for the absence of 
reverse-execution commands.

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

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

jimingham wrote:



> On Jul 29, 2024, at 1:06 PM, rocallahan ***@***.***> wrote:
> 
> 
> As it stands, this will allow "reverse continue to a breakpoint", right?
> 
> Using rr as the backend you can reverse-continue to any stop, including 
> signals, watchpoints and the "history boundary" i.e. start of time. I expect 
> the other stop types don't work well yet. I plan to work on them next. We can 
> delay adding the CLI for reverse-continue until they work adequately.
> 
> But once "in the past" you wouldn't be able to do either forward or reverse 
> steps, you are just going to navigate by breakpoint?
> 
> After reverse-continue you can do any kind of forward execution you want. 
> With LLDB + rr, you're always "in the past" since during debugging rr 
> always/only navigates history; when you're at a certain point in time the 
> state of LLDB and rr is independent of whether you got there by forward or 
> reverse execution. And LLDB + rr is pretty much fully functional already --- 
> except for the absence of reverse-execution commands.
> 
Is there a notion of "reverse stepping" like "take me to the line that preceded 
this one in execution history", and if so what contains the logic that does 
that?

Jim


> —
> 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/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

The change itself looks good modulo formatting. Can you please update one of 
the existing tests to cover this use case? 

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

[Lldb-commits] [lldb] [llvm] [Draft][LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Jacob Lalonde via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Jacob Lalonde via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-llvm-binary-utilities

Author: Jacob Lalonde (Jlalond)


Changes

This PR is in response to a bug my coworker @mbucko discovered where on 
MacOS Minidumps were being created where the 64b memory regions were readable, 
but were not being listed in `SBProcess.GetMemoryRegionList()`. This went 
unnoticed in !95312 due to all the linux testing including /proc/pid maps. On 
MacOS generated dumps (or any dump without access to /proc/pid) we would fail 
to properly map Memory Regions due to there being two independent methods for 
32b and 64b mapping.

In this PR I addressed this minor bug and merged the methods, but in order to 
add test coverage required additions to `obj2yaml` and `yaml2obj` which make up 
the bulk of this patch.

Lastly, there are some non-required changes such as the addition of the 
`Memory64ListHeader` type, to make writing/reading the header section of the 
Memory64List easier.

---

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


11 Files Affected:

- (modified) lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
(+8-5) 
- (modified) lldb/source/Plugins/Process/minidump/MinidumpParser.cpp (+29-29) 
- (modified) 
lldb/test/API/functionalities/postmortem/minidump-new/TestMiniDumpNew.py (+13) 
- (added) 
lldb/test/API/functionalities/postmortem/minidump-new/linux-x86_64_mem64.dmp () 
- (added) 
lldb/test/API/functionalities/postmortem/minidump-new/linux-x86_64_mem64.yaml 
(+36) 
- (modified) llvm/include/llvm/BinaryFormat/Minidump.h (+12) 
- (modified) llvm/include/llvm/Object/Minidump.h (+13-3) 
- (modified) llvm/include/llvm/ObjectYAML/MinidumpYAML.h (+28) 
- (modified) llvm/lib/Object/Minidump.cpp (+17-2) 
- (modified) llvm/lib/ObjectYAML/MinidumpEmitter.cpp (+11) 
- (modified) llvm/lib/ObjectYAML/MinidumpYAML.cpp (+34) 


``diff
diff --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index de212c6b20da7..b941748bd7ccb 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -1020,15 +1020,17 @@ 
MinidumpFileBuilder::AddMemoryList_32(Process::CoreFileMemoryRanges &ranges) {
   // With a size of the number of ranges as a 32 bit num
   // And then the size of all the ranges
   error = AddDirectory(StreamType::MemoryList,
-   sizeof(llvm::support::ulittle32_t) +
+   sizeof(llvm::minidump::MemoryListHeader) +
descriptors.size() *
sizeof(llvm::minidump::MemoryDescriptor));
   if (error.Fail())
 return error;
 
+  llvm::minidump::MemoryListHeader list_header;
   llvm::support::ulittle32_t memory_ranges_num =
   static_cast(descriptors.size());
-  m_data.AppendData(&memory_ranges_num, sizeof(llvm::support::ulittle32_t));
+  list_header.NumberOfMemoryRanges = memory_ranges_num;
+  m_data.AppendData(&list_header, sizeof(llvm::minidump::MemoryListHeader));
   // For 32b we can get away with writing off the descriptors after the data.
   // This means no cleanup loop needed.
   m_data.AppendData(descriptors.data(),
@@ -1050,9 +1052,10 @@ 
MinidumpFileBuilder::AddMemoryList_64(Process::CoreFileMemoryRanges &ranges) {
   if (error.Fail())
 return error;
 
+  llvm::minidump::Memory64ListHeader list_header;
   llvm::support::ulittle64_t memory_ranges_num =
   static_cast(ranges.size());
-  m_data.AppendData(&memory_ranges_num, sizeof(llvm::support::ulittle64_t));
+  list_header.NumberOfMemoryRanges = memory_ranges_num;
   // Capture the starting offset for all the descriptors so we can clean them 
up
   // if needed.
   offset_t starting_offset =
@@ -1064,8 +1067,8 @@ 
MinidumpFileBuilder::AddMemoryList_64(Process::CoreFileMemoryRanges &ranges) {
   (ranges.size() * sizeof(llvm::minidump::MemoryDescriptor_64));
   llvm::support::ulittle64_t memory_ranges_base_rva =
   static_cast(base_rva);
-  m_data.AppendData(&memory_ranges_base_rva,
-sizeof(llvm::support::ulittle64_t));
+  list_header.BaseRVA = memory_ranges_base_rva;
+  m_data.AppendData(&list_header, sizeof(llvm::minidump::Memory64ListHeader));
 
   bool cleanup_required = false;
   std::vector descriptors;
diff --git a/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp 
b/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
index be9fae938e227..7e19acd3d0834 100644
--- a/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
+++ b/lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
@@ -553,43 +553,45 @@ static bool
 CreateRegionsCacheFromMemoryList(MinidumpParser &parser,
  std::vector ®ions) {
   Log *log = GetLog(LLDBLog::Modules);
+  // Cache the expected memory32 into an optional
+  // because double checking the expected triggers the unchecked w

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[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 6dba99e14f7e508a5028036b753fa7f84e846307 
47af2b7229eaa6712fe5812e3d4dbea44bbb212b --extensions cpp -- 
lldb/source/Core/Section.cpp 
lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp 
b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
index 0ee827355f..33b9f85cc3 100644
--- a/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
+++ b/lldb/source/Plugins/ObjectFile/JSON/ObjectFileJSON.cpp
@@ -183,8 +183,9 @@ void ObjectFileJSON::CreateSections(SectionList 
&unified_section_list) {
   for (const auto §ion : m_sections) {
 auto section_sp = std::make_shared(
 GetModule(), this, id++, ConstString(section.name),
-section.type.value_or(eSectionTypeCode), section.address.value_or(0), 
section.size.value_or(0), 0,
-section.size.value_or(0), /*log2align*/ 0, /*flags*/ 0);
+section.type.value_or(eSectionTypeCode), section.address.value_or(0),
+section.size.value_or(0), 0, section.size.value_or(0), /*log2align*/ 0,
+/*flags*/ 0);
 m_sections_up->AddSection(section_sp);
 unified_section_list.AddSection(section_sp);
   }

``




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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

YungRaj wrote:

> The change itself looks good modulo formatting. Can you please update one of 
> the existing tests to cover this use case?

This doesn't get symbolication fully working. We still need to prevent the 
object file from being read when inspecting the symbolicated addresses through 
disassembly of instructions or by reading the contents of that memory.

I can fix all the unit tests once we get the ball fully rolled there. What are 
your recommendations for getting that working? Is that an issue with 
`Target::ReadMemory()` and the such?

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

This patch fixes the deserialization of the "address" field which surely can be 
tested in isolation. The existing test (`TestObjectFileJSON.py`) has `address` 
set to zero, which is why this happens to work today. It should be possible to 
either update the test or add a new one that has a non-zero section address, 
which would fail prior to this patch, but pass with it. 

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

YungRaj wrote:

> This patch fixes the deserialization of the "address" field which surely can 
> be tested in isolation. The existing test (`TestObjectFileJSON.py`) has 
> `address` set to zero, which is why this happens to work today. It should be 
> possible to either update the test or add a new one that has a non-zero 
> section address, which would fail prior to this patch, but pass with it.

I was hoping to fix everything in one Pull Request so that it at least becomes 
usable once this merges. I can handle the unit test changes, but I'm unsure how 
to fix the other memory reading issue while debugging the target. I describe it 
in brief on that other comment.

Basically reading the memory of the symbolicated address reads from the JSON 
Object File instead of the live memory.

```
ilhanraja@ilhanrajas-Virtual-Machine build % bin/lldb
(lldb) target create /Users/ilhanraja/Downloads/symbols.json 
Current executable set to '/Users/ilhanraja/Downloads/symbols.json' (arm64e).
(lldb) gdb-remote 10.11.1.2:4000
Kernel UUID: 894FC3F0-4DF9-3A70-A4EE-75646151C8A7
Load Address: 0xfff00700c000
Process 1 stopped
* thread #1, stop reason = signal SIGINT
frame #0: 0xfff007d56080
error: 0x can't be resolved
(lldb) bt
* thread #1, stop reason = signal SIGINT
  * frame #0: 0xfff007d56080
frame #1: 0xfff007ecafe8
frame #2: 0xfff007dc2d50
frame #3: 0xfff007dc2fb8
(lldb) image lookup -r -s ipc
74 symbols match the regular expression 'ipc' in 
/Users/ilhanraja/Downloads/symbols.json:
Address: symbols.json[0xfff007d62124] 
(symbols.json.com.apple.kernel:__text + 106788)
Summary: symbols.json`ipc_hash_delete
Address: symbols.json[0xfff007d6264c] 
(symbols.json.com.apple.kernel:__text + 108108)
Summary: symbols.json`ipc_importance_task_check_transition
Address: symbols.json[0xfff007d62774] 
(symbols.json.com.apple.kernel:__text + 108404)
Summary: symbols.json`ipc_importance_task_propagate_assertion_locked
Address: symbols.json[0xfff007d66b80] 
(symbols.json.com.apple.kernel:__text + 125824)
Summary: symbols.json`ipc_kmsg_alloc
Address: symbols.json[0xfff007d66e30] 
(symbols.json.com.apple.kernel:__text + 126512)
Summary: symbols.json`ipc_kmsg_alloc_uext_reply
Address: symbols.json[0xfff007d671c4] 
(symbols.json.com.apple.kernel:__text + 127428)
Summary: symbols.json`ipc_kmsg_enqueue_qos
Address: symbols.json[0xfff007d675f8] 
(symbols.json.com.apple.kernel:__text + 128504)
Summary: symbols.json`ipc_kmsg_clean_body
Address: symbols.json[0xfff007d6af48] 
(symbols.json.com.apple.kernel:__text + 143176)
Summary: symbols.json`_ipc_kmsg_option_check
Address: symbols.json[0xfff007d6b0fc] 
(symbols.json.com.apple.kernel:__text + 143612)
Summary: symbols.json`ipc_kmsg_validate_reply_port_locked
Address: symbols.json[0xfff007d6bf78] 
(symbols.json.com.apple.kernel:__text + 147320)
Summary: symbols.json`ipc_kmsg_link_reply_context_locked
Address: symbols.json[0xfff007d6cf5c] 
(symbols.json.com.apple.kernel:__text + 151388)
Summary: symbols.json`ipc_kmsg_get_thread_group
Address: symbols.json[0xfff007d6e65c] 
(symbols.json.com.apple.kernel:__text + 157276)
Summary: symbols.json`ipc_mqueue_destroy_locked
Address: symbols.json[0xfff007d6e6fc] 
(symbols.json.com.apple.kernel:__text + 157436)
Summary: symbols.json`ipc_mqueue_set_qlimit_locked
Address: symbols.json[0xfff007d6e87c] 
(symbols.json.com.apple.kernel:__text + 157820)
Summary: symbols.json`ipc_notify_port_deleted
Address: symbols.json[0xfff007d6e8e0] 
(symbols.json.com.apple.kernel:__text + 157920)
Summary: symbols.json`ipc_notify_no_senders_prepare
Address: symbols.json[0xfff007d6ea50] 
(symbols.json.com.apple.kernel:__text + 158288)
Summary: symbols.json`ipc_notify_send_once_and_unlock
Address: symbols.json[0xfff007d6eb6c] 
(symbols.json.com.apple.kernel:__text + 158572)
Summary: symbols.json`ipc_object_deallocate_queue_invoke
Address: symbols.json[0xfff007d6ec7c] 
(symbols.json.com.apple.kernel:__text + 158844)
Summary: symbols.json`ipc_object_release
Address: symbols.json[0xfff007d6f300] 
(symbols.json.com.apple.kernel:__text + 160512)
Summary: symbols.json`ipc_object_alloc
Address: symbols.json[0xfff007d6f400] 
(symbols.json.com.apple.kernel:__text + 160768)
Summary: symbols.json`ipc_object_alloc_name
Address: symbols.json[0xfff007d70844] 
(symbols.json.com.apple.kernel:__text + 165956)
Summary: symbols.json`ipc_object_lock_allow_invalid
Address: symbols.json[0xfff007d70970] 
(symbols.json.com.apple.kernel:__text + 166256)
Summary: symbols.json`ipc_port_reference
Address: symbols.

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

[Kendal Harland via lldb-commits]

@@ -12,6 +12,7 @@
 class MultipleSlidesTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
+@expectedFailureAll(oslist=["windows"], archs=["x86_64"])

kendalharland wrote:

Ah, sorry I spoke too soon. On windows I am seeing this fail. The test is built 
without debug information because this is in it's makefile:

```
C_SOURCES := main.c
MAKE_DSYM := NO

include Makefile.rules

main.o: main.c
$(CC) $(CFLAGS_NO_DEBUG) -c $< -o $@
```

I am curious to know how this is passing for you? Without specifying `-g` or 
`-gdwarf` to Clang, lldb cannot resolve the name `first` and fails for me 
locally. But adding either of those flags fixes the problem.

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

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

[Kendal Harland via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][test][win][x86_64] Fix XFAIL and XPASS on LLDB API tests (PR #100477)

[Kendal Harland via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Jacob Lalonde via lldb-commits]

Jlalond wrote:

@labath Would you mind if I added you as a reviewer for the `Obj2Yaml` changes 
for minidump?

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Jacob Lalonde via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[Robert O'Callahan via lldb-commits]

rocallahan wrote:

> Is there a notion of "reverse stepping" like "take me to the line that 
> preceded this one in execution history", and if so what contains the logic 
> that does that?

rr supports the "bs" gdbserver packet to reverse-step a single instruction (and 
so does the test proxy I'm adding here). To "reverse-next one line" we will 
need to implement a thread plan that uses a combination of 
reverse-step-instruction and reverse-continue-to-breakpoint. That's future 
work. It may be difficult, and it's also not very high priority because it 
tends not to get used very much by gdb users.

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

[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #99736)

[via lldb-commits]

jimingham wrote:



> On Jul 29, 2024, at 3:16 PM, rocallahan ***@***.***> wrote:
> 
> 
> Is there a notion of "reverse stepping" like "take me to the line that 
> preceded this one in execution history", and if so what contains the logic 
> that does that?
> 
> rr supports the "bs" gdbserver packet to reverse-step a single instruction 
> (and so does the test proxy I'm adding here). To "reverse-next one line" we 
> will need to implement a thread plan that uses a combination of 
> reverse-step-instruction and reverse-continue-to-breakpoint. That's future 
> work. It may be difficult, and it's also not very high priority because it 
> tends not to get used very much by gdb users.
> 
I guessed that was the case.  We should still try to do something here, 
tbreak/reverse continue probably gets old over time, but that seems fine to 
leave for "future work".

Jim


> —
> 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/99736
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Greg Clayton via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Greg Clayton via lldb-commits]

@@ -104,6 +105,25 @@ using ModuleListStream = 
detail::ListStream;
 using ThreadListStream = detail::ListStream;
 using MemoryListStream = detail::ListStream;
 
+/// Memory64ListStream minidump stream.
+struct Memory64ListStream : public Stream {
+  std::vector Entries;
+  yaml::BinaryRef Content;
+  minidump::Memory64ListHeader Header;

clayborg wrote:

move this up two lines to appear before `Entries`?

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Greg Clayton via lldb-commits]

https://github.com/clayborg requested changes to this pull request.

There must be some minidump yaml tests somewhere. We should add some to test 
the YAML support. Also need to test for multiple MemoryDescriptor_64 entries in 
a file using your new YAML.

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Greg Clayton via lldb-commits]

@@ -154,3 +155,17 @@ MinidumpFile::create(MemoryBufferRef Source) {
   return std::unique_ptr(
   new MinidumpFile(Source, Hdr, *ExpectedStreams, std::move(StreamMap)));
 }
+
+Expected> MinidumpFile::getMemory64List() const {
+  Expected MemoryList64 = 
getMemoryList64Header();
+  if (!MemoryList64)
+return MemoryList64.takeError();
+
+  std::optional> Stream =
+  getRawStream(StreamType::Memory64List);
+  if (!Stream)
+return createError("No such stream");
+
+  return getDataSliceAs(
+  *Stream, sizeof(Memory64ListHeader), MemoryList64->NumberOfMemoryRanges);
+}

clayborg wrote:

The 32 bit memory list just does:
```
  Expected> getMemoryList() const {
return getListStream(
minidump::StreamType::MemoryList);
  }
```
Should this be the same kind of thing:
```
  Expected> getMemoryList64() const {
return getListStream< minidump::MemoryDescriptor_64>(
minidump::StreamType::MemoryList_64);
  }
```

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

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Fix ProcessMinidump::GetMemoryRegions to include 64b regions when /proc/pid maps are missing. (PR #101086)

[Greg Clayton via lldb-commits]

@@ -154,3 +155,17 @@ MinidumpFile::create(MemoryBufferRef Source) {
   return std::unique_ptr(
   new MinidumpFile(Source, Hdr, *ExpectedStreams, std::move(StreamMap)));
 }
+
+Expected> MinidumpFile::getMemory64List() const {
+  Expected MemoryList64 = 
getMemoryList64Header();
+  if (!MemoryList64)
+return MemoryList64.takeError();
+
+  std::optional> Stream =
+  getRawStream(StreamType::Memory64List);
+  if (!Stream)
+return createError("No such stream");
+
+  return getDataSliceAs(

clayborg wrote:

This gets just a single memory descriptor and it needs to be an array. There 
should be a test for this to ensure we can load multiple 64 bit ranges where 
you use your YAML to produce a small core file with only a few memory ranges 
that are in the MemoryDescriptor_64 formats and verify we can read the data.

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

[Lldb-commits] [lldb] ObjectFileJSON and Section changes to support section.address field i… (PR #101062)

[Ilhan Raja via lldb-commits]

YungRaj wrote:

I got it working.

But symbolicating backtraces is still broken. Setting breakpoints by address, 
reading memory, disassembling memory, etc is now working.

https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/lldb/source/Core/Section.cpp#L229


In `Section::GetBaseLoadAddress()`, the default return value is` 
LLDB_INVALID_ADDRESS`, but should only be the default return value if the 
current segment's FileAddress() is invalid, in which case with the 
`symbols.json` value it is not.

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

[Lldb-commits] [lldb] 6bd5fd3 - [lldb] Reland 2402b3213c2f with `-H -MM` to debug the windows build issue

[Med Ismail Bennani via lldb-commits]

Author: Med Ismail Bennani
Date: 2024-07-29T20:51:49-07:00
New Revision: 6bd5fd35063cd14b0a56bc6f7fb1e7b6e1ac56d5

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

LOG: [lldb] Reland 2402b3213c2f with `-H -MM` to debug the windows build issue

This patch relands 2402b3213c2f to investigate the ambigious typedef
issue happening on the windows bots:

https://lab.llvm.org/buildbot/#/builders/141/builds/1175/

However this patch adds the `-H` & `-MM` compiler flags when building
the ScriptedProcessPythonInterface library to be able to investigate the
include order issue.

This patch will be revert after 1 failing run on the windows bot.

Signed-off-by: Med Ismail Bennani 

Added: 

lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt

lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp

lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.h

Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 

lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.cpp

lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.h



diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt
index 8c7e92bead32c..4d9627964d4cd 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/CMakeLists.txt
@@ -21,7 +21,6 @@ endif()
 
 add_lldb_library(lldbPluginScriptInterpreterPythonInterfaces
   ScriptedPythonInterface.cpp
-  ScriptedProcessPythonInterface.cpp
   ScriptedThreadPythonInterface.cpp
 
   LINK_LIBS
@@ -38,5 +37,9 @@ add_lldb_library(lldbPluginScriptInterpreterPythonInterfaces
 
 add_subdirectory(OperatingSystemPythonInterface)
 add_subdirectory(ScriptedPlatformPythonInterface)
+set(ORIGINAL_CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
+set(CMAKE_CXX_FLAGS "${ORIGINAL_CMAKE_CXX_FLAGS} -H -MM")
+add_subdirectory(ScriptedProcessPythonInterface)
+set(CMAKE_CXX_FLAGS "${ORIGINAL_CMAKE_CXX_FLAGS}")
 add_subdirectory(ScriptedThreadPlanPythonInterface)
 

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt
new file mode 100644
index 0..66ed041853f67
--- /dev/null
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt
@@ -0,0 +1,16 @@
+add_lldb_library(lldbPluginScriptInterpreterPythonScriptedProcessPythonInterface
 PLUGIN
+
+  ScriptedProcessPythonInterface.cpp
+
+  LINK_LIBS
+lldbCore
+lldbHost
+lldbInterpreter
+lldbTarget
+lldbPluginScriptInterpreterPython
+${Python3_LIBRARIES}
+${LLDB_LIBEDIT_LIBS}
+
+  LINK_COMPONENTS
+Support
+  )

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.cpp
 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp
similarity index 85%
rename from 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.cpp
rename to 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp
index 313c597ce48f3..f4fba0848fe27 100644
--- 
a/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface.cpp
+++ 
b/lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/ScriptedProcessPythonInterface.cpp
@@ -6,11 +6,8 @@
 //
 
//===--===//
 
+#include "lldb/Core/PluginManager.h"
 #include "lldb/Host/Config.h"
-#if LLDB_ENABLE_PYTHON
-// LLDB Python header must be included first
-#include "../lldb-python.h"
-#endif
 #include "lldb/Target/Process.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/Status.h"
@@ -18,10 +15,16 @@
 
 #if LLDB_ENABLE_PYTHON
 
-#include "../SWIGPythonBridge.h"
-#include "../ScriptInterpreterPythonImpl.h"
+// clang-format off
+// LLDB Python header must be included first
+#include "../../lldb-python.h"
+//clang-format on
+
+#include "../../SWIGPythonBridge.h"
+#include "../../ScriptInterpreterPythonImpl.h"
+#include "../ScriptedThreadPythonInterface.h"
 #include "ScriptedProcessPythonInterface.h"
-#include "ScriptedThre