date:20240808

[Lldb-commits] [lldb] [lldb/Interpreter] Fix ambiguous partial command resolution (PR #101934)

2024-08-08 Thread Med Ismail Bennani via lldb-commits


https://github.com/medismailben updated 
https://github.com/llvm/llvm-project/pull/101934

>From b2061b3d60ceb43b8bbd57dd4fb56eacd834d644 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Thu, 8 Aug 2024 00:45:54 -0700
Subject: [PATCH] [lldb/Interpreter] Fix ambiguous partial command resolution

This patch is a follow-up to #97263 that fix ambigous abbreviated
command resolution.

When multiple commands are resolved, instead of failing to pick a command to
run, this patch changes to resolution logic to check if there is a single
alias match and if so, it will run the alias instead of the other matches.

This has as a side-effect that we don't need to make aliases for every
substring of aliases to support abbrivated alias resolution.

Signed-off-by: Med Ismail Bennani 
---
 lldb/docs/use/tutorial.rst|  4 +
 .../lldb/Interpreter/CommandInterpreter.h |  4 +
 .../source/Commands/CommandObjectCommands.cpp |  8 +-
 .../source/Interpreter/CommandInterpreter.cpp | 84 ++-
 .../TestAmbiguousCommands.py  | 35 
 .../ambigous_commands/categories  |  1 +
 6 files changed, 116 insertions(+), 20 deletions(-)
 create mode 100644 
lldb/test/API/functionalities/ambigous_commands/TestAmbiguousCommands.py
 create mode 100644 lldb/test/API/functionalities/ambigous_commands/categories

diff --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst
index 22354c6720e14a..00e7befdd087a4 100644
--- a/lldb/docs/use/tutorial.rst
+++ b/lldb/docs/use/tutorial.rst
@@ -168,6 +168,10 @@ is more convenient to make the basic commands unique down 
to a letter or two,
 and then learn these sequences than to fill the namespace with lots of aliases,
 and then have to type them all the way out.
 
+If the alias abbreviation or the full alias command collides with another
+existing command, the command resolver will prefer to use the alias over any
+other command as far as there is only one alias command match.
+
 However, users are free to customize LLDB's command set however they like, and
 since LLDB reads the file ``~/.lldbinit`` at startup, you can store all your
 aliases there and they will be generally available to you. Your aliases are
diff --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 48f6618ab0e392..2bafc30cc8e23a 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -295,6 +295,10 @@ class CommandInterpreter : public Broadcaster,
   StringList *matches = nullptr,
   StringList *descriptions = nullptr) 
const;
 
+  CommandObject *
+  GetAliasCommandObject(llvm::StringRef cmd, StringList *matches = nullptr,
+StringList *descriptions = nullptr) const;
+
   /// Determine whether a root level, built-in command with this name exists.
   bool CommandExists(llvm::StringRef cmd) const;
 
diff --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index c63445b7c8c868..7c439f4ddb93e3 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -322,7 +322,13 @@ rather than using a positional placeholder:"
 
 (lldb) command alias bl3 breakpoint set -f %1 -l 3
 
-Always sets a breakpoint on line 3 of whatever file is indicated.)");
+Always sets a breakpoint on line 3 of whatever file is indicated.
+
+)"
+
+"If the alias abbreviation or the full alias command collides with 
another \
+existing command, the command resolver will prefer to use the alias over any \
+other command as far as there is only one alias command match.");
 
 CommandArgumentEntry arg1;
 CommandArgumentEntry arg2;
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index fc07168b6c0ac1..f3cabbd28e976e 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -520,10 +520,6 @@ void CommandInterpreter::Initialize() {
 
   cmd_obj_sp = GetCommandSPExact("scripting run");
   if (cmd_obj_sp) {
-AddAlias("sc", cmd_obj_sp);
-AddAlias("scr", cmd_obj_sp);
-AddAlias("scri", cmd_obj_sp);
-AddAlias("scrip", cmd_obj_sp);
 AddAlias("script", cmd_obj_sp);
   }
 
@@ -1302,6 +1298,39 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
   return {};
 }
 
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+  auto find_exact =
+  [&](const CommandObject::CommandMap &map) -> CommandObject * {
+auto found_elem = map.find(cmd.str());
+if (found_elem == map.end())
+  return (CommandObject *)nullptr;
+CommandObject *exact_cmd = found_elem->second.get();
+if (!exact_cmd)
+  return nullptr;
+
+if

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits


https://github.com/labath commented:

We're pretty close, but I still some comments and question. None of them should 
be major, I hope.

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits


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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -494,6 +528,23 @@ Stream::create(const Directory &StreamDesc, const 
object::MinidumpFile &File) {
 }
 return std::make_unique(std::move(Ranges));
   }
+  case StreamKind::Memory64List: {
+Error Err = Error::success();
+auto Memory64List = File.getMemory64List(Err);
+if (Err)
+  return Err;
+std::vector Ranges;
+for (const auto &Pair : Memory64List) {
+  Ranges.push_back({Pair.first, Pair.second});
+}
+
+// If we don't have an error, or if any of the reads succeed, return ranges
+// this would also work if we have no descriptors.
+if (!Err || Ranges.size() > 0)
+  return std::make_unique(std::move(Ranges));
+
+return Err;

labath wrote:

If we encounter an error after reading at least one element, this will assert 
due to not consuming the error. If this is the behavior you want, you should 
thrown in an extra `consumeError(std::move(Err))` here.

*However*, I'm not sure this is the best behavior, as we will swallow the error 
and the caller of this function has no way of knowing that he has given an 
incomplete range. I *think* it'd be better to just pass the error instead of an 
incomplete range. I.e., this:
```suggestion
if (Err) return Err;
return std::make_unique(std::move(Ranges));
```

I realize this may seem to contradict what I said earlier about the 
`getMemory64List`, but there is a logic to that: `getMemory64List` can (thanks 
to the iterator pattern) return both a partial result *and* and error, and it 
is this flexibility which allows the callers (such as this function) to choose 
what they want to do. It's just that for this particular caller, I don't think 
that a partial result is the most useful mode of operation. Things would be 
different e.g. for a function that was looking for a particular piece of 
memory, in which case it could return early (and successfully) even if the rest 
of the stream was corrupted.

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -132,6 +140,92 @@ class MinidumpFile : public Binary {
 size_t Stride;
   };
 
+  /// Class the provides an iterator over the memory64 memory ranges. Only the
+  /// the first descriptor is validated as readable beforehand.
+  class Memory64Iterator {
+  public:
+static Memory64Iterator
+begin(ArrayRef Storage,
+  ArrayRef Descriptors) {
+  return Memory64Iterator(Storage, Descriptors);
+}
+
+static Memory64Iterator end() { return Memory64Iterator(); }
+
+bool operator==(const Memory64Iterator &R) const {
+  return IsEnd == R.IsEnd;
+}
+
+bool operator!=(const Memory64Iterator &R) const { return !(*this == R); }
+
+const std::pair> &
+operator*() {
+  return Current;
+}
+
+const std::pair> *
+operator->() {
+  return &Current;
+}
+
+Error inc() {
+  if (Storage.size() == 0 || Descriptors.size() == 0) {

labath wrote:

```suggestion
  if (Descriptors.empty()) {
```

(storage size is checked on line 179)

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,88 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(File.streams().size(), 1u);
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;
+  auto Iterator = MemoryList.begin();
+
+  auto DescOnePair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescOne = DescOnePair.first;
+  ASSERT_THAT(DescOne.StartOfMemoryRange, 0x7FCF0818283u);
+  ASSERT_THAT(DescOne.DataSize, 5u);
+  ++Iterator;
+  ASSERT_FALSE(Err);

labath wrote:

```suggestion
  ASSERT_THAT_ERROR(Err, Succeeded());
```

(should give a better error msg if this fails)

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -132,6 +140,92 @@ class MinidumpFile : public Binary {
 size_t Stride;
   };
 
+  /// Class the provides an iterator over the memory64 memory ranges. Only the
+  /// the first descriptor is validated as readable beforehand.
+  class Memory64Iterator {
+  public:
+static Memory64Iterator
+begin(ArrayRef Storage,
+  ArrayRef Descriptors) {
+  return Memory64Iterator(Storage, Descriptors);
+}
+
+static Memory64Iterator end() { return Memory64Iterator(); }
+
+bool operator==(const Memory64Iterator &R) const {
+  return IsEnd == R.IsEnd;
+}
+
+bool operator!=(const Memory64Iterator &R) const { return !(*this == R); }
+
+const std::pair> &
+operator*() {
+  return Current;
+}
+
+const std::pair> *
+operator->() {
+  return &Current;
+}
+
+Error inc() {
+  if (Storage.size() == 0 || Descriptors.size() == 0) {
+IsEnd = true;
+return Error::success();
+  }
+
+  // Drop front gives us an array ref, so we need to call .front() as well.
+  const minidump::MemoryDescriptor_64 &Descriptor = Descriptors.front();
+  if (Descriptor.DataSize > Storage.size()) {
+IsEnd = true;
+return make_error(
+"Memory64 Descriptor exceeds end of file.",
+object_error::unexpected_eof);
+  }
+
+  ArrayRef Content = Storage.take_front(Descriptor.DataSize);
+  Current = std::make_pair(Descriptor, Content);
+
+  Storage = Storage.drop_front(Descriptor.DataSize);
+  Descriptors = Descriptors.drop_front();
+
+  if (Descriptors.empty())
+IsEnd = true;

labath wrote:

This doesn't look correct. Since you're holding the "current" object in a 
separate member, the emptyness of this does not indicate that you've reached 
the end (well, you sort of did, but the end iterator should point **past** the 
end of the array). I would expect that this should be caught the next time 
someone calls this function (attempts to increment the iterator).

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,88 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(File.streams().size(), 1u);
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;
+  auto Iterator = MemoryList.begin();
+
+  auto DescOnePair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescOne = DescOnePair.first;
+  ASSERT_THAT(DescOne.StartOfMemoryRange, 0x7FCF0818283u);
+  ASSERT_THAT(DescOne.DataSize, 5u);
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescTwoPair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescTwo = DescTwoPair.first;
+  ASSERT_THAT(DescTwo.StartOfMemoryRange, 0x7FFF0818283u);
+  ASSERT_THAT(DescTwo.DataSize, 5u);
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  const std::optional> ExpectedContent =
+  File.getRawStream(StreamType::Memory64List);
+  ASSERT_TRUE(ExpectedContent);
+  const size_t ExpectedStreamSize =
+  sizeof(Memory64ListHeader) + (sizeof(MemoryDescriptor_64) * 2);
+  ASSERT_THAT(ExpectedStreamSize, ExpectedContent->size());

labath wrote:

and reverse the order here :)

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,89 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(1u, File.streams().size());
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;
+  auto Iterator = MemoryList.begin();
+
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescOnePair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescOne = DescOnePair.first;
+  ASSERT_THAT(0x7FCF0818283u, DescOne.StartOfMemoryRange);
+  ASSERT_THAT(5u, DescOne.DataSize);
+
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescTwoPair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescTwo = DescTwoPair.first;
+  ASSERT_THAT(0x7FFF0818283u, DescTwo.StartOfMemoryRange);
+  ASSERT_THAT(5u, DescTwo.DataSize);
+  const std::optional> ExpectedContent =
+  File.getRawStream(StreamType::Memory64List);
+  ASSERT_TRUE(ExpectedContent);
+  const size_t ExpectedStreamSize =
+  sizeof(Memory64ListHeader) + (sizeof(MemoryDescriptor_64) * 2);
+  ASSERT_THAT(ExpectedStreamSize, ExpectedContent->size());
+
+  Expected ExpectedHeader =
+  File.getMemoryList64Header();
+  ASSERT_THAT_EXPECTED(ExpectedHeader, Succeeded());
+  ASSERT_THAT(ExpectedHeader->BaseRVA, 92u);
+
+  Expected> DescOneExpectedContentSlice = DescOnePair.second;
+  ASSERT_THAT_EXPECTED(DescOneExpectedContentSlice, Succeeded());
+  ASSERT_THAT(5u, DescOneExpectedContentSlice->size());
+  ASSERT_THAT(arrayRefFromStringRef("hello"), *DescOneExpectedContentSlice);
+
+  Expected> DescTwoExpectedContentSlice = DescTwoPair.second;
+  ASSERT_THAT_EXPECTED(DescTwoExpectedContentSlice, Succeeded());
+  ASSERT_THAT(arrayRefFromStringRef("world"), *DescTwoExpectedContentSlice);
+
+  ASSERT_TRUE(Iterator == MemoryList.end());
+}
+
+TEST(MinidumpYAML, MemoryRegion_DataSize_TooSmall) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Data Size: 4   1
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Failed());

labath wrote:

The thing I'd like to be sure is that this code fails for the "right" reason. 
I.e., due to the small size, and not -- like it did before -- due to a syntax 
error. I see you have fixed the error now, but this is still a fragile pattern, 
so some sort of a positive test would be better. If there's some indication of 
the error in the error string, then we could check that with 
`FailedWithMessage("expected error string")` here. Otherwise, I think it be 
better to do it with a lit test.

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -154,3 +155,50 @@ MinidumpFile::create(MemoryBufferRef Source) {
   return std::unique_ptr(
   new MinidumpFile(Source, Hdr, *ExpectedStreams, std::move(StreamMap)));
 }
+
+static iterator_range
+makeEmptyRange(Error &Err) {
+  return make_range(
+  llvm::object::MinidumpFile::FallibleMemory64Iterator::itr(
+  llvm::object::MinidumpFile::Memory64Iterator::end(), Err),
+  llvm::object::MinidumpFile::FallibleMemory64Iterator::end(
+  llvm::object::MinidumpFile::Memory64Iterator::end()));

labath wrote:

```suggestion
  return make_fallible_range(
   Memory64Iterator::end(),
   Memory64Iterator::end(), Err);
```

.. although the way I'd probably do it is to delete this function, put an `auto 
end = make_fallible_end(Memory64Iterator::end())` at the beginning of the 
`getMemory64List` function, and then do a `return make_range(end, end)` on the 
error paths.

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -494,6 +528,23 @@ Stream::create(const Directory &StreamDesc, const 
object::MinidumpFile &File) {
 }
 return std::make_unique(std::move(Ranges));
   }
+  case StreamKind::Memory64List: {
+Error Err = Error::success();
+auto Memory64List = File.getMemory64List(Err);
+if (Err)
+  return Err;

labath wrote:

```suggestion
auto Memory64List = File.getMemory64List(Err);
```

I think we can delete this check, as the error will be checked below, and we 
will get an empty iterator range in case of early fatal errors.

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,88 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(File.streams().size(), 1u);
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);

labath wrote:

This shouldn't be necessary. Could it have something to do with the fact that 
you're not using the `ErrorAsOutParameter` object inside `getMemory64List`? 
(That object allows you to assign to an error object without first checking it).

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,88 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(File.streams().size(), 1u);
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;

labath wrote:

```suggestion
  iterator_range = 
File.getMemory64List(Err);

  ASSERT_THAT_ERROR(Err, Succeeded());
```

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -336,3 +336,88 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(File.streams().size(), 1u);
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;
+  auto Iterator = MemoryList.begin();
+
+  auto DescOnePair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescOne = DescOnePair.first;
+  ASSERT_THAT(DescOne.StartOfMemoryRange, 0x7FCF0818283u);
+  ASSERT_THAT(DescOne.DataSize, 5u);
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescTwoPair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescTwo = DescTwoPair.first;
+  ASSERT_THAT(DescTwo.StartOfMemoryRange, 0x7FFF0818283u);
+  ASSERT_THAT(DescTwo.DataSize, 5u);
+  ++Iterator;
+  ASSERT_FALSE(Err);

labath wrote:

```suggestion
  ASSERT_THAT_ERROR(Err, Succeeded());
```

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -132,6 +140,95 @@ class MinidumpFile : public Binary {
 size_t Stride;
   };
 
+  /// Class the provides an iterator over the memory64 memory ranges. Only the
+  /// the first descriptor is validated as readable beforehand.
+  class Memory64Iterator {
+  public:
+static Memory64Iterator
+begin(ArrayRef Storage,
+  ArrayRef Descriptors,
+  uint64_t BaseRVA) {
+  return Memory64Iterator(Storage, Descriptors, BaseRVA);
+}
+
+static Memory64Iterator end() { return Memory64Iterator(); }
+
+std::pair> Current;
+
+bool operator==(const Memory64Iterator &R) const {
+  return IsEnd == R.IsEnd;
+}
+
+bool operator!=(const Memory64Iterator &R) const { return !(*this == R); }
+
+const std::pair> &
+operator*() {
+  return Current;
+}
+
+const std::pair> *
+operator&() {
+  return &Current;
+}
+
+Error inc() {
+  if (Storage.size() == 0 || Descriptors.size() == 0)
+return make_error("No Memory64List Stream",
+  object_error::parse_failed);
+
+  if (Index >= Descriptors.size())
+return createError("Can't read past of Memory64List Stream");
+
+  const minidump::MemoryDescriptor_64 &Descriptor = Descriptors[Index];
+  if (RVA + Descriptor.DataSize > Storage.size())
+return make_error(
+"Memory64 Descriptor exceeds end of file.",
+object_error::unexpected_eof);
+
+  ArrayRef Content = Storage.slice(RVA, Descriptor.DataSize);
+  Current = std::make_pair(Descriptor, Content);
+  Index++;
+  RVA += Descriptor.DataSize;
+  if (Index >= Descriptors.size())
+IsEnd = true;
+  return Error::success();
+}
+
+  private:
+// This constructor will only happen after a validation check to see
+// if the first descriptor is readable.
+Memory64Iterator(ArrayRef Storage,
+ ArrayRef Descriptors,
+ uint64_t BaseRVA)
+: RVA(BaseRVA), Storage(Storage), Descriptors(Descriptors),
+  IsEnd(false) {
+  assert(Descriptors.size() > 0);
+  assert(Storage.size() >= BaseRVA + Descriptors.front().DataSize);

labath wrote:

Okay, that's fine.

https://github.com/llvm/llvm-project/pull/101272
___
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)

2024-08-08 Thread 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] Change lldb's breakpoint handling behavior (PR #96260)

2024-08-08 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> Thanks @DavidSpickett just to be sure, this is armv7 right, not AArch32?

This is an AArch32 container on Armv8. I'm not sure if lldb-server knows the 
difference though. Maybe it doesn't need to, and ptrace single step is done in 
the kernel which uses the h/w step.

But it looks like it may software single step on any Arm, v7 and v8...

> debugserver uses the hardware breakpoint because we know we have that feature 
> on our armv7 darwin cores, but it looks like lldb-server on armv7 linux will 
> be entirely software based.

> I don't know how much lldb distinguishes between AArch32 and armv7, but this 
> is one important difference.

The single step code you posted doesn't seem to make a distinction. This is 
perhaps why we saw armv7 style behaviour on AArch32.

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

[Lldb-commits] [lldb] 2771ce8 - [lldb][Docs] Add edit link to docs pages (#102144)

2024-08-08 Thread via lldb-commits


Author: David Spickett
Date: 2024-08-08T09:48:50+01:00
New Revision: 2771ce80f86e75ba38d9f5cb39fb37aa0268f0da

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

LOG: [lldb][Docs] Add edit link to docs pages (#102144)

That aren't the generated `python_api/` pages.

This button is a pencil icon at the top right of the page and takes you
to a GitHub page where you can edit the content, assuming you have a
fork already. If not it tells you how to make one.

This is hardcoded to the llvm-project URL and main branch. So folks will
need a downstream patch if they want to change that.

For the upstream repo, main is right because even if a release branch
was open for PRs, it would only be for cherry picks from main.

The icon isn't as obvious as the "edit on GitHub" icons seen elsewhere
but it's built in, and we could change it later if we wanted to.

Added: 
lldb/docs/_templates/components/edit-this-page.html

Modified: 
lldb/docs/conf.py

Removed: 




diff  --git a/lldb/docs/_templates/components/edit-this-page.html 
b/lldb/docs/_templates/components/edit-this-page.html
new file mode 100644
index 00..671caeac52f6d2
--- /dev/null
+++ b/lldb/docs/_templates/components/edit-this-page.html
@@ -0,0 +1,9 @@
+{% extends "furo/components/edit-this-page.html" %}
+
+{% block link_available -%}
+{%- if pagename.startswith("python_api") -%}
+  
+{%- else -%}
+  {{ furo_edit_button(determine_page_edit_link()) }}
+{%- endif -%}
+{%- endblock %}
\ No newline at end of file

diff  --git a/lldb/docs/conf.py b/lldb/docs/conf.py
index 9b005c9537f23e..50f4ab84f1ca66 100644
--- a/lldb/docs/conf.py
+++ b/lldb/docs/conf.py
@@ -166,7 +166,11 @@
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
-html_theme_options = {}
+html_theme_options = {
+"source_repository": "https://github.com/llvm/llvm-project";,
+"source_branch": "main",
+"source_directory": "lldb/docs/",
+}
 
 # Add any paths that contain custom themes here, relative to this directory.
 # html_theme_path = []



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

[Lldb-commits] [lldb] [lldb][Docs] Add edit link to docs pages (PR #102144)

2024-08-08 Thread David Spickett via lldb-commits


https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/102144
___
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)

2024-08-08 Thread 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:

Hmm... this ties in to the IsValid discussion we had on a different object 
(DILMemberInfo). Since all of the factory functions creating these objects 
return a pointer, I think that having an extra IsValid() method is unnecessary 
and/or confusing as the (in)validity of the result could be indicated by the 
(in)validity of the pointer.
That I think would also make it natural to move this check to the caller, as it 
could do something like:
```
if (value_sp) return IdentifierInfo::FromValue(value_sp);
return nullptr;
```

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] 57cd100 - [lldb] Fix crash when adding members to an "incomplete" type (#102116)

2024-08-08 Thread via lldb-commits


Author: Pavel Labath
Date: 2024-08-08T10:53:15+02:00
New Revision: 57cd1000c9c93fd0e64352cfbc9fbbe5b8a8fcef

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

LOG: [lldb] Fix crash when adding members to an "incomplete" type (#102116)

This fixes a regression caused by delayed type definition searching
(#96755 and friends): If we end up adding a member (e.g. a typedef) to a
type that we've already attempted to complete (and failed), the
resulting AST would end up inconsistent (we would start to "forcibly"
complete it, but never finish it), and importing it into an expression
AST would crash.

This patch fixes this by detecting the situation and finishing the
definition as well.

Added: 
lldb/test/Shell/SymbolFile/DWARF/x86/typedef-in-incomplete-type.cpp

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

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 1a13725b99804a..86b3117f361cd1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -269,8 +269,15 @@ static void PrepareContextToReceiveMembers(TypeSystemClang 
&ast,
   }
 
   // We don't have a type definition and/or the import failed, but we need to
-  // add members to it. Start the definition to make that possible.
-  tag_decl_ctx->startDefinition();
+  // add members to it. Start the definition to make that possible. If the type
+  // has no external storage we also have to complete the definition. 
Otherwise,
+  // that will happen when we are asked to complete the type
+  // (CompleteTypeFromDWARF).
+  ast.StartTagDeclarationDefinition(type);
+  if (!tag_decl_ctx->hasExternalLexicalStorage()) {
+ast.SetDeclIsForcefullyCompleted(tag_decl_ctx);
+ast.CompleteTagDeclarationDefinition(type);
+  }
 }
 
 ParsedDWARFTypeAttributes::ParsedDWARFTypeAttributes(const DWARFDIE &die) {

diff  --git 
a/lldb/test/Shell/SymbolFile/DWARF/x86/typedef-in-incomplete-type.cpp 
b/lldb/test/Shell/SymbolFile/DWARF/x86/typedef-in-incomplete-type.cpp
new file mode 100644
index 00..591607784b0a9b
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/typedef-in-incomplete-type.cpp
@@ -0,0 +1,23 @@
+// RUN: %clangxx --target=x86_64-pc-linux -flimit-debug-info -o %t -c %s -g
+// RUN: %lldb %t -o "target var a" -o "expr -- var" -o exit | FileCheck %s
+
+// This forces lldb to attempt to complete the type A. Since it has no
+// definition it will fail.
+// CHECK: target var a
+// CHECK: (A) a = 
+
+// Now attempt to display the second variable, which will try to add a typedef
+// to the incomplete type. Make sure that succeeds. Use the expression command
+// to make sure the resulting AST can be imported correctly.
+// CHECK: expr -- var
+// CHECK: (A::X) $0 = 0
+
+struct A {
+  // Declare the constructor, but don't define it to avoid emitting the
+  // definition in the debug info.
+  A();
+  using X = int;
+};
+
+A a;
+A::X var;



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

[Lldb-commits] [lldb] [lldb] Fix crash when adding members to an "incomplete" type (PR #102116)

2024-08-08 Thread Pavel Labath via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Realpath symlinks for breakpoints (PR #102223)

2024-08-08 Thread Pavel Labath via lldb-commits

@@ -0,0 +1,66 @@
+//===-- RealpathPrefixes.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/Utility/RealpathPrefixes.h"
+
+#include "lldb/Target/Statistics.h"
+#include "lldb/Target/Target.h"

labath wrote:

> What is the general guidance of when a class should be in "Target" vs. in 
> "Utility"?

We have a description [here](https://lldb.llvm.org/resources/overview.html), 
though it leaves a lot of room for interpretation. I think it makes sense for 
this to be in Utility, but then it should not depend on Target, so that it can 
be an actual utility that can be reused for more than one purpose.

> 
> > dependency inversion technique
> 
> Like how? Below is my attempt. Haven't updated the patch. Want to get your 
> feedback first by describing it below.
> 
> I tried to make an interface `RealpathPrefixStats` which contains the two 
> increment functions, then have `TargetStats` implement this interface (thus 
> virtual functions), in the hope of the Target can create the `RealpathPrefix` 
> and feed its own `TargetStats` to it as `RealpathPrefixStats` (where 
> `RealpathPrefix` only sees `RealpathPrefixStats`, and both are in `Utility`).
> 
> However, there is the lifecycle problem as Jim pointed out earlier, that what 
> guarantees that the `RealpathPrefixStats` object lives longer than the 
> `RealpathPrefix` object. In order to guarantee this, I will need to make 
> `Target::m_stats` a shared pointer, then give a weak pointer of 
> `RealpathPrefixStats` to `RealpathPrefix`.
> 
> Is the above a good plan? Do you see a better approach?

Maybe (to both questions).

You may not need to make m_stats a shared pointer if you use the 
little-known-but-very powerful feature of shared_ptr -- the [aliasing 
constructor](https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr). 
With it, you can create a shared_ptr, which points to a subfield (m_stats), but 
keeps the whole object alive like so `std::shared_ptr(shared_from_this(), 
&m_stats)`.

A different approach would be to implement the interfaces you need on the 
Target object itself.

It may also be possible to keep a record of the statistics on the inside the 
object itself, and only later add it to the ones in the Target. This would make 
sense if there's a natural place where you can insert the call to gather the 
stats (either when the object is destructed, when the stats are requested, 
etc.).

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

[Lldb-commits] [lldb] [lldb] Realpath symlinks for breakpoints (PR #102223)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -0,0 +1,66 @@
+//===-- RealpathPrefixes.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/Utility/RealpathPrefixes.h"
+
+#include "lldb/Target/Statistics.h"
+#include "lldb/Target/Target.h"

labath wrote:

It may also make sense to move more of the statistics code into Utility as well 
(provided it does not depend on other things -- which right now I see it does, 
but it probably can be refactored away). This way you wouldn't need to do the 
interface thing.

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Pavel Labath via lldb-commits


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

Thanks for your patience.

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

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -788,7 +808,13 @@ Type::GetTypeScopeAndBasename(llvm::StringRef name) {
 switch (pos.value()) {
 case ':':
   if (prev_is_colon && template_depth == 0) {
-result.scope.push_back(name.slice(name_begin, pos.index() - 1));
+llvm::StringRef scope_name = name.slice(name_begin, pos.index() - 1);
+// The itanium demangler uses this string to represent anonymous
+// namespaces. Convert it to a more language-agnostic form (which is
+// also used in DWARF).
+if (scope_name == "(anonymous namespace)")
+  scope_name = "";

labath wrote:

Yes, that also goes through this piece of code. I'll add a test for that path.

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

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -134,6 +134,20 @@ bool TypeQuery::ContextMatches(
 if (ctx == ctx_end)
   return false; // Pattern too long.
 
+if (ctx->kind == CompilerContextKind::Namespace && ctx->name.IsEmpty()) {

labath wrote:

The anonymous namespace is detected and nullified on line 815. I'm not aware of 
such code, but if anyone was constructing these contexts without going through 
the name parser, then they'd have to make sure they use the expected (empty) 
encoding for anonymous namespaces. I think that's reasonable, because ensuring 
this when constructing the names from some kind of a structured source is easy, 
and noone should be parsing name strings by hand as the process is very 
nontrivial. They should rather call the function in this file (which will do 
the nullification for them).

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

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -440,12 +440,6 @@ static void GetTypeLookupContextImpl(DWARFDIE die,
   continue;
 }
 
-// If there is no name, then there is no need to look anything up for this
-// DIE.
-const char *name = die.GetName();
-if (!name || !name[0])
-  return;
-

labath wrote:

unnamed structs cannot contain [named 
structs](https://godbolt.org/z/sEfdMEvsz), so the only place these can appear 
is at the top (bottom?) level. We don't currently have a way to look them up 
from our APIs taking strings (we'd need something like an `(anonymous 
struct)`), but they could be looked up internally by code which constructs 
CompilerContexts directly. So yeah, I think including them here is the right 
choice for this function.

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

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

2024-08-08 Thread Pavel Labath via lldb-commits


https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/102111

>From c6936f3d5d0592babe9082e867b179af594c447b Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Tue, 6 Aug 2024 09:51:20 +0200
Subject: [PATCH 1/4] [lldb] Better matching of types in anonymous namespaces

This patch extends TypeQuery matching to support anonymous namespaces. A
new flag is added to control the behavior. In the "strict" mode, the
query must match the type exactly -- all anonymous namespaces included.
The dynamic type resolver in the itanium abi (the motivating use case
for this) uses this flag, as it queries using the name from the
demangles, which includes anonymous namespaces.

This ensures we don't confuse a type with a same-named type in an
anonymous namespace. However, this does *not* ensure we don't confuse
two types in anonymous namespacs (in different CUs). To resolve this, we
would need to use a completely different lookup algorithm, which
probably also requires a DWARF extension.

In the "lax" mode (the default), the anonymous namespaces in the query
are optional, and this allows one search for the type using the usual
language rules (`::A` matches `::(anonymous namespace)::A`).

This patch also changes the type context computation algorithm in
DWARFDIE, so that it includes anonymous namespace information. This
causes a slight change in behavior: the algorithm previously stopped
computing the context after encountering an anonymous namespace, which
caused the outer namespaces to be ignored. This meant that a type like
`NS::(anonymous namespace)::A` would be (incorrectly) recognized as
`::A`). This can cause code depending on the old behavior to misbehave.
The fix is to specify all the enclosing namespaces in the query, or use
a non-exact match.
---
 lldb/include/lldb/Symbol/Type.h   | 10 -
 .../ItaniumABI/ItaniumABILanguageRuntime.cpp  |  1 +
 .../Plugins/SymbolFile/DWARF/DWARFDIE.cpp |  8 +---
 lldb/source/Symbol/Type.cpp   | 33 +---
 lldb/test/API/lang/cpp/dynamic-value/Makefile |  2 +-
 .../cpp/dynamic-value/TestDynamicValue.py | 17 -
 lldb/test/API/lang/cpp/dynamic-value/a.h  | 25 
 .../lang/cpp/dynamic-value/anonymous-b.cpp| 15 
 .../lang/cpp/dynamic-value/pass-to-base.cpp   | 38 +--
 lldb/unittests/Symbol/TestType.cpp| 22 +++
 .../SymbolFile/DWARF/DWARFDIETest.cpp | 24 +++-
 11 files changed, 149 insertions(+), 46 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/dynamic-value/a.h
 create mode 100644 lldb/test/API/lang/cpp/dynamic-value/anonymous-b.cpp

diff --git a/lldb/include/lldb/Symbol/Type.h b/lldb/include/lldb/Symbol/Type.h
index 420307e0dbcf02..021e27b52fca71 100644
--- a/lldb/include/lldb/Symbol/Type.h
+++ b/lldb/include/lldb/Symbol/Type.h
@@ -77,10 +77,13 @@ FLAGS_ENUM(TypeQueryOptions){
 /// If set, the query will ignore all Module entries in the type context,
 /// even for exact matches.
 e_ignore_modules = (1u << 2),
+/// If set, all anonymous namespaces in the context must be matched exactly
+/// by the pattern. Otherwise, superfluous namespaces are skipped.
+e_strict_namespaces = (1u << 3),
 /// When true, the find types call should stop the query as soon as a 
single
 /// matching type is found. When false, the type query should find all
 /// matching types.
-e_find_one = (1u << 3),
+e_find_one = (1u << 4),
 };
 LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
 
@@ -266,6 +269,11 @@ class TypeQuery {
   bool GetIgnoreModules() const { return (m_options & e_ignore_modules) != 0; }
   void SetIgnoreModules() { m_options &= ~e_ignore_modules; }
 
+  bool GetStrictNamespaces() const {
+return (m_options & e_strict_namespaces) != 0;
+  }
+  void SetStrictNamespaces() { m_options &= ~e_strict_namespaces; }
+
   /// The \a m_context can be used in two ways: normal types searching with
   /// the context containing a stanadard declaration context for a type, or
   /// with the context being more complete for exact matches in clang modules.
diff --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
index 7af768aad0bc19..4c547afe30fe81 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
@@ -90,6 +90,7 @@ TypeAndOrName ItaniumABILanguageRuntime::GetTypeInfo(
   TypeResults results;
   TypeQuery query(const_lookup_name.GetStringRef(),
   TypeQueryOptions::e_exact_match |
+  TypeQueryOptions::e_strict_namespaces |
   TypeQueryOptions::e_find_one);
   if (module_sp) {
 module_sp->FindTypes(query, results);
diff --git a/lldb/source/Plugins/Symbol

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

2024-08-08 Thread Pavel Labath via lldb-commits

labath wrote:

> This patch relies on "(anonymous namespace)" being removed from the compiler 
> contexts to work. What is the user types any of:
> 
> ```
> (lldb) type lookup "(anonymous namespace)::A"
> (lldb) script lldb.target.FindFirstType("(anonymous namespace)::A");
> (lldb) script lldb.target.FindTypes("(anonymous namespace)::A");
> ```
> 
> Do we correctly set this "(anonymous namespace)" to empty? Or are we 
> expecting these type lookups will always use the looser matching strategy?

These lookups use the looser matching strategy which means they can to the 
lookup both with and without the namespace prefix. Matching the exact string in 
the matching algorighm is not necessary because it gets canonicalized in the 
parser. I've now added a test for this.

> If not we need to check for both.
> 
> We might want to stop passing around `std::vector` and pass 
> around a class that contains the language:
> 
> ```
> struct CompilerContexts {
>   lldb::LanguageType language;
>   std::vector;
> };
> ```
> 
> Then we could add a method to check for anonymous namespaces where C++ can 
> check for "(anonymous namespace)".

For something like this, I think the bigger question is whether we want our 
type name syntax to be language specific. If we don't (which is the current 
state), and we say that we use the same syntax for all language (and the syntax 
happens to mostly match the c++ language), then I don't think we need this, as 
we can just canonicalize the type context during parsing (like I did here).

OTOH, if we want to have language-specific syntax, then we may need to do 
something completely different, because it's not even possible to parse the 
string into the context vector without knowing the language (the type queries 
don't usually specify a specific language, so we may have to delay the parsing 
until we know which language we are matching against).

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Pavel Labath via lldb-commits


https://github.com/labath commented:

> @labath I have added the class SharedSocket. I have implemented all the 
> recommendations.

Looks mostly fine. Just a couple of notes. David, what do you think?


> Note we have the buildbot for cross tests (Windows x64/Linux x64 host and 
> Linux Aarch64 target).
> So everything is tested. Hope 1191 API tests run with this lldb-server are 
> enough.

That's great, but I don't think this should be the only way this code is 
tested, as most of it can be tested perfectly well locally. Most of the devs 
will not be running this bot configuration before they push their patches, and 
they will not know how to set it up when they get the breakage email, so it's 
always better to have a first line of defense that everyone can use, and leave 
the cross testing for catching subtle integration details.

That said, we do have that one test which should exercise most of this code, so 
I'm sort of fine with this for now, but I still may ask for more tests in the 
future, for example, when we librarize this code.

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -44,6 +47,112 @@ using namespace llvm;
 
 // option descriptors for getopt_long_only()
 
+#ifdef _WIN32
+typedef pipe_t fd_t;
+const fd_t kInvalidSharedFD = LLDB_INVALID_PIPE;
+#else
+typedef NativeSocket fd_t;
+const fd_t kInvalidSharedFD = Socket::kInvalidSocketValue;
+#endif
+
+class SharedSocket {
+public:
+  // Used by the parent process.
+  SharedSocket(Connection *conn, Status &error) {
+m_fd = kInvalidSharedFD;
+
+const Socket *socket =
+static_cast(conn->GetReadObject().get());
+if (socket == nullptr) {
+  error = Status("invalid conn socket");
+  return;
+}
+
+#ifdef _WIN32
+m_socket = socket->GetNativeSocket();
+
+// Create a pipe to transfer WSAPROTOCOL_INFO to the child process.
+error = m_socket_pipe.CreateNew(true);
+if (error.Fail())
+  return;
+
+m_fd = m_socket_pipe.GetReadPipe();
+#else
+m_fd = socket->GetNativeSocket();
+error = Status();
+#endif
+  }
+
+  // Used by the child process.
+  SharedSocket(fd_t fd) : m_fd(fd) {}

labath wrote:

```suggestion
  explicit SharedSocket(fd_t fd) : m_fd(fd) {}
```

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -44,6 +47,112 @@ using namespace llvm;
 
 // option descriptors for getopt_long_only()
 
+#ifdef _WIN32
+typedef pipe_t fd_t;
+const fd_t kInvalidSharedFD = LLDB_INVALID_PIPE;
+#else
+typedef NativeSocket fd_t;
+const fd_t kInvalidSharedFD = Socket::kInvalidSocketValue;
+#endif
+
+class SharedSocket {
+public:
+  // Used by the parent process.
+  SharedSocket(Connection *conn, Status &error) {
+m_fd = kInvalidSharedFD;
+
+const Socket *socket =
+static_cast(conn->GetReadObject().get());
+if (socket == nullptr) {
+  error = Status("invalid conn socket");
+  return;
+}
+
+#ifdef _WIN32
+m_socket = socket->GetNativeSocket();
+
+// Create a pipe to transfer WSAPROTOCOL_INFO to the child process.
+error = m_socket_pipe.CreateNew(true);
+if (error.Fail())
+  return;
+
+m_fd = m_socket_pipe.GetReadPipe();
+#else
+m_fd = socket->GetNativeSocket();
+error = Status();
+#endif
+  }
+
+  // Used by the child process.
+  SharedSocket(fd_t fd) : m_fd(fd) {}
+
+  fd_t GetSendableFD() { return m_fd; }
+
+  Status CompleteSending(lldb::pid_t child_pid) {
+#ifdef _WIN32
+// Transfer WSAPROTOCOL_INFO to the child process.
+m_socket_pipe.CloseReadFileDescriptor();
+
+WSAPROTOCOL_INFO protocol_info;
+if (::WSADuplicateSocket(m_socket, child_pid, &protocol_info) ==
+SOCKET_ERROR) {
+  int last_error = ::WSAGetLastError();
+  return Status("WSADuplicateSocket() failed, error: %d", last_error);
+}
+
+size_t num_bytes;
+Status error =
+m_socket_pipe.WriteWithTimeout(&protocol_info, sizeof(protocol_info),
+   std::chrono::seconds(10), num_bytes);
+if (error.Fail())
+  return error;
+if (num_bytes != sizeof(protocol_info))
+  return Status("WriteWithTimeout(WSAPROTOCOL_INFO) failed: %d bytes",
+num_bytes);
+#endif
+return Status();
+  }
+
+  Status GetNativeSocket(NativeSocket &socket) {

labath wrote:

I think this would be better off as a static function -- it's not using any of 
the members except m_fd, which could just as easily be a function argument, and 
it's duplicating the Pipe and NativeSocket members as local vars.

I can also imagine with a proper member function version of it, but then I 
think should reuse the members in the class. For example, by putting most of 
this work into the constructor, where it will initialize the m_pipe member and 
use it to receive the NativeSocket. `GetNativeSocket` could then be a plain 
getter (?)

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Pavel Labath via lldb-commits



@@ -114,6 +224,133 @@ static Status save_socket_id_to_file(const std::string 
&socket_id,
   return status;
 }
 
+static void client_handle(GDBRemoteCommunicationServerPlatform &platform,
+  const lldb_private::Args &args) {
+  if (!platform.IsConnected())
+return;
+
+  if (args.GetArgumentCount() > 0) {
+lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+std::optional port;
+std::string socket_name;
+Status error = platform.LaunchGDBServer(args,
+"", // hostname
+pid, port, socket_name);
+if (error.Success())
+  platform.SetPendingGdbServer(pid, *port, socket_name);
+else
+  fprintf(stderr, "failed to start gdbserver: %s\n", error.AsCString());
+  }
+
+  bool interrupt = false;
+  bool done = false;
+  Status error;
+  while (!interrupt && !done) {
+if (platform.GetPacketAndSendResponse(std::nullopt, error, interrupt,
+  done) !=
+GDBRemoteCommunication::PacketResult::Success)
+  break;
+  }
+
+  printf("Disconnected.\n");
+}
+
+static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
+static std::mutex gdbserver_portmap_mutex;
+
+static void spawn_process_reaped(lldb::pid_t pid, int signal, int status) {
+  std::lock_guard guard(gdbserver_portmap_mutex);
+  gdbserver_portmap.FreePortForProcess(pid);
+}
+
+static Status spawn_process(const char *progname, Connection *conn,
+uint16_t gdb_port, uint16_t port_offset,
+const lldb_private::Args &args,
+const std::string &log_file,
+const StringRef log_channels) {
+  Status error;
+  SharedSocket shared_socket(conn, error);
+  if (error.Fail())
+return error;
+
+  ProcessLaunchInfo launch_info;
+
+  FileSpec self_spec(progname, FileSpec::Style::native);
+  launch_info.SetExecutableFile(self_spec, true);
+  Args &self_args = launch_info.GetArguments();
+  self_args.AppendArgument(llvm::StringRef("platform"));
+  self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
+  self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
+  if (gdb_port) {
+self_args.AppendArgument(llvm::StringRef("--gdbserver-port"));
+self_args.AppendArgument(llvm::to_string(gdb_port));
+  }
+  if (port_offset > 0) {
+self_args.AppendArgument(llvm::StringRef("--port-offset"));
+self_args.AppendArgument(llvm::to_string(port_offset));
+  }
+  if (!log_file.empty()) {
+self_args.AppendArgument(llvm::StringRef("--log-file"));
+self_args.AppendArgument(log_file);
+  }
+  if (!log_channels.empty()) {
+self_args.AppendArgument(llvm::StringRef("--log-channels"));
+self_args.AppendArgument(log_channels);
+  }
+  if (args.GetArgumentCount() > 0) {
+self_args.AppendArgument("--");
+self_args.AppendArguments(args);
+  }
+
+  launch_info.SetLaunchInSeparateProcessGroup(false);
+  launch_info.SetMonitorProcessCallback(&spawn_process_reaped);
+
+  // Copy the current environment.
+  // WSASocket(FROM_PROTOCOL_INFO) will fail in the child process
+  // with the error WSAEPROVIDERFAILEDINIT if the SystemRoot is missing
+  // in the environment.

labath wrote:

FWIW, I don't think this requires any special justification. Environment 
inheritance is the default behavior when launching processes. I'd just delete 
this comment.

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Pavel Labath via lldb-commits


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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)

2024-08-08 Thread Dmitri Gribenko via lldb-commits


gribozavr wrote:

@mizvekov I will provide a more detailed response to the points you made in 
your last message separately, but for now I would like to ask you to revert the 
commit to unbreak us.

We looked into the problem internally and it does not look we have a simple 
hack we can apply to recover this information. The solutions you offered so far 
to unblock us are going to take years to implement (like waiting for you to 
complete work that you consider low priority, or upstreaming our code - which 
means upstreaming 20 KLoC of nullability verification code which involves 
resolving differences around pragma semantics etc.)

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/102488

This will soon be needed for https://github.com/llvm/llvm-project/pull/102309, 
where we plan on calling these APIs from generic ExpressionParser code.

>From 99dd6c9d974ffd95f3c2aed9dfb2a861cc55f084 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 2 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


Michael137 wrote:

I checked their uses in the Swift repo and we always have a `Target` available 
when we call these methods. So we should be able to use `Target::GetPlatform` 
to replace those static calls.

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

This will soon be needed for https://github.com/llvm/llvm-project/pull/102309, 
where we plan on calling these APIs from generic ExpressionParser code.

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


2 Files Affected:

- (modified) lldb/include/lldb/Target/Platform.h (+34) 
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h (+5-26) 


``diff
diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);

``




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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From 99dd6c9d974ffd95f3c2aed9dfb2a861cc55f084 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH 1/2] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 2 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);

>From 7f560914c7ffd0521c093d1bea9e424b1dfbfc06 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:32:53 +0100
Subject: [PATCH 2/2] fixup! fix unit-test build

---
 .../SymbolFile/DWARF/XcodeSDKModuleTests.cpp | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lldb/unitte

[Lldb-commits] [lldb] Reland "[lldb][ClangExpressionParser] Set BuiltinHeadersInSystemModules depending on SDK version (#102309)" (PR #102497)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From d2f0b68afe6ebfffe5a2ef3ce14a77a5e1025c90 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH 1/4] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 .../SymbolFile/DWARF/XcodeSDKModuleTests.cpp  | 12 +--
 3 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);
diff --git a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp 
b/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
index c37da89ff79ce7..dc5680522e1836 100644
--- a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
+++ b/lldb/unittests/SymbolFile/DWA

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Jacob Lalonde via lldb-commits



@@ -336,3 +336,89 @@ TEST(MinidumpYAML, ExceptionStream_ExtraParameter) {
0xab, 0xad, 0xca, 0xfe}),
 *ExpectedContext);
 }
+
+TEST(MinidumpYAML, MemoryRegion_64bit) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Succeeded());
+  object::MinidumpFile &File = **ExpectedFile;
+
+  ASSERT_THAT(1u, File.streams().size());
+
+  Error Err = Error::success();
+  // Explicit Err check
+  ASSERT_FALSE(Err);
+  Expected>
+  ExpectedMemoryList = File.getMemory64List(Err);
+
+  ASSERT_THAT_EXPECTED(ExpectedMemoryList, Succeeded());
+
+  iterator_range MemoryList =
+  *ExpectedMemoryList;
+  auto Iterator = MemoryList.begin();
+
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescOnePair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescOne = DescOnePair.first;
+  ASSERT_THAT(0x7FCF0818283u, DescOne.StartOfMemoryRange);
+  ASSERT_THAT(5u, DescOne.DataSize);
+
+  ++Iterator;
+  ASSERT_FALSE(Err);
+
+  auto DescTwoPair = *Iterator;
+  const minidump::MemoryDescriptor_64 &DescTwo = DescTwoPair.first;
+  ASSERT_THAT(0x7FFF0818283u, DescTwo.StartOfMemoryRange);
+  ASSERT_THAT(5u, DescTwo.DataSize);
+  const std::optional> ExpectedContent =
+  File.getRawStream(StreamType::Memory64List);
+  ASSERT_TRUE(ExpectedContent);
+  const size_t ExpectedStreamSize =
+  sizeof(Memory64ListHeader) + (sizeof(MemoryDescriptor_64) * 2);
+  ASSERT_THAT(ExpectedStreamSize, ExpectedContent->size());
+
+  Expected ExpectedHeader =
+  File.getMemoryList64Header();
+  ASSERT_THAT_EXPECTED(ExpectedHeader, Succeeded());
+  ASSERT_THAT(ExpectedHeader->BaseRVA, 92u);
+
+  Expected> DescOneExpectedContentSlice = DescOnePair.second;
+  ASSERT_THAT_EXPECTED(DescOneExpectedContentSlice, Succeeded());
+  ASSERT_THAT(5u, DescOneExpectedContentSlice->size());
+  ASSERT_THAT(arrayRefFromStringRef("hello"), *DescOneExpectedContentSlice);
+
+  Expected> DescTwoExpectedContentSlice = DescTwoPair.second;
+  ASSERT_THAT_EXPECTED(DescTwoExpectedContentSlice, Succeeded());
+  ASSERT_THAT(arrayRefFromStringRef("world"), *DescTwoExpectedContentSlice);
+
+  ASSERT_TRUE(Iterator == MemoryList.end());
+}
+
+TEST(MinidumpYAML, MemoryRegion_DataSize_TooSmall) {
+  SmallString<0> Storage;
+  auto ExpectedFile = toBinary(Storage, R"(
+--- !minidump
+Streams:
+  - Type:Memory64List
+Memory Ranges:
+  - Start of Memory Range: 0x7FCF0818283
+Data Size: 4   1
+Content:   '68656c6c6f'
+  - Start of Memory Range: 0x7FFF0818283
+Content:   '776f726c64'
+)");
+
+  ASSERT_THAT_EXPECTED(ExpectedFile, Failed());

Jlalond wrote:

I'm going to drop this for now and extend basic.yaml in the positive case where 
datasize appends 0's

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

[Lldb-commits] [lldb] [llvm] [Obj2Yaml] Add support for minidump generation with 64b memory ranges. (PR #101272)

2024-08-08 Thread Jacob Lalonde via lldb-commits



@@ -494,6 +528,23 @@ Stream::create(const Directory &StreamDesc, const 
object::MinidumpFile &File) {
 }
 return std::make_unique(std::move(Ranges));
   }
+  case StreamKind::Memory64List: {
+Error Err = Error::success();
+auto Memory64List = File.getMemory64List(Err);
+if (Err)
+  return Err;
+std::vector Ranges;
+for (const auto &Pair : Memory64List) {
+  Ranges.push_back({Pair.first, Pair.second});
+}
+
+// If we don't have an error, or if any of the reads succeed, return ranges
+// this would also work if we have no descriptors.
+if (!Err || Ranges.size() > 0)
+  return std::make_unique(std::move(Ranges));
+
+return Err;

Jlalond wrote:

You know it's been a fun PR when we've gone full circle! I've edited the code 
as you suggest.

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

[Lldb-commits] [lldb] Reland "[lldb][ClangExpressionParser] Set BuiltinHeadersInSystemModules depending on SDK version (#102309)" (PR #102497)

2024-08-08 Thread Michael Buch via lldb-commits


https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/102497

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

This reverts commit 
https://github.com/llvm/llvm-project/commit/cf56e265e4b74799aee72a04b634fcc261078084.

The original change was reverted because it was causing linker failures
in the unit-tests:
```
Undefined symbols for architecture arm64:
  
"lldb_private::PlatformDarwin::GetSDKPathFromDebugInfo(lldb_private::Module&)",
referenced from:
  
lldb_private::ClangExpressionParser::ClangExpressionParser(lldb_private::ExecutionContextScope*,
lldb_private::Expression&, bool,
std::__1::vector, std::__1::allocator>,
std::__1::allocator, std::__1::allocator>>>,
std::__1::basic_string,
std::__1::allocator>) in
liblldbPluginExpressionParserClang.a[11](ClangExpressionParser.cpp.o)
ld: symbol(s) not found for architecture arm64
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
```

The relanded version differs only in the fact that we now use the
generic `Platform` abstraction to get to `GetSDKPathFromDebugInfo`.

>From d2f0b68afe6ebfffe5a2ef3ce14a77a5e1025c90 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH 1/2] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 .../SymbolFile/DWARF/XcodeSDKModuleTests.cpp  | 12 +--
 3 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugI

[Lldb-commits] [lldb] Reland "[lldb][ClangExpressionParser] Set BuiltinHeadersInSystemModules depending on SDK version (#102309)" (PR #102497)

2024-08-08 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

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

This reverts commit 
https://github.com/llvm/llvm-project/commit/cf56e265e4b74799aee72a04b634fcc261078084.

The original change was reverted because it was causing linker failures
in the unit-tests:
```
Undefined symbols for architecture arm64:
  
"lldb_private::PlatformDarwin::GetSDKPathFromDebugInfo(lldb_private::Module&)",
referenced from:
  
lldb_private::ClangExpressionParser::ClangExpressionParser(lldb_private::ExecutionContextScope*,
lldb_private::Expression&, bool,
std::__1::vector, std::__1::allocator>,
std::__1::allocator, std::__1::allocator,
std::__1::allocator>) in
liblldbPluginExpressionParserClang.a[11](ClangExpressionParser.cpp.o)
ld: symbol(s) not found for architecture arm64
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
```

The relanded version differs only in the fact that we now use the
generic `Platform` abstraction to get to `GetSDKPathFromDebugInfo`.

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


6 Files Affected:

- (modified) lldb/include/lldb/Target/Platform.h (+34) 
- (modified) lldb/include/lldb/Utility/XcodeSDK.h (+14) 
- (modified) 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp (+63-3) 
- (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h (+5-26) 
- (modified) lldb/source/Utility/XcodeSDK.cpp (+21) 
- (modified) lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp (+9-3) 


``diff
diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/include/lldb/Utility/XcodeSDK.h 
b/lldb/include/lldb/Utility/XcodeSDK.h
index 673ea578ffce85..2720d0d8a44a11 100644
--- a/lldb/include/lldb/Utility/XcodeSDK.h
+++ b/lldb/include/lldb/Utility/XcodeSDK.h
@@ -85,6 +85,20 @@ class XcodeSDK {
   /// Whether LLDB feels confident importing Clang modules from this SDK.
   static bool SDKSupportsModules(Type type, llvm::VersionTuple version);
   static bool SDKSupportsModules(Type desired_type, const FileSpec &sdk_path);
+
+  /// Returns true if the SDK for the specified triple supports
+  /// builtin modules in system headers.
+  ///
+  /// NOTE: should be kept in sync with sdkSupportsBuiltinModules in
+  /// Toolchains/Darwin.cpp
+  ///
+  /// FIXME: this function will be removed once LLDB's ClangExpressionParser
+  /// constructs the compiler instance through the driver/toolchain. See \ref
+  /// SetupImportStdModuleLangOpts
+  ///
+  static bool SDKSupportsBuiltinModules(const llvm::Triple &target_triple,
+llvm::VersionTuple sdk_version);
+
   /// Return the canonica

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Support minidumps where there are multiple exception streams (PR #97470)

2024-08-08 Thread Jacob Lalonde via lldb-commits


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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


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

[Lldb-commits] [lldb] Reland "[lldb][ClangExpressionParser] Set BuiltinHeadersInSystemModules depending on SDK version (#102309)" (PR #102497)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From d2f0b68afe6ebfffe5a2ef3ce14a77a5e1025c90 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH 1/3] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 .../SymbolFile/DWARF/XcodeSDKModuleTests.cpp  | 12 +--
 3 files changed, 48 insertions(+), 29 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);
diff --git a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp 
b/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
index c37da89ff79ce7..dc5680522e1836 100644
--- a/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp
+++ b/lldb/unittests/SymbolFile/DWA

[Lldb-commits] [lldb] [lldb/Interpreter] Fix ambiguous partial command resolution (PR #101934)

2024-08-08 Thread via lldb-commits


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

LGTM

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)

2024-08-08 Thread Matheus Izvekov via lldb-commits

mizvekov wrote:

> @mizvekov I will provide a more detailed response to the points you made in 
> your last message separately, but for now I would like to ask you to revert 
> the commit to unbreak us.

@gribozavr see https://github.com/llvm/llvm-project/pull/102510 for alternative.

> which means upstreaming 20 KLoC of nullability verification code which 
> involves resolving differences around pragma semantics etc.)

That's not really true. You only need to upstream the AST affecting parts. The 
attributes itself and AST node which represent it.
You can try proposing to add this attribute and guard it under an experimental 
flag, and promise no stability and to take ownership of it.

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Greg Clayton via lldb-commits


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

>From f0cd3ef613b2da145b14a3d79d6810cc19e9b198 Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Tue, 30 Jul 2024 13:37:44 -0700
Subject: [PATCH 1/8] Impove ObjectFileELF's .dynamic parsing and usage.

This patch improves the ability of a ObjectFileELF instance to read the 
.dynamic section. It adds the ability to read the .dynamic section from a ELF 
file that is read from memory, cleans up the usage of the .dynamic entries so 
that ObjectFileELF::ParseDynamicSymbols() is the only code that parses .dynamic 
entries, teaches that function the read and store the string values for each 
.dynamic entry, and dumps the .dynamic entries in the output of "image dump 
objfile". It also cleans up the code that gets the dynamic string table and the 
.dynamic data from the ELF file.
---
 lldb/include/lldb/Target/Process.h|   2 +-
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  | 356 +-
 .../Plugins/ObjectFile/ELF/ObjectFileELF.h|  38 +-
 lldb/source/Target/Process.cpp|  15 +
 .../ObjectFile/ELF/Inputs/memory-elf.cpp  |   6 +
 .../test/Shell/ObjectFile/ELF/elf-memory.test |  58 +++
 6 files changed, 378 insertions(+), 97 deletions(-)
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/Inputs/memory-elf.cpp
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/elf-memory.test

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index c8475db8ae1609..17e18261b4752d 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -1952,7 +1952,7 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::ModuleSP ReadModuleFromMemory(const FileSpec &file_spec,
   lldb::addr_t header_addr,
-  size_t size_to_read = 512);
+  size_t size_to_read = 0);
 
   /// Attempt to get the attributes for a region of memory in the process.
   ///
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 890db5c2748146..becee73f962058 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -873,33 +873,29 @@ Address ObjectFileELF::GetImageInfoAddress(Target 
*target) {
   if (!section_list)
 return Address();
 
-  // Find the SHT_DYNAMIC (.dynamic) section.
-  SectionSP dynsym_section_sp(
-  section_list->FindSectionByType(eSectionTypeELFDynamicLinkInfo, true));
-  if (!dynsym_section_sp)
-return Address();
-  assert(dynsym_section_sp->GetObjectFile() == this);
-
-  user_id_t dynsym_id = dynsym_section_sp->GetID();
-  const ELFSectionHeaderInfo *dynsym_hdr = GetSectionHeaderByIndex(dynsym_id);
-  if (!dynsym_hdr)
-return Address();
-
   for (size_t i = 0; i < m_dynamic_symbols.size(); ++i) {
-ELFDynamic &symbol = m_dynamic_symbols[i];
+const ELFDynamic &symbol = m_dynamic_symbols[i].symbol;
 
 if (symbol.d_tag == DT_DEBUG) {
   // Compute the offset as the number of previous entries plus the size of
   // d_tag.
-  addr_t offset = i * dynsym_hdr->sh_entsize + GetAddressByteSize();
-  return Address(dynsym_section_sp, offset);
+  addr_t offset = (i * 2 + 1) * GetAddressByteSize();
+  addr_t file_addr = m_dynamic_base_addr + offset;
+  Address addr;
+  if (addr.ResolveAddressUsingFileSections(file_addr, GetSectionList()))
+return addr;
 }
 // MIPS executables uses DT_MIPS_RLD_MAP_REL to support PIE. 
DT_MIPS_RLD_MAP
 // exists in non-PIE.
 else if ((symbol.d_tag == DT_MIPS_RLD_MAP ||
   symbol.d_tag == DT_MIPS_RLD_MAP_REL) &&
  target) {
-  addr_t offset = i * dynsym_hdr->sh_entsize + GetAddressByteSize();
+  SectionSP dynsym_section_sp(section_list->FindSectionByType(
+  eSectionTypeELFDynamicLinkInfo, true));
+  if (!dynsym_section_sp)
+return Address();
+
+  addr_t offset = (i * 2 + 1) * GetAddressByteSize();
   addr_t dyn_base = dynsym_section_sp->GetLoadBaseAddress(target);
   if (dyn_base == LLDB_INVALID_ADDRESS)
 return Address();
@@ -970,62 +966,23 @@ Address ObjectFileELF::GetBaseAddress() {
   return LLDB_INVALID_ADDRESS;
 }
 
-// ParseDependentModules
 size_t ObjectFileELF::ParseDependentModules() {
   if (m_filespec_up)
 return m_filespec_up->GetSize();
 
   m_filespec_up = std::make_unique();
 
-  if (!ParseSectionHeaders())
-return 0;
-
-  SectionList *section_list = GetSectionList();
-  if (!section_list)
-return 0;
-
-  // Find the SHT_DYNAMIC section.
-  Section *dynsym =
-  section_list->FindSectionByType(eSectionTypeELFDynamicLinkInfo, true)
-  .get();
-  if (!dynsym)
-return 0;
-  assert(dynsym->GetObjectFile() == this);
-
-  const ELFSectionHeaderInfo *header = 
GetSectionHeaderByIndex(dynsym

[Lldb-commits] [lldb] 28ba8a5 - [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (#101237)

2024-08-08 Thread via lldb-commits


Author: Greg Clayton
Date: 2024-08-08T11:04:52-07:00
New Revision: 28ba8a56b6fb9ec61897fa84369f46e43be94c03

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

LOG: [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (#101237)

This patch improves the ability of a ObjectFileELF instance to read the 
.dynamic section. It adds the ability to read the .dynamic section from the 
PT_DYNAMIC program header which is useful for ELF files that have no section 
headers and for ELF files that are read from memory. It cleans up the usage of 
the .dynamic entries so that ObjectFileELF::ParseDynamicSymbols() is the only 
code that parses .dynamic entries, teaches that function the read and store the 
string values for each .dynamic entry. We now dump the .dynamic entries in the 
output of "image dump objfile". It also cleans up the code that gets the 
dynamic string table so that it can grab it from the DT_STRTAB and DT_STRSZ 
.dynamic entries for when we have a ELF file with no section headers or we are 
reading it from memory.

Added: 
lldb/test/Shell/ObjectFile/ELF/Inputs/memory-elf.cpp
lldb/test/Shell/ObjectFile/ELF/elf-dynamic-no-shdrs.yaml
lldb/test/Shell/ObjectFile/ELF/elf-memory.test

Modified: 
lldb/include/lldb/Symbol/ObjectFile.h
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
lldb/source/Symbol/ObjectFile.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index 8592323322e383..d89314d44bf671 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -656,8 +656,9 @@ class ObjectFile : public 
std::enable_shared_from_this,
   // When an object file is in memory, subclasses should try and lock the
   // process weak pointer. If the process weak pointer produces a valid
   // ProcessSP, then subclasses can call this function to read memory.
-  static lldb::DataBufferSP ReadMemory(const lldb::ProcessSP &process_sp,
-   lldb::addr_t addr, size_t byte_size);
+  static lldb::WritableDataBufferSP
+  ReadMemory(const lldb::ProcessSP &process_sp, lldb::addr_t addr,
+ size_t byte_size);
 
   // This function returns raw file contents. Do not use it if you want
   // transparent decompression of section contents.

diff  --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 890db5c2748146..414ac6112d5797 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -419,19 +419,35 @@ ObjectFile *ObjectFileELF::CreateInstance(const 
lldb::ModuleSP &module_sp,
 ObjectFile *ObjectFileELF::CreateMemoryInstance(
 const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
 const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
-  if (data_sp && data_sp->GetByteSize() > (llvm::ELF::EI_NIDENT)) {
-const uint8_t *magic = data_sp->GetBytes();
-if (ELFHeader::MagicBytesMatch(magic)) {
-  unsigned address_size = ELFHeader::AddressSizeInBytes(magic);
-  if (address_size == 4 || address_size == 8) {
-std::unique_ptr objfile_up(
-new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
-ArchSpec spec = objfile_up->GetArchitecture();
-if (spec && objfile_up->SetModulesArchitecture(spec))
-  return objfile_up.release();
-  }
-}
-  }
+  if (!data_sp || data_sp->GetByteSize() < (llvm::ELF::EI_NIDENT))
+return nullptr;
+  const uint8_t *magic = data_sp->GetBytes();
+  if (!ELFHeader::MagicBytesMatch(magic))
+return nullptr;
+  // Read the ELF header first so we can figure out how many bytes we need
+  // to read to get as least the ELF header + program headers.
+  DataExtractor data;
+  data.SetData(data_sp);
+  elf::ELFHeader hdr;
+  lldb::offset_t offset = 0;
+  if (!hdr.Parse(data, &offset))
+return nullptr;
+
+  // Make sure the address size is set correctly in the ELF header.
+  if (!hdr.Is32Bit() && !hdr.Is64Bit())
+return nullptr;
+  // Figure out where the program headers end and read enough bytes to get the
+  // program headers in their entirety.
+  lldb::offset_t end_phdrs = hdr.e_phoff + (hdr.e_phentsize * hdr.e_phnum);
+  if (end_phdrs > data_sp->GetByteSize())
+data_sp = ReadMemory(process_sp, header_addr, end_phdrs);
+
+  std::unique_ptr objfile_up(
+  new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
+  ArchSpec spec = objfile_up->GetArchitecture();
+  if (spec && objfile_up->SetModulesArchitecture(spec))
+return objfile_up.release();
+
   return nullptr;
 }
 
@@ -873,42 +889,37 @@ Address ObjectFileELF:

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Greg Clayton via lldb-commits


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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

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

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

Here is the relevant piece of the build log for the reference:
```
Step 6 (test) failure: build (failure)
...
15.417 [1/3/86] Linking CXX executable 
tools/lldb/unittests/Platform/Android/AdbClientTests
16.057 [1/2/87] Linking CXX executable bin/lldb-test
16.544 [1/1/88] Linking CXX executable 
tools/lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests
16.544 [0/1/88] Running lldb lit test suite
llvm-lit: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/utils/lit/lit/llvm/config.py:508:
 note: using clang: /home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang
llvm-lit: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/utils/lit/lit/llvm/config.py:508:
 note: using ld.lld: /home/worker/2.0.1/lldb-x86_64-debian/build/bin/ld.lld
llvm-lit: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/utils/lit/lit/llvm/config.py:508:
 note: using lld-link: /home/worker/2.0.1/lldb-x86_64-debian/build/bin/lld-link
llvm-lit: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/utils/lit/lit/llvm/config.py:508:
 note: using ld64.lld: /home/worker/2.0.1/lldb-x86_64-debian/build/bin/ld64.lld
llvm-lit: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/llvm/utils/lit/lit/llvm/config.py:508:
 note: using wasm-ld: /home/worker/2.0.1/lldb-x86_64-debian/build/bin/wasm-ld
-- Testing: 2644 tests, 72 workers --
FAIL: lldb-api :: tools/lldb-dap/module/TestDAP_module.py (1 of 2644)
 TEST 'lldb-api :: tools/lldb-dap/module/TestDAP_module.py' 
FAILED 
Script:
--
/usr/bin/python3 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/dotest.py -u 
CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy 
--env LLVM_LIBS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./lib --env 
LLVM_INCLUDE_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/include --env 
LLVM_TOOLS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --arch x86_64 
--build-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/lldb --compiler 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin/clang --dsymutil 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin/dsymutil --llvm-tools-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --lldb-obj-root 
/home/worker/2.0.1/lldb-x86_64-debian/build/tools/lldb --lldb-libs-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/./lib -t 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/tools/lldb-dap/module
 -p TestDAP_module.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 20.0.0git (https://github.com/llvm/llvm-project.git revision 
28ba8a56b6fb9ec61897fa84369f46e43be94c03)
  clang revision 28ba8a56b6fb9ec61897fa84369f46e43be94c03
  llvm revision 28ba8a56b6fb9ec61897fa84369f46e43be94c03
Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 
'debugserver', 'objc']
= DEBUG ADAPTER PROTOCOL LOGS =
1723140734.310717583 --> 
Content-Length: 344

{
  "arguments": {
"adapterID": "lldb-native",
"clientID": "vscode",
"columnsStartAt1": true,
"linesStartAt1": true,
"locale": "en-us",
"pathFormat": "path",
"sourceInitFile": false,
"supportsRunInTerminalRequest": true,
"supportsStartDebuggingRequest": true,
"supportsVariablePaging": true,
"supportsVariableType": true
  },
  "command": "initialize",
  "seq": 1,
  "type": "request"
}
1723140734.312727451 <-- 
Content-Length: 1483


```

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

[Lldb-commits] [lldb] [lldb] Updated lldb-server to spawn the child process and share socket (PR #101283)

2024-08-08 Thread Dmitry Vasilyev via lldb-commits


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

>From 6b2a41ba3d71270e81e24a42d3b4f5dc2f96b939 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Wed, 31 Jul 2024 05:41:21 +0400
Subject: [PATCH 1/4] [lldb] Updated lldb-server to spawn the child process and
 share socket on Windows

`lldb-server platform --server` works on Windows now w/o multithreading. The 
rest functionality remains unchanged.

Depends on #101383.

Fixes #90923, fixes #56346.

This is the part 1 of the replacement of #100670.

In the part 2 I plan to switch `lldb-server gdbserver` to use `--fd` and listen 
a common gdb port for all gdbserver connections. Then we can remove gdb port 
mapping to fix #97537.
---
 lldb/tools/lldb-server/lldb-platform.cpp | 347 ---
 1 file changed, 306 insertions(+), 41 deletions(-)

diff --git a/lldb/tools/lldb-server/lldb-platform.cpp 
b/lldb/tools/lldb-server/lldb-platform.cpp
index 7148a1d2a30941..e23237ef574c30 100644
--- a/lldb/tools/lldb-server/lldb-platform.cpp
+++ b/lldb/tools/lldb-server/lldb-platform.cpp
@@ -22,6 +22,7 @@
 #include 
 
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
 
@@ -32,8 +33,10 @@
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/HostGetOpt.h"
 #include "lldb/Host/OptionParser.h"
+#include "lldb/Host/Socket.h"
 #include "lldb/Host/common/TCPSocket.h"
 #include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Status.h"
 
 using namespace lldb;
@@ -60,6 +63,9 @@ static struct option g_long_options[] = {
 {"max-gdbserver-port", required_argument, nullptr, 'M'},
 {"socket-file", required_argument, nullptr, 'f'},
 {"server", no_argument, &g_server, 1},
+#if defined(_WIN32)
+{"accept", required_argument, nullptr, 'a'},
+#endif
 {nullptr, 0, nullptr, 0}};
 
 #if defined(__APPLE__)
@@ -114,6 +120,249 @@ static Status save_socket_id_to_file(const std::string 
&socket_id,
   return status;
 }
 
+static void client_handle(GDBRemoteCommunicationServerPlatform &platform,
+  const lldb_private::Args &args) {
+  if (!platform.IsConnected())
+return;
+
+  if (args.GetArgumentCount() > 0) {
+lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
+std::optional port;
+std::string socket_name;
+Status error = platform.LaunchGDBServer(args,
+"", // hostname
+pid, port, socket_name);
+if (error.Success())
+  platform.SetPendingGdbServer(pid, *port, socket_name);
+else
+  fprintf(stderr, "failed to start gdbserver: %s\n", error.AsCString());
+  }
+
+  bool interrupt = false;
+  bool done = false;
+  Status error;
+  while (!interrupt && !done) {
+if (platform.GetPacketAndSendResponse(std::nullopt, error, interrupt,
+  done) !=
+GDBRemoteCommunication::PacketResult::Success)
+  break;
+  }
+
+  if (error.Fail())
+WithColor::error() << error.AsCString() << '\n';
+}
+
+static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
+static std::mutex gdbserver_portmap_mutex;
+
+#if defined(_WIN32)
+static void spawn_process_reaped(lldb::pid_t pid, int signal, int status) {
+  std::lock_guard guard(gdbserver_portmap_mutex);
+  gdbserver_portmap.FreePortForProcess(pid);
+}
+
+static bool spawn_process_parent(const char *progname, Connection *conn,
+ uint16_t gdb_port, uint16_t port_offset,
+ const lldb_private::Args &args,
+ const std::string &log_file,
+ const StringRef log_channels) {
+  Log *log = GetLog(LLDBLog::Platform);
+  Pipe socket_pipe;
+  Status error = socket_pipe.CreateNew(true);
+  if (error.Fail()) {
+LLDB_LOGF(log,
+  "lldb-platform parent: "
+  "cannot create pipe: %s",
+  error.AsCString());
+return false;
+  }
+
+  ProcessLaunchInfo launch_info;
+  FileSpec self_spec(progname, FileSpec::Style::native);
+  launch_info.SetExecutableFile(self_spec, true);
+  Args &self_args = launch_info.GetArguments();
+  self_args.AppendArgument(llvm::StringRef("platform"));
+  self_args.AppendArgument(llvm::StringRef("--accept"));
+  self_args.AppendArgument(llvm::to_string(socket_pipe.GetReadPipe()));
+  if (gdb_port) {
+self_args.AppendArgument(llvm::StringRef("--gdbserver-port"));
+self_args.AppendArgument(llvm::to_string(gdb_port));
+  }
+  if (port_offset > 0) {
+self_args.AppendArgument(llvm::StringRef("--port-offset"));
+self_args.AppendArgument(llvm::to_string(port_offset));
+  }
+  if (!log_file.empty()) {
+self_args.AppendArgument(llvm::StringRef("--log-file"));
+self_args.AppendArgument(log_file);
+  }
+  if (!log_channels.empty()) {
+self_args.AppendA

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)

2024-08-08 Thread Dmitri Gribenko via lldb-commits

gribozavr wrote:

> @gribozavr see #102510 for alternative.

Thank you! We are looking at this now.

> That's not really true. You only need to upstream the AST affecting parts. 
> The attributes itself and AST node which represent it.

The attributes are already upstream (we are reusing nullability attributes 
added by Apple), as I explained above. The C++-compatible pragma is missing - 
and I expect it to be a lot of work to reconcile. And even then, we still need 
to propagate the annotations - which currently happens within the ClangTidy 
check.

For example, we need to understand that the template parameter 0 of 
`std::vector` variable below is nullable:

```c++
std::vector> MakeVectorOfNullable();

void Test() {
  std::vector xs = MakeVectorOfNullable();
  *xs[0]; // warning
}
```

This propagation could happen within core Clang so that it can be integrated 
into the resugarer that constructs the AST, but doing so (injecting nullable 
annotations here) would have its own cost for the AST, and would require 
rearchitecting the check, to essentially run part of the logic during AST 
construction instead of inside of ClangTidy.

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

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

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

Here is the relevant piece of the build log for the reference:
```
Step 6 (test-build-unified-tree-check-cross-project) failure: test (failure)
 TEST 'cross-project-tests :: 
debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp' FAILED 

Exit Code: 1

Command Output (stderr):
--
RUN: at line 14: clang++ -O0 -glldb -std=gnu++11 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
+ clang++ -O0 -glldb -std=gnu++11 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
RUN: at line 15: not "/usr/bin/python3.10" 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py"
 test --fail-lt 1.0 -w --debugger lldb --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
 -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 | 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/FileCheck
 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
+ not /usr/bin/python3.10 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py
 test --fail-lt 1.0 -w --debugger lldb --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
 -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
+ 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/build/bin/FileCheck
 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
[1m/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp:34:16:
 [0m[0;1;31merror: [0m[1mCHECK-NEXT: expected string not found in input
[0m// CHECK-NEXT: (0x[[Y_VAL]]): step 4
[0;1;32m   ^
[0m[1m:37:20: [0m[0;1;30mnote: [0m[1mscanning from here
[0m misordered result:
[0;1;32m   ^
[0m[1m:37:20: [0m[0;1;30mnote: [0m[1mwith "Y_VAL" equal to 
"5556aed0"
[0m misordered result:
[0;1;32m   ^
[0m[1m:38:16: [0m[0;1;30mnote: [0m[1mpossible intended match here
[0m (0x5556aed0): step 6 [-3]
[0;1;32m   ^
[0m
Input file: 
Check file: 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp

-dump-input=help explains the following input dump.

Input was:
<<
[1m[0m[0;1;30m1: [0m[1m[0;1;46maddress_printing.cpp: (0.5714) 
[0m
[0;1;30m2: [0m[1m[0;1;46m [0m
[0;1;30m3: [0m[1m[0;1;46m## BEGIN ## [0m
[0;1;30m4: [0m[1m[0;1;46m[1, "main", 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp",
 38, 14, "StopReason.BREAKPOINT", "StepKind.FUNC", []] [0m
[0;1;30m5: [0m[1m[0;1;46m[2, "operator new(unsigned long)", 
null, 4294967295, 0, "StopReason.STEP", "StepKind.VERTICAL_FORWARD", []] [0m
[0;1;30m6: [0m[1m[0;1;46m[3, "main", 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu-dwarf5/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_prin

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

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

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

Here is the relevant piece of the build log for the reference:
```
Step 6 (test-build-unified-tree-check-cross-project) failure: test (failure)
 TEST 'cross-project-tests :: 
debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp' FAILED 

Exit Code: 1

Command Output (stderr):
--
RUN: at line 14: clang++ -O0 -glldb -std=gnu++11 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
+ clang++ -O0 -glldb -std=gnu++11 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 -o 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
RUN: at line 15: not "/usr/bin/python3.8" 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py"
 test --fail-lt 1.0 -w --debugger lldb --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
 -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
 | 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/FileCheck 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
+ not /usr/bin/python3.8 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/dexter.py
 test --fail-lt 1.0 -w --debugger lldb --binary 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/projects/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/Output/address_printing.cpp.tmp
 -v -- 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
+ 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/build/bin/FileCheck 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp
[1m/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp:34:16:
 [0m[0;1;31merror: [0m[1mCHECK-NEXT: expected string not found in input
[0m// CHECK-NEXT: (0x[[Y_VAL]]): step 4
[0;1;32m   ^
[0m[1m:37:20: [0m[0;1;30mnote: [0m[1mscanning from here
[0m misordered result:
[0;1;32m   ^
[0m[1m:37:20: [0m[0;1;30mnote: [0m[1mwith "Y_VAL" equal to 
"5556aed0"
[0m misordered result:
[0;1;32m   ^
[0m[1m:38:16: [0m[0;1;30mnote: [0m[1mpossible intended match here
[0m (0x5556aed0): step 6 [-3]
[0;1;32m   ^
[0m
Input file: 
Check file: 
/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp

-dump-input=help explains the following input dump.

Input was:
<<
[1m[0m[0;1;30m1: [0m[1m[0;1;46maddress_printing.cpp: (0.5714) 
[0m
[0;1;30m2: [0m[1m[0;1;46m [0m
[0;1;30m3: [0m[1m[0;1;46m## BEGIN ## [0m
[0;1;30m4: [0m[1m[0;1;46m[1, "main", 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp",
 38, 14, "StopReason.BREAKPOINT", "StepKind.FUNC", []] [0m
[0;1;30m5: [0m[1m[0;1;46m. [2, "operator new(unsigned long)", 
null, 4294967295, 0, "StopReason.STEP", "StepKind.FUNC_UNKNOWN", []] [0m
[0;1;30m6: [0m[1m[0;1;46m[3, "main", 
"/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/test/address_printing.cpp",
 39, 14, "StopReason.BREAKPOINT", "StepKind.VERTICAL_FORWARD", []] [0m
[0;1;30m7: [0m[1m[0;1;46m. [4, "operator

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread LLVM Continuous Integration via lldb-commits


llvm-ci wrote:

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

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

Here is the relevant piece of the build log for the reference:
```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: commands/command/script/add/TestAddParsedCommand.py (30 of 
2003)
PASS: lldb-api :: commands/command/script/import/TestImport.py (31 of 2003)
PASS: lldb-api :: commands/command/backticks/TestBackticksInAlias.py (32 of 
2003)
PASS: lldb-api :: 
commands/command/script/import/rdar-12586188/TestRdar12586188.py (33 of 2003)
PASS: lldb-api :: commands/command/script_alias/TestCommandScriptAlias.py (34 
of 2003)
PASS: lldb-api :: commands/command/source/TestCommandSource.py (35 of 2003)
PASS: lldb-api :: api/listeners/TestListener.py (36 of 2003)
PASS: lldb-api :: commands/disassemble/basic/TestDisassembleBreakpoint.py (37 
of 2003)
PASS: lldb-api :: commands/disassemble/basic/TestFrameDisassemble.py (38 of 
2003)
PASS: lldb-api :: commands/expression/calculator_mode/TestCalculatorMode.py (39 
of 2003)
FAIL: lldb-api :: 
commands/expression/anonymous-struct/TestCallUserAnonTypedef.py (40 of 2003)
 TEST 'lldb-api :: 
commands/expression/anonymous-struct/TestCallUserAnonTypedef.py' FAILED 

Script:
--
/usr/bin/python3.8 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py
 -u CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/local/bin/llvm-ar --env 
OBJCOPY=/usr/bin/llvm-objcopy --env 
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env 
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include 
--env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin 
--arch aarch64 --build-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb 
--compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang 
--dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil 
--llvm-tools-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin 
--lldb-obj-root /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb 
--lldb-libs-dir /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/commands/expression/anonymous-struct
 -p TestCallUserAnonTypedef.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 20.0.0git (https://github.com/llvm/llvm-project.git revision 
28ba8a56b6fb9ec61897fa84369f46e43be94c03)
  clang revision 28ba8a56b6fb9ec61897fa84369f46e43be94c03
  llvm revision 28ba8a56b6fb9ec61897fa84369f46e43be94c03
Skipping the following test categories: ['libc++', 'dsym', 'gmodules', 
'debugserver', 'objc']

--
Command Output (stderr):
--
UNSUPPORTED: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_dsym (TestCallUserAnonTypedef.TestExprLookupAnonStructTypedef) (test case 
does not fall in any category of interest for this run) 
FAIL: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_dwarf (TestCallUserAnonTypedef.TestExprLookupAnonStructTypedef)
FAIL: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_dwo (TestCallUserAnonTypedef.TestExprLookupAnonStructTypedef)
==
FAIL: test_dwarf (TestCallUserAnonTypedef.TestExprLookupAnonStructTypedef)
   Test typedeffed untagged struct arguments for function call expressions
--
Traceback (most recent call last):
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1758, in test_method
return attrvalue(self)
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/commands/expression/anonymous-struct/TestCallUserAnonTypedef.py",
 line 23, in test
self.expect_expr("multiply(&s)", result_type="double", result_value="1")
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2514, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 300, in check_value
test_base.assertSuccess(val.GetError())
  File 
"/home/tcwg-buildbot/worker/l

[Lldb-commits] [lldb] Reland "[lldb][ClangExpressionParser] Set BuiltinHeadersInSystemModules depending on SDK version (#102309)" (PR #102497)

2024-08-08 Thread Adrian Prantl via lldb-commits


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


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

[Lldb-commits] [lldb] 8334d2b - [lldb/Interpreter] Fix ambiguous partial command resolution (#101934)

2024-08-08 Thread via lldb-commits


Author: Med Ismail Bennani
Date: 2024-08-08T12:55:10-07:00
New Revision: 8334d2bfd34e2666db173269525d17352afa7bac

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

LOG: [lldb/Interpreter] Fix ambiguous partial command resolution (#101934)

This patch is a follow-up to #97263 that fix ambigous abbreviated
command resolution.

When multiple commands are resolved, instead of failing to pick a
command to
run, this patch changes to resolution logic to check if there is a
single
alias match and if so, it will run the alias instead of the other
matches.

This has as a side-effect that we don't need to make aliases for every
substring of aliases to support abbrivated alias resolution.

Signed-off-by: Med Ismail Bennani 

Added: 
lldb/test/API/functionalities/ambigous_commands/TestAmbiguousCommands.py
lldb/test/API/functionalities/ambigous_commands/categories

Modified: 
lldb/docs/use/tutorial.rst
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/Commands/CommandObjectCommands.cpp
lldb/source/Interpreter/CommandInterpreter.cpp

Removed: 




diff  --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst
index 22354c6720e14a..00e7befdd087a4 100644
--- a/lldb/docs/use/tutorial.rst
+++ b/lldb/docs/use/tutorial.rst
@@ -168,6 +168,10 @@ is more convenient to make the basic commands unique down 
to a letter or two,
 and then learn these sequences than to fill the namespace with lots of aliases,
 and then have to type them all the way out.
 
+If the alias abbreviation or the full alias command collides with another
+existing command, the command resolver will prefer to use the alias over any
+other command as far as there is only one alias command match.
+
 However, users are free to customize LLDB's command set however they like, and
 since LLDB reads the file ``~/.lldbinit`` at startup, you can store all your
 aliases there and they will be generally available to you. Your aliases are

diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 48f6618ab0e392..2bafc30cc8e23a 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -295,6 +295,10 @@ class CommandInterpreter : public Broadcaster,
   StringList *matches = nullptr,
   StringList *descriptions = nullptr) 
const;
 
+  CommandObject *
+  GetAliasCommandObject(llvm::StringRef cmd, StringList *matches = nullptr,
+StringList *descriptions = nullptr) const;
+
   /// Determine whether a root level, built-in command with this name exists.
   bool CommandExists(llvm::StringRef cmd) const;
 

diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index c63445b7c8c868..7c439f4ddb93e3 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -322,7 +322,13 @@ rather than using a positional placeholder:"
 
 (lldb) command alias bl3 breakpoint set -f %1 -l 3
 
-Always sets a breakpoint on line 3 of whatever file is indicated.)");
+Always sets a breakpoint on line 3 of whatever file is indicated.
+
+)"
+
+"If the alias abbreviation or the full alias command collides with 
another \
+existing command, the command resolver will prefer to use the alias over any \
+other command as far as there is only one alias command match.");
 
 CommandArgumentEntry arg1;
 CommandArgumentEntry arg2;

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 71c928ec811fc6..e45112530404b8 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -520,10 +520,6 @@ void CommandInterpreter::Initialize() {
 
   cmd_obj_sp = GetCommandSPExact("scripting run");
   if (cmd_obj_sp) {
-AddAlias("sc", cmd_obj_sp);
-AddAlias("scr", cmd_obj_sp);
-AddAlias("scri", cmd_obj_sp);
-AddAlias("scrip", cmd_obj_sp);
 AddAlias("script", cmd_obj_sp);
   }
 
@@ -1302,6 +1298,39 @@ CommandObject *CommandInterpreter::GetUserCommandObject(
   return {};
 }
 
+CommandObject *CommandInterpreter::GetAliasCommandObject(
+llvm::StringRef cmd, StringList *matches, StringList *descriptions) const {
+  auto find_exact =
+  [&](const CommandObject::CommandMap &map) -> CommandObject * {
+auto found_elem = map.find(cmd.str());
+if (found_elem == map.end())
+  return (CommandObject *)nullptr;
+CommandObject *exact_cmd = found_elem->second.get();
+if (!exact_cmd)
+  return nullptr;
+
+if (matches)
+  matches->AppendString(exact_cmd->

[Lldb-commits] [lldb] [lldb/Interpreter] Fix ambiguous partial command resolution (PR #101934)

2024-08-08 Thread Med Ismail Bennani via lldb-commits


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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Jonas Devlieghere via lldb-commits


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


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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)

2024-08-08 Thread Andrey Ali Khan Bolshakov via lldb-commits

bolshakov-a wrote:

> From past conversations with IWYU maintainer, this was desirable, since IWYU 
> rolls its own resugarer, which is faulty and difficult to maintain.

I just want to mention that, actually, IWYU doesn't probably need any resugarer 
at all. A type template argument as-written is needed just to decide whether 
its canonical type should be reported for `#include`ing or not (e.g. because 
the `typedef` author has provided it already). Another way to do it is to 
collect a list of types blocked for reporting before scanning the instantiated 
template. I started rewriting IWYU in that direction some time ago.

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Adrian Prantl via lldb-commits



@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));

adrian-prantl wrote:

LLVM_PRETTY_FUNCTION?

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Adrian Prantl via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb/Plugins] Introduce Scripted Platform Plugin (PR #99814)

2024-08-08 Thread via lldb-commits

jimingham wrote:

> To extend on Pavel's modification of my idea:
> 
> ```
> class ScriptedPlatform:
>   def extends_platform_name(self):
> '''Get the name of the internal platform this class extends.'''
> return "iPhoneOS.platform"
> ```
> 
> Then every function would have 3 variants:
> 
> ```
> def pre_XXX(...):
> def XXX(...)
> def post_XXX(...)
> ```
> 
> So for "attach_to_process" this would mean the possible functions are:
> 
> ```
> class ScriptedPlatform:
>   def pre_attach_to_process(self, ...):
> # Called before the extended platform default attach_to_process() 
> functionality
> # but only if `def extends_platform_name(self)` exists in this class. The 
> default
> # attach_to_process() from the extended platform will be called after 
> this function
> # completes.
> 
>   def attach_to_process(self, ...):
> # This will override the attach_to_process() functionality. Clients that 
> implement
> # this function should not override pre_attach_to_process() or 
> # post_attach_to_process() as everything can be done in this function.
> 
>   def post_attach_to_process(...)
> # Called after the extended platform's default attach_to_process() 
> functionality
> # but only if `def extends_platform_name(self)` exists in this class. 
> ```

If we were to do it this way, I would not have "attach_to_process" be the 
override of the underlying platform's method, because you could also have a 
scripted platform that extends nothing, and it would use attach_to_process but 
override nothing.  I think it would be clearer to have the "override" version 
explicitly state that it is that, so: `override_attach_to_process` rather than 
`attach_to_process`.

But again, if most of the things that we want the scripted platform to do are 
methods that really ought to be available in the SBPlatform API, then I think 
it would be much more straightforward to be able to have the scripted version 
just make an instance of the platform it wants to wrap, and do the dispatch 
itself.

I do think it would also be handy to be able to have a wrapping scripted 
platform override the name lookup of the platform it wraps as well.  You might 
have something special you wanted to do for you installation with say the 
`remote-macosx` platform in your environment, and it would be simpler if you 
could just tell people to install your scripted platform, and then just use 
`remote-macosx` as they were before.  That means we need to have a shadowing 
list (in the Debugger) of the scripted platforms, and also a way to ask for the 
"built-in" platform of that name.

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Felipe de Azevedo Piovezan via lldb-commits


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


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

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-08 Thread Jacob Lalonde via lldb-commits



@@ -1095,3 +1095,9 @@ bool ProcessElfCore::GetProcessInfo(ProcessInstanceInfo 
&info) {
   }
   return true;
 }
+
+const uint8_t *ProcessElfCore::PeekMemory(lldb::addr_t low, lldb::addr_t high,

Jlalond wrote:

Would an `ArrayRef` be better for reading from a core file?

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

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-08 Thread via lldb-commits


github-actions[bot] wrote:




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



You can test this locally with the following command:


``bash
darker --check --diff -r 
1248698e9bb2a0232eee53a72679ed5077190a90...d5d772504b0fa993aad704d392a7eb02c9c717c1
 lldb/test/API/python_api/find_in_memory/TestFindInMemoryCore.py 
lldb/test/API/python_api/find_in_memory/TestFindInMemory.py 
lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py 
lldb/test/API/python_api/find_in_memory/address_ranges_helper.py
``





View the diff from darker here.


``diff
--- TestFindInMemory.py 2024-08-08 20:32:32.00 +
+++ TestFindInMemory.py 2024-08-08 21:03:17.957135 +
@@ -27,11 +27,13 @@
 lldb.SBFileSpec("main.cpp"),
 )
 live_pi.frame = live_pi.thread.GetFrameAtIndex(0)
 self.assertTrue(live_pi.bp.IsValid())
 self.assertTrue(live_pi.process, PROCESS_IS_VALID)
-self.assertState(live_pi.process.GetState(), lldb.eStateStopped, 
PROCESS_STOPPED)
+self.assertState(
+live_pi.process.GetState(), lldb.eStateStopped, PROCESS_STOPPED
+)
 
 self.live_pi = live_pi
 
 def test_check_stack_pointer(self):
 """Make sure the 'stack_pointer' variable lives on the stack"""
@@ -43,11 +45,13 @@
 ).Success(),
 )
 
 stack_region = lldb.SBMemoryRegionInfo()
 self.assertTrue(
-
self.live_pi.process.GetMemoryRegionInfo(self.live_pi.frame.GetSP(), 
stack_region).Success(),
+self.live_pi.process.GetMemoryRegionInfo(
+self.live_pi.frame.GetSP(), stack_region
+).Success(),
 )
 
 self.assertEqual(variable_region, stack_region)
 
 def test_find_in_memory_ok(self):
--- TestFindRangesInMemory.py   2024-08-08 20:32:32.00 +
+++ TestFindRangesInMemory.py   2024-08-08 21:03:18.070071 +
@@ -27,11 +27,13 @@
 lldb.SBFileSpec("main.cpp"),
 )
 live_pi.frame = live_pi.thread.GetFrameAtIndex(0)
 self.assertTrue(live_pi.bp.IsValid())
 self.assertTrue(live_pi.process, PROCESS_IS_VALID)
-self.assertState(live_pi.process.GetState(), lldb.eStateStopped, 
PROCESS_STOPPED)
+self.assertState(
+live_pi.process.GetState(), lldb.eStateStopped, PROCESS_STOPPED
+)
 
 self.live_pi = live_pi
 
 def test_find_ranges_in_memory_two_matches(self):
 """Make sure two matches exist in the heap memory and the right 
address ranges are provided"""

``




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

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-08 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Miro Bucko (mbucko)


Changes

Summary:
The current implementation of 'Process::FindInMemory()' utilizes a slow 
ReadMemory() API to search for 1 byte at a time in memory. This new overload 
takes advantage of the fact that the process core is already loaded into 
memory, allowing for a direct and more efficient search.

Test Plan:
llvm-lit 
./llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemoryCore.py 
./llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py
 ./llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py

---

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


21 Files Affected:

- (modified) lldb/include/lldb/Symbol/ObjectFile.h (+7) 
- (modified) lldb/include/lldb/Target/PostMortemProcess.h (+18) 
- (modified) lldb/include/lldb/Target/Process.h (+30-2) 
- (modified) lldb/include/lldb/Target/ProcessTrace.h (+3) 
- (modified) lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp (+6) 
- (modified) lldb/source/Plugins/Process/elf-core/ProcessElfCore.h (+3-7) 
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp (+6) 
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.h (+3-7) 
- (modified) lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp (+11) 
- (modified) lldb/source/Plugins/Process/minidump/ProcessMinidump.h (+3) 
- (modified) lldb/source/Symbol/ObjectFile.cpp (+12) 
- (modified) lldb/source/Target/CMakeLists.txt (+1) 
- (added) lldb/source/Target/PostMortemProcess.cpp (+80) 
- (modified) lldb/source/Target/Process.cpp (+3-25) 
- (modified) lldb/source/Target/ProcessTrace.cpp (+6) 
- (modified) lldb/test/API/python_api/find_in_memory/TestFindInMemory.py 
(+27-40) 
- (added) lldb/test/API/python_api/find_in_memory/TestFindInMemoryCore.py 
(+295) 
- (modified) lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py 
(+35-64) 
- (modified) lldb/test/API/python_api/find_in_memory/address_ranges_helper.py 
(+53-36) 
- (added) lldb/test/API/python_api/find_in_memory/linux-x86_64.yaml (+101) 
- (modified) lldb/test/API/python_api/find_in_memory/main.cpp (+2-2) 


``diff
diff --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index d89314d44bf671..fac35167a7c764 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -669,6 +669,13 @@ class ObjectFile : public 
std::enable_shared_from_this,
   // transparent decompression of section contents.
   size_t CopyData(lldb::offset_t offset, size_t length, void *dst) const;
 
+  // Returns a pointer to the data at the specified offset. If the offset is
+  // invalid, this function will return nullptr. The 'available_bytes' argument
+  // will be set to the number of bytes available at the given offset, which
+  // will be at most 'length' bytes.
+  const uint8_t *PeekData(lldb::addr_t offset, size_t length,
+  size_t &available_bytes) const;
+
   // This function will transparently decompress section data if the section if
   // compressed.
   virtual size_t ReadSectionData(Section *section,
diff --git a/lldb/include/lldb/Target/PostMortemProcess.h 
b/lldb/include/lldb/Target/PostMortemProcess.h
index 9c9cd7fa599bc3..a589adda93fe91 100644
--- a/lldb/include/lldb/Target/PostMortemProcess.h
+++ b/lldb/include/lldb/Target/PostMortemProcess.h
@@ -10,6 +10,7 @@
 #define LLDB_TARGET_POSTMORTEMPROCESS_H
 
 #include "lldb/Target/Process.h"
+#include "lldb/Utility/RangeMap.h"
 
 namespace lldb_private {
 
@@ -33,6 +34,23 @@ class PostMortemProcess : public Process {
   FileSpec GetCoreFile() const override { return m_core_file; }
 
 protected:
+  typedef lldb_private::Range FileRange;
+  typedef lldb_private::RangeDataVector
+  VMRangeToFileOffset;
+  typedef lldb_private::RangeDataVector
+  VMRangeToPermissions;
+
+  virtual const uint8_t *PeekMemory(lldb::addr_t low, lldb::addr_t high,
+size_t &size) = 0;
+
+  lldb::addr_t FindInMemory(lldb::addr_t low, lldb::addr_t high,
+const uint8_t *buf, size_t size) override;
+
+  const uint8_t *DoPeekMemory(lldb::ModuleSP &core_module_sp,
+  VMRangeToFileOffset &core_aranges,
+  lldb::addr_t low, lldb::addr_t high,
+  size_t &available_bytes);
+
   FileSpec m_core_file;
 };
 
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index cf16fbc812aa48..51dba5b36a21c0 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -2703,8 +2703,8 @@ void PruneThreadPlans();
   ///
   /// \return The address where the pattern was found or LLDB_INVALID_ADDRESS 
if
   /// not found.
-  lldb::addr_t FindInMemory(lldb::addr_t low, lldb::addr_t high,
-

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Alex Langford via lldb-commits


https://github.com/bulbazord created 
https://github.com/llvm/llvm-project/pull/102539

This class is technically not usable in its current state. When you use it in a 
simple C++ project, your compiler will complain about an incomplete definition 
of SaveCoreOptions. Normally this isn't a problem, other classes in the SBAPI 
do this. The difference is that SBSaveCoreOptions has a default destructor in 
the header, so the compiler will attempt to generate the code for the 
destructor with an incomplete definition of the impl type.

All methods for every class, including constructors and destructors, must have 
a separate implementation not in a header.

>From 293db75e2e4d20e213de5ff9b1c5a06cfc169089 Mon Sep 17 00:00:00 2001
From: Alex Langford 
Date: Thu, 8 Aug 2024 14:13:09 -0700
Subject: [PATCH] [lldb] Move definition of SBSaveCoreOptions dtor out of
 header

This class is technically not usable in its current state. When you use
it in a simple C++ project, your compiler will complain about an
incomplete definition of SaveCoreOptions. Normally this isn't a problem,
other classes in the SBAPI do this. The difference is that
SBSaveCoreOptions has a default destructor in the header, so the
compiler will attempt to generate the code for the destructor with an
incomplete definition of the impl type.

All methods for every class, including constructors and destructors, must
not have an implementation in the header.
---
 lldb/include/lldb/API/SBSaveCoreOptions.h | 2 +-
 lldb/source/API/SBSaveCoreOptions.cpp | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/lldb/include/lldb/API/SBSaveCoreOptions.h 
b/lldb/include/lldb/API/SBSaveCoreOptions.h
index e77496bd3a4a0d..75506fd752e762 100644
--- a/lldb/include/lldb/API/SBSaveCoreOptions.h
+++ b/lldb/include/lldb/API/SBSaveCoreOptions.h
@@ -17,7 +17,7 @@ class LLDB_API SBSaveCoreOptions {
 public:
   SBSaveCoreOptions();
   SBSaveCoreOptions(const lldb::SBSaveCoreOptions &rhs);
-  ~SBSaveCoreOptions() = default;
+  ~SBSaveCoreOptions();
 
   const SBSaveCoreOptions &operator=(const lldb::SBSaveCoreOptions &rhs);
 
diff --git a/lldb/source/API/SBSaveCoreOptions.cpp 
b/lldb/source/API/SBSaveCoreOptions.cpp
index 6c3f74596203d6..19ca83f932bcf1 100644
--- a/lldb/source/API/SBSaveCoreOptions.cpp
+++ b/lldb/source/API/SBSaveCoreOptions.cpp
@@ -29,6 +29,8 @@ SBSaveCoreOptions::SBSaveCoreOptions(const SBSaveCoreOptions 
&rhs) {
   m_opaque_up = clone(rhs.m_opaque_up);
 }
 
+SBSaveCoreOptions::~SBSaveCoreOptions() = default;
+
 const SBSaveCoreOptions &
 SBSaveCoreOptions::operator=(const SBSaveCoreOptions &rhs) {
   LLDB_INSTRUMENT_VA(this, rhs);

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Alex Langford (bulbazord)


Changes

This class is technically not usable in its current state. When you use it in a 
simple C++ project, your compiler will complain about an incomplete definition 
of SaveCoreOptions. Normally this isn't a problem, other classes in the SBAPI 
do this. The difference is that SBSaveCoreOptions has a default destructor in 
the header, so the compiler will attempt to generate the code for the 
destructor with an incomplete definition of the impl type.

All methods for every class, including constructors and destructors, must have 
a separate implementation not in a header.

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


2 Files Affected:

- (modified) lldb/include/lldb/API/SBSaveCoreOptions.h (+1-1) 
- (modified) lldb/source/API/SBSaveCoreOptions.cpp (+2) 


``diff
diff --git a/lldb/include/lldb/API/SBSaveCoreOptions.h 
b/lldb/include/lldb/API/SBSaveCoreOptions.h
index e77496bd3a4a0d..75506fd752e762 100644
--- a/lldb/include/lldb/API/SBSaveCoreOptions.h
+++ b/lldb/include/lldb/API/SBSaveCoreOptions.h
@@ -17,7 +17,7 @@ class LLDB_API SBSaveCoreOptions {
 public:
   SBSaveCoreOptions();
   SBSaveCoreOptions(const lldb::SBSaveCoreOptions &rhs);
-  ~SBSaveCoreOptions() = default;
+  ~SBSaveCoreOptions();
 
   const SBSaveCoreOptions &operator=(const lldb::SBSaveCoreOptions &rhs);
 
diff --git a/lldb/source/API/SBSaveCoreOptions.cpp 
b/lldb/source/API/SBSaveCoreOptions.cpp
index 6c3f74596203d6..19ca83f932bcf1 100644
--- a/lldb/source/API/SBSaveCoreOptions.cpp
+++ b/lldb/source/API/SBSaveCoreOptions.cpp
@@ -29,6 +29,8 @@ SBSaveCoreOptions::SBSaveCoreOptions(const SBSaveCoreOptions 
&rhs) {
   m_opaque_up = clone(rhs.m_opaque_up);
 }
 
+SBSaveCoreOptions::~SBSaveCoreOptions() = default;
+
 const SBSaveCoreOptions &
 SBSaveCoreOptions::operator=(const SBSaveCoreOptions &rhs) {
   LLDB_INSTRUMENT_VA(this, rhs);

``




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

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-08 Thread Jacob Lalonde via lldb-commits



@@ -111,6 +111,9 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
 
   bool SupportsMemoryTagging() override { return !m_core_tag_ranges.IsEmpty(); 
}
 
+  const uint8_t *PeekMemory(lldb::addr_t low, lldb::addr_t high,

Jlalond wrote:

Same ArrayRef preference

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Felipe de Azevedo Piovezan via lldb-commits


felipepiovezan wrote:

LGTM! Good catch!

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Jacob Lalonde via lldb-commits


Jlalond wrote:

Great catch @bulbazord!

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Alex Langford via lldb-commits


bulbazord wrote:

This will need a cherry-pick to release/19.x after it lands.

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Med Ismail Bennani via lldb-commits


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

LGTM!

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Adrian Prantl via lldb-commits


adrian-prantl wrote:

@clayborg Based on the blamelist in 
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/9352/ this 
broke 
[lldb-api.functionalities/gdb_remote_client.TestGdbClientModuleLoad.py](https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/9352/testReport/junit/lldb-api/functionalities_gdb_remote_client/TestGdbClientModuleLoad_py/)
Can you investigate/revert?

thanks!

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

[Lldb-commits] [lldb] [lldb] Move definition of SBSaveCoreOptions dtor out of header (PR #102539)

2024-08-08 Thread Greg Clayton via lldb-commits


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


https://github.com/llvm/llvm-project/pull/102539
___
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)

2024-08-08 Thread 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) {

jimingham wrote:

I didn't look further into the code to see if you actually treat ValueObjects 
this way, but just to make sure this is clear, IsValid is a necessary but not 
sufficient check to see whether you can use an ValueObject.  You also have to 
check GetError().Success().  If you think about the case of a variable request 
for a variable that is defined in the block containing the PC, but is optimized 
out at the current PC.  That is a valid SBValue, since it carries a useful 
error and might have a value after you step again.  But it doesn't have a value 
you can use at this stop.


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)

2024-08-08 Thread via lldb-commits


https://github.com/jimingham 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)

2024-08-08 Thread via lldb-commits


https://github.com/jimingham 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)

2024-08-08 Thread via lldb-commits


https://github.com/jimingham 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] 1d9e1c6 - Revert "[LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (#101237)"

2024-08-08 Thread Leonard Chan via lldb-commits


Author: Leonard Chan
Date: 2024-08-08T23:05:23Z
New Revision: 1d9e1c6644a03530efbb09d419013ec0bfe0c823

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

LOG: Revert "[LLDB] Impove ObjectFileELF's .dynamic parsing and usage. 
(#101237)"

This reverts commit 28ba8a56b6fb9ec61897fa84369f46e43be94c03.

Reverting since this broke the buildbot at
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/9352/.

Added: 


Modified: 
lldb/include/lldb/Symbol/ObjectFile.h
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
lldb/source/Symbol/ObjectFile.cpp

Removed: 
lldb/test/Shell/ObjectFile/ELF/Inputs/memory-elf.cpp
lldb/test/Shell/ObjectFile/ELF/elf-dynamic-no-shdrs.yaml
lldb/test/Shell/ObjectFile/ELF/elf-memory.test



diff  --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index d89314d44bf671..8592323322e383 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -656,9 +656,8 @@ class ObjectFile : public 
std::enable_shared_from_this,
   // When an object file is in memory, subclasses should try and lock the
   // process weak pointer. If the process weak pointer produces a valid
   // ProcessSP, then subclasses can call this function to read memory.
-  static lldb::WritableDataBufferSP
-  ReadMemory(const lldb::ProcessSP &process_sp, lldb::addr_t addr,
- size_t byte_size);
+  static lldb::DataBufferSP ReadMemory(const lldb::ProcessSP &process_sp,
+   lldb::addr_t addr, size_t byte_size);
 
   // This function returns raw file contents. Do not use it if you want
   // transparent decompression of section contents.

diff  --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 414ac6112d5797..890db5c2748146 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -419,35 +419,19 @@ ObjectFile *ObjectFileELF::CreateInstance(const 
lldb::ModuleSP &module_sp,
 ObjectFile *ObjectFileELF::CreateMemoryInstance(
 const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
 const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
-  if (!data_sp || data_sp->GetByteSize() < (llvm::ELF::EI_NIDENT))
-return nullptr;
-  const uint8_t *magic = data_sp->GetBytes();
-  if (!ELFHeader::MagicBytesMatch(magic))
-return nullptr;
-  // Read the ELF header first so we can figure out how many bytes we need
-  // to read to get as least the ELF header + program headers.
-  DataExtractor data;
-  data.SetData(data_sp);
-  elf::ELFHeader hdr;
-  lldb::offset_t offset = 0;
-  if (!hdr.Parse(data, &offset))
-return nullptr;
-
-  // Make sure the address size is set correctly in the ELF header.
-  if (!hdr.Is32Bit() && !hdr.Is64Bit())
-return nullptr;
-  // Figure out where the program headers end and read enough bytes to get the
-  // program headers in their entirety.
-  lldb::offset_t end_phdrs = hdr.e_phoff + (hdr.e_phentsize * hdr.e_phnum);
-  if (end_phdrs > data_sp->GetByteSize())
-data_sp = ReadMemory(process_sp, header_addr, end_phdrs);
-
-  std::unique_ptr objfile_up(
-  new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
-  ArchSpec spec = objfile_up->GetArchitecture();
-  if (spec && objfile_up->SetModulesArchitecture(spec))
-return objfile_up.release();
-
+  if (data_sp && data_sp->GetByteSize() > (llvm::ELF::EI_NIDENT)) {
+const uint8_t *magic = data_sp->GetBytes();
+if (ELFHeader::MagicBytesMatch(magic)) {
+  unsigned address_size = ELFHeader::AddressSizeInBytes(magic);
+  if (address_size == 4 || address_size == 8) {
+std::unique_ptr objfile_up(
+new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
+ArchSpec spec = objfile_up->GetArchitecture();
+if (spec && objfile_up->SetModulesArchitecture(spec))
+  return objfile_up.release();
+  }
+}
+  }
   return nullptr;
 }
 
@@ -889,37 +873,42 @@ Address ObjectFileELF::GetImageInfoAddress(Target 
*target) {
   if (!section_list)
 return Address();
 
-  for (size_t i = 0; i < m_dynamic_symbols.size(); ++i) {
-const ELFDynamic &symbol = m_dynamic_symbols[i].symbol;
+  // Find the SHT_DYNAMIC (.dynamic) section.
+  SectionSP dynsym_section_sp(
+  section_list->FindSectionByType(eSectionTypeELFDynamicLinkInfo, true));
+  if (!dynsym_section_sp)
+return Address();
+  assert(dynsym_section_sp->GetObjectFile() == this);
 
-if (symbol.d_tag != DT_DEBUG && symbol.d_tag != DT_MIPS_RLD_MAP &&
-symbol.d_tag != DT_MIPS_RLD_MAP_REL)
-  continue;
+  user_id

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Greg Clayton via lldb-commits


clayborg wrote:

I am on it!

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

[Lldb-commits] [lldb] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers from PlatformDarwin into Platform (PR #102488)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From 99dd6c9d974ffd95f3c2aed9dfb2a861cc55f084 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:07:21 +0100
Subject: [PATCH 1/3] [lldb][Platform] Move the GetSDKPathFromDebugInfo helpers
 from PlatformDarwin into Platform

This will soon be needed for
https://github.com/llvm/llvm-project/pull/102309, where we
plan on calling these APIs from generic ExpressionParser code.
---
 lldb/include/lldb/Target/Platform.h   | 34 +++
 .../Plugins/Platform/MacOSX/PlatformDarwin.h  | 31 +++--
 2 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 5ed2fc33356d9d..8cf52a486e2c87 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -27,6 +27,7 @@
 #include "lldb/Utility/StructuredData.h"
 #include "lldb/Utility/Timeout.h"
 #include "lldb/Utility/UserIDResolver.h"
+#include "lldb/Utility/XcodeSDK.h"
 #include "lldb/lldb-private-forward.h"
 #include "lldb/lldb-public.h"
 
@@ -436,6 +437,39 @@ class Platform : public PluginInterface {
 return lldb_private::ConstString();
   }
 
+  /// Search each CU associated with the specified 'module' for
+  /// the SDK paths the CUs were compiled against. In the presence
+  /// of different SDKs, we try to pick the most appropriate one
+  /// using \ref XcodeSDK::Merge.
+  ///
+  /// \param[in] module Module whose debug-info CUs to parse for
+  ///   which SDK they were compiled against.
+  ///
+  /// \returns If successful, returns a pair of a parsed XcodeSDK
+  ///  object and a boolean that is 'true' if we encountered
+  ///  a conflicting combination of SDKs when parsing the CUs
+  ///  (e.g., a public and internal SDK).
+  virtual llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
+  /// Returns the full path of the most appropriate SDK for the
+  /// specified 'module'. This function gets this path by parsing
+  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
+  ///
+  /// \param[in] module Module whose debug-info to parse for
+  ///   which SDK it was compiled against.
+  ///
+  /// \returns If successful, returns the full path to an
+  ///  Xcode SDK.
+  virtual llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) {
+return llvm::createStringError(llvm::formatv(
+"{0} not implemented for '{1}' platform.", __func__, GetName()));
+  }
+
   const std::string &GetRemoteURL() const { return m_remote_url; }
 
   bool IsHost() const {
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
index ff7087da6825d9..66a26d2f496776 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
@@ -124,32 +124,11 @@ class PlatformDarwin : public PlatformPOSIX {
   /// located in.
   static FileSpec GetCurrentCommandLineToolsDirectory();
 
-  /// Search each CU associated with the specified 'module' for
-  /// the SDK paths the CUs were compiled against. In the presence
-  /// of different SDKs, we try to pick the most appropriate one
-  /// using \ref XcodeSDK::Merge.
-  ///
-  /// \param[in] module Module whose debug-info CUs to parse for
-  ///   which SDK they were compiled against.
-  ///
-  /// \returns If successful, returns a pair of a parsed XcodeSDK
-  ///  object and a boolean that is 'true' if we encountered
-  ///  a conflicting combination of SDKs when parsing the CUs
-  ///  (e.g., a public and internal SDK).
-  static llvm::Expected>
-  GetSDKPathFromDebugInfo(Module &module);
-
-  /// Returns the full path of the most appropriate SDK for the
-  /// specified 'module'. This function gets this path by parsing
-  /// debug-info (see \ref `GetSDKPathFromDebugInfo`).
-  ///
-  /// \param[in] module Module whose debug-info to parse for
-  ///   which SDK it was compiled against.
-  ///
-  /// \returns If successful, returns the full path to an
-  ///  Xcode SDK.
-  static llvm::Expected
-  ResolveSDKPathFromDebugInfo(Module &module);
+  llvm::Expected>
+  GetSDKPathFromDebugInfo(Module &module) override;
+
+  llvm::Expected
+  ResolveSDKPathFromDebugInfo(Module &module) override;
 
 protected:
   static const char *GetCompatibleArch(ArchSpec::Core core, size_t idx);

>From 7f560914c7ffd0521c093d1bea9e424b1dfbfc06 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Thu, 8 Aug 2024 16:32:53 +0100
Subject: [PATCH 2/3] fixup! fix unit-test build

---
 .../SymbolFile/DWARF/XcodeSDKModuleTests.cpp | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lldb/unitte

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

2024-08-08 Thread 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) {

cmtice wrote:

Ack.

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] Support new libc++ __compressed_pair layout (PR #96538)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From 16ae2c3c04d908807d78224a8fee34f772a337fa 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] [WIP][lldb][test] Add a new __compressed_pair layout to libcxx simulator tests (PR #99012)

2024-08-08 Thread Michael Buch via lldb-commits


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

>From e3ec030cb404c407ead39b10d5ea0baa4a0683ff Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 10 Jul 2024 15:37:45 +0100
Subject: [PATCH 1/4] [WIP][lldb][test] Add a new __compressed_pair layout to
 libcxx simulator tests

---
 .../compressed_pair.h | 34 ++-
 .../TestDataFormatterLibcxxStringSimulator.py | 19 ++-
 .../libcxx-simulators/string/main.cpp | 33 +++---
 ...stDataFormatterLibcxxUniquePtrSimulator.py | 14 ++--
 .../libcxx-simulators/unique_ptr/main.cpp |  5 +++
 5 files changed, 81 insertions(+), 24 deletions(-)

diff --git 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
index 026e7183ab27a..f2c1b626bd46f 100644
--- 
a/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
+++ 
b/lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
@@ -7,7 +7,7 @@
 namespace std {
 namespace __lldb {
 
-// Post-c88580c layout
+#if COMPRESSED_PAIR_REV == 0 // Post-c88580c layout
 struct __value_init_tag {};
 struct __default_init_tag {};
 
@@ -52,6 +52,38 @@ class __compressed_pair : private 
__compressed_pair_elem<_T1, 0>,
 
   _T1 &first() { return static_cast<_Base1 &>(*this).__get(); }
 };
+#elif COMPRESSED_PAIR_REV == 1
+template  class __compressed_pair_padding {
+  char __padding_[(is_empty<_ToPad>::value && 
!__libcpp_is_final<_ToPad>::value)
+  ? 0
+  : sizeof(_ToPad) - __datasizeof(_ToPad)];
+};
+
+#define _LLDB_COMPRESSED_PAIR(T1, Initializer1, T2, Initializer2)  
\
+  [[__gnu__::__aligned__(alignof(T2))]] [[no_unique_address]] T1 Initializer1; 
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_;
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Initializer1, T2, Initializer2, T3,
\
+Initializer3)  
\
+  [[using __gnu__: __aligned__(alignof(T2)),   
\
+__aligned__(alignof(T3))]] [[no_unique_address]] T1 Initializer1;  
\
+  [[no_unique_address]] __compressed_pair_padding __padding1_; 
\
+  [[no_unique_address]] T2 Initializer2;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding2_; 
\
+  [[no_unique_address]] T3 Initializer3;   
\
+  [[no_unique_address]] __compressed_pair_padding __padding3_;
+#elif COMPRESSED_PAIR_REV == 2
+#define _LLDB_COMPRESSED_PAIR(T1, Name1, T2, Name2)
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2
+
+#define _LLDB_COMPRESSED_TRIPLE(T1, Name1, T2, Name2, T3, Name3)   
\
+  [[no_unique_address]] T1 Name1;  
\
+  [[no_unique_address]] T2 Name2;  
\
+  [[no_unique_address]] T3 Name3
+#endif
 } // namespace __lldb
 } // namespace std
 
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
index 3e5c493692c4f..0d4270ef58568 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/TestDataFormatterLibcxxStringSimulator.py
@@ -25,12 +25,13 @@ def _run_test(self, defines):
 
 for v in [None, "ALTERNATE_LAYOUT"]:
 for r in range(5):
-name = "test_r%d" % r
-defines = ["REVISION=%d" % r]
-if v:
-name += "_" + v
-defines += [v]
-f = functools.partialmethod(
-LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
-)
-setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
+for c in range(3):
+name = "test_r%d_c%d" % (r, c)
+defines = ["REVISION=%d" % r, "COMPRESSED_PAIR_REV=%d" % c]
+if v:
+name += "_" + v
+defines += [v]
+f = functools.partialmethod(
+LibcxxStringDataFormatterSimulatorTestCase._run_test, defines
+)
+setattr(LibcxxStringDataFormatterSimulatorTestCase, name, f)
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/string/main

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Greg Clayton via lldb-commits


clayborg wrote:

I have identified the issue: with the new changes we are not successfully 
getting the address of the DT_DEBUG when calling:
```
Address ObjectFileELF::GetImageInfoAddress(Target *target);
```
Working on a fix.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

2024-08-08 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

> > Thanks @DavidSpickett just to be sure, this is armv7 right, not AArch32?
> 
> This is an AArch32 container on Armv8. I'm not sure if lldb-server knows the 
> difference though. Maybe it doesn't need to, and ptrace single step is done 
> in the kernel which uses the h/w step.
> 

Yeah I'm thinking lldb-server probably does a software instruction step on 
AArch32, even thought the hardware has instruction-step. Probably a small 
enough perf hit that there's little value in looking into that further.

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

[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

2024-08-08 Thread Jason Molenda via lldb-commits


jasonmolenda wrote:

The problem I now have is that debugserver doesn't do this nice behavior that 
lldb-server does, recognizing that a thread was instruction-stepping and 
rewriting the stop-reason as "trace" when it was actually "breakpoint-hit".  I 
can't update the debugserver on the armv7 watches, and we need to support 
debugging on them for a while to come.  I may need to make a generic code 
change where Thread::GetTemporaryResumeState can return both eStateStepping and 
its original pc it started the step from, only for the armv7 debugservers.  
With that small fix to `NativeProcessLinux::MonitorBreakpoint` outlined above, 
it should report the correct stop reason all by itself in this case.

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #101237)

2024-08-08 Thread Greg Clayton via lldb-commits


clayborg wrote:

I found the fix. Will have it in in a few minutes.

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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [clang] Reland: Instantiate alias templates with sugar (PR #101858)

2024-08-08 Thread Younan Zhang via lldb-commits

zyn0217 wrote:

> or if we would implement a `TypeAliasTemplateSpecializationDecl` only for the 
> benefit of external resugarers.

It is not only valuable to external resugarers. Another point that warrants an 
introduction of it is for unevaluated lambdas. These lambdas e.g. appearing as 
part of the `using Alias = decltype(lambda)` could carry a requires expression 
and thus evaluating it requires the recovery of the instantiating template 
arguments for the type alias, which isn't a quite natural thing without such a 
Decl. I have improved some of these situations through an on-stack 
InstantiatingTemplate to help to inspect the template arguments; however, that 
approach is somewhat cumbersome and still couldn't extend to other scenarios 
e.g. mangling these lambdas. 
(https://github.com/llvm/llvm-project/issues/97024. We need a correct 
DeclContext for the lambda, yet a `TypeAliasTemplateDecl` isn't a DeclContext, 
unfortunately.)

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

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

2024-08-08 Thread Miro Bucko via lldb-commits



@@ -2835,6 +2835,34 @@ void PruneThreadPlans();
   AddressRanges &matches, size_t alignment,
   size_t max_matches);
 
+  template 
+  lldb::addr_t FindInMemoryGeneric(IT &&iterator, lldb::addr_t low,
+   lldb::addr_t high, const uint8_t *buf,
+   size_t size) {
+const size_t region_size = high - low;
+
+if (region_size < size)
+  return LLDB_INVALID_ADDRESS;
+
+std::vector bad_char_heuristic(256, size);
+
+for (size_t idx = 0; idx < size - 1; idx++) {
+  decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
+  bad_char_heuristic[bcu_idx] = size - idx - 1;
+}
+for (size_t s = 0; s <= (region_size - size);) {
+  int64_t j = size - 1;
+  while (j >= 0 && buf[j] == iterator[s + j])
+j--;
+  if (j < 0)
+return low + s;
+  else
+s += bad_char_heuristic[iterator[s + size - 1]];
+}
+
+return LLDB_INVALID_ADDRESS;
+  }
+

mbucko wrote:

[NFC] Moved from 'Process::FindInMemory()'

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

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #102570)

2024-08-08 Thread Greg Clayton via lldb-commits


https://github.com/clayborg created 
https://github.com/llvm/llvm-project/pull/102570


https://github.com/llvm/llvm-project/pull/101237 got reverted due to 
buildbot failures. Opening a new PR to submit this again with a fix.

This patch improves the ability of a ObjectFileELF instance to read the 
.dynamic section. It adds the ability to read the .dynamic section from the 
PT_DYNAMIC program header which is useful for ELF files that have no section 
headers and for ELF files that are read from memory. It cleans up the usage of 
the .dynamic entries so that ObjectFileELF::ParseDynamicSymbols() is the only 
code that parses .dynamic entries, teaches that function the read and store the 
string values for each .dynamic entry. We now dump the .dynamic entries in the 
output of "image dump objfile". It also cleans up the code that gets the 
dynamic string table so that it can grab it from the DT_STRTAB and DT_STRSZ 
.dynamic entries for when we have a ELF file with no section headers or we are 
reading it from memory.

>From 706ef86564ae7be4e4d1c671f438fc6bd2d8c69c Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Thu, 8 Aug 2024 22:18:32 -0700
Subject: [PATCH 1/2] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage.

https://github.com/llvm/llvm-project/pull/101237 got reverted due to buildbot 
failures. Opening a new PR to submit this again with a fix.

This patch improves the ability of a ObjectFileELF instance to read the 
.dynamic section. It adds the ability to read the .dynamic section from the 
PT_DYNAMIC program header which is useful for ELF files that have no section 
headers and for ELF files that are read from memory. It cleans up the usage of 
the .dynamic entries so that ObjectFileELF::ParseDynamicSymbols() is the only 
code that parses .dynamic entries, teaches that function the read and store the 
string values for each .dynamic entry. We now dump the .dynamic entries in the 
output of "image dump objfile". It also cleans up the code that gets the 
dynamic string table so that it can grab it from the DT_STRTAB and DT_STRSZ 
.dynamic entries for when we have a ELF file with no section headers or we are 
reading it from memory.
---
 lldb/include/lldb/Symbol/ObjectFile.h |   5 +-
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  | 422 +-
 .../Plugins/ObjectFile/ELF/ObjectFileELF.h|  35 +-
 lldb/source/Symbol/ObjectFile.cpp |   7 +-
 .../ObjectFile/ELF/Inputs/memory-elf.cpp  |   5 +
 .../ObjectFile/ELF/elf-dynamic-no-shdrs.yaml  |  90 
 .../test/Shell/ObjectFile/ELF/elf-memory.test |  55 +++
 7 files changed, 493 insertions(+), 126 deletions(-)
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/Inputs/memory-elf.cpp
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/elf-dynamic-no-shdrs.yaml
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/elf-memory.test

diff --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index 8592323322e383..d89314d44bf671 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -656,8 +656,9 @@ class ObjectFile : public 
std::enable_shared_from_this,
   // When an object file is in memory, subclasses should try and lock the
   // process weak pointer. If the process weak pointer produces a valid
   // ProcessSP, then subclasses can call this function to read memory.
-  static lldb::DataBufferSP ReadMemory(const lldb::ProcessSP &process_sp,
-   lldb::addr_t addr, size_t byte_size);
+  static lldb::WritableDataBufferSP
+  ReadMemory(const lldb::ProcessSP &process_sp, lldb::addr_t addr,
+ size_t byte_size);
 
   // This function returns raw file contents. Do not use it if you want
   // transparent decompression of section contents.
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 890db5c2748146..414ac6112d5797 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -419,19 +419,35 @@ ObjectFile *ObjectFileELF::CreateInstance(const 
lldb::ModuleSP &module_sp,
 ObjectFile *ObjectFileELF::CreateMemoryInstance(
 const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
 const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
-  if (data_sp && data_sp->GetByteSize() > (llvm::ELF::EI_NIDENT)) {
-const uint8_t *magic = data_sp->GetBytes();
-if (ELFHeader::MagicBytesMatch(magic)) {
-  unsigned address_size = ELFHeader::AddressSizeInBytes(magic);
-  if (address_size == 4 || address_size == 8) {
-std::unique_ptr objfile_up(
-new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
-ArchSpec spec = objfile_up->GetArchitecture();
-if (spec && objfile_up->SetModulesArchitecture(spec))
-  return objfile_up.release();
-  }
-}
-  }
+  if (!data_sp || data_sp-

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #102570)

2024-08-08 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Greg Clayton (clayborg)


Changes


https://github.com/llvm/llvm-project/pull/101237 got reverted due to 
buildbot failures. Opening a new PR to submit this again with a fix.

This patch improves the ability of a ObjectFileELF instance to read the 
.dynamic section. It adds the ability to read the .dynamic section from the 
PT_DYNAMIC program header which is useful for ELF files that have no section 
headers and for ELF files that are read from memory. It cleans up the usage of 
the .dynamic entries so that ObjectFileELF::ParseDynamicSymbols() is the only 
code that parses .dynamic entries, teaches that function the read and store the 
string values for each .dynamic entry. We now dump the .dynamic entries in the 
output of "image dump objfile". It also cleans up the code that gets the 
dynamic string table so that it can grab it from the DT_STRTAB and DT_STRSZ 
.dynamic entries for when we have a ELF file with no section headers or we are 
reading it from memory.

---

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


7 Files Affected:

- (modified) lldb/include/lldb/Symbol/ObjectFile.h (+3-2) 
- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (+306-120) 
- (modified) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h (+34-1) 
- (modified) lldb/source/Symbol/ObjectFile.cpp (+4-3) 
- (added) lldb/test/Shell/ObjectFile/ELF/Inputs/memory-elf.cpp (+5) 
- (added) lldb/test/Shell/ObjectFile/ELF/elf-dynamic-no-shdrs.yaml (+93) 
- (added) lldb/test/Shell/ObjectFile/ELF/elf-memory.test (+55) 


``diff
diff --git a/lldb/include/lldb/Symbol/ObjectFile.h 
b/lldb/include/lldb/Symbol/ObjectFile.h
index 8592323322e383..d89314d44bf671 100644
--- a/lldb/include/lldb/Symbol/ObjectFile.h
+++ b/lldb/include/lldb/Symbol/ObjectFile.h
@@ -656,8 +656,9 @@ class ObjectFile : public 
std::enable_shared_from_this,
   // When an object file is in memory, subclasses should try and lock the
   // process weak pointer. If the process weak pointer produces a valid
   // ProcessSP, then subclasses can call this function to read memory.
-  static lldb::DataBufferSP ReadMemory(const lldb::ProcessSP &process_sp,
-   lldb::addr_t addr, size_t byte_size);
+  static lldb::WritableDataBufferSP
+  ReadMemory(const lldb::ProcessSP &process_sp, lldb::addr_t addr,
+ size_t byte_size);
 
   // This function returns raw file contents. Do not use it if you want
   // transparent decompression of section contents.
diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 890db5c2748146..f348b94baad806 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -419,19 +419,35 @@ ObjectFile *ObjectFileELF::CreateInstance(const 
lldb::ModuleSP &module_sp,
 ObjectFile *ObjectFileELF::CreateMemoryInstance(
 const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
 const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
-  if (data_sp && data_sp->GetByteSize() > (llvm::ELF::EI_NIDENT)) {
-const uint8_t *magic = data_sp->GetBytes();
-if (ELFHeader::MagicBytesMatch(magic)) {
-  unsigned address_size = ELFHeader::AddressSizeInBytes(magic);
-  if (address_size == 4 || address_size == 8) {
-std::unique_ptr objfile_up(
-new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
-ArchSpec spec = objfile_up->GetArchitecture();
-if (spec && objfile_up->SetModulesArchitecture(spec))
-  return objfile_up.release();
-  }
-}
-  }
+  if (!data_sp || data_sp->GetByteSize() < (llvm::ELF::EI_NIDENT))
+return nullptr;
+  const uint8_t *magic = data_sp->GetBytes();
+  if (!ELFHeader::MagicBytesMatch(magic))
+return nullptr;
+  // Read the ELF header first so we can figure out how many bytes we need
+  // to read to get as least the ELF header + program headers.
+  DataExtractor data;
+  data.SetData(data_sp);
+  elf::ELFHeader hdr;
+  lldb::offset_t offset = 0;
+  if (!hdr.Parse(data, &offset))
+return nullptr;
+
+  // Make sure the address size is set correctly in the ELF header.
+  if (!hdr.Is32Bit() && !hdr.Is64Bit())
+return nullptr;
+  // Figure out where the program headers end and read enough bytes to get the
+  // program headers in their entirety.
+  lldb::offset_t end_phdrs = hdr.e_phoff + (hdr.e_phentsize * hdr.e_phnum);
+  if (end_phdrs > data_sp->GetByteSize())
+data_sp = ReadMemory(process_sp, header_addr, end_phdrs);
+
+  std::unique_ptr objfile_up(
+  new ObjectFileELF(module_sp, data_sp, process_sp, header_addr));
+  ArchSpec spec = objfile_up->GetArchitecture();
+  if (spec && objfile_up->SetModulesArchitecture(spec))
+return objfile_up.release();
+
   return nullptr;
 }
 
@@ -873,42 +889,37 @@ A

[Lldb-commits] [lldb] [LLDB] Impove ObjectFileELF's .dynamic parsing and usage. (PR #102570)

2024-08-08 Thread Greg Clayton via lldb-commits


clayborg wrote:

I am resubmitting this. I started out with the exact same patch, and then added 
a diff that fixes and tests the issue that was failing.

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

1 2 >

1 - 100 of 108 matches

Mail list logo