[Lldb-commits] [lldb] [LLDB] Fix GetIndexOfChildMemberWithName to handle anonymous structs. (PR #138487)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,33 @@
+int main(int argc, char** argv) {
+  struct A {
+struct {
+  int x = 1;
+};
+int y = 2;
+  } a;
+
+   struct B {
+// Anonymous struct inherits another struct.
+struct : public A {
+  int z = 3;
+};
+int w = 4;
+A a;
+  } b;
+
+   struct : public A {
+ struct {
+   int z = 13;
+ };
+   } unnamed_derived;
+
+   struct DerivedB : public B {
+ struct {
+   // `w` in anonymous struct overrides `w` from `B`.

labath wrote:

I think the precise term is "shadows"

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

[Lldb-commits] [lldb] [LLDB] Fix GetIndexOfChildMemberWithName to handle anonymous structs. (PR #138487)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Change synthetic symbol names to have file address (PR #138416)

[Ely Ronnen via lldb-commits]

https://github.com/eronnen updated 
https://github.com/llvm/llvm-project/pull/138416



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] 488cb24 - [lldb] fix crash on FreeBSD/powerpc64le (#138331)

[via lldb-commits]

Author: Piotr Kubaj
Date: 2025-05-06T10:23:33+01:00
New Revision: 488cb24c2eddb8d0ec3419a4117691022e9e679b

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

LOG: [lldb] fix crash on FreeBSD/powerpc64le (#138331)

Fix for:
`Assertion failed: (false && "Architecture or OS not supported"),
function CreateRegisterContextForFrame, file
/usr/src/contrib/llvm-project/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp,
line 182.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and
include the crash backtrace.
#0 0x00080cd857c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&,
int)
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x00080cd85ed4
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:797:3
#2 0x00080cd82ae8 llvm::sys::RunSignalHandlers()
/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:104:5
#3 0x00080cd861f0 SignalHandler
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:403:3 #4
0x00080f159644 handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:298:3
`

Added: 


Modified: 
lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
index 91552dd976925..a0cd0ee5025bd 100644
--- a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -95,6 +95,7 @@ ThreadElfCore::CreateRegisterContextForFrame(StackFrame 
*frame) {
 reg_interface = new RegisterContextFreeBSD_powerpc32(arch);
 break;
   case llvm::Triple::ppc64:
+  case llvm::Triple::ppc64le:
 reg_interface = new RegisterContextFreeBSD_powerpc64(arch);
 break;
   case llvm::Triple::mips64:



___
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 on FreeBSD/powerpc64le (PR #138331)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/138331
___
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 on FreeBSD/powerpc64le (PR #138331)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

Apart from the pointer indexing question, this PR also opens the question of 
"how should the numbers be represented". Here you represent them as 
ValueObjects, which means you have to give them types, which means you have to 
find a type system for them, ...

I'm not sure I agree with how are  those steps implemented (in fact, I'm pretty 
sure I don't agree with at least some of those steps). In order to keep this PR 
focused, and because a first-class number representation is not necessary for 
replacing the current "frame var", my suggestion would be to dumb down the 
implementation of `postfix_expression`: Instead of `postfix_expression "[" 
expression "]"`, you could implement something like `postfix_expression "[" 
integer "]"`. Then we can store the RHS of the `[]` expression directly as a 
(u)int64 (or AP(S)Int, or whatever), and we can completely sidestep the 
question its type.

My reason for that is that I believe that after this is implemented (and 
@cmtice finishes member access), we will be in a position to flip the flag on 
this and make it the default -- which I think is the real proof of the pudding, 
and I sort of expect we will need to tweak the implementation until everything 
settles into place. I think it's better to not introduce additional complexity 
while we're doing that.

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -18,6 +18,22 @@
 
 namespace lldb_private::dil {
 
+static lldb::ValueObjectSP
+ArrayToPointerConversion(lldb::ValueObjectSP valobj,
+ std::shared_ptr ctx) {
+  assert(valobj->IsArrayType() &&
+ "an argument to array-to-pointer conversion must be an array");
+
+  uint64_t addr = valobj->GetLoadAddress();
+  llvm::StringRef name = "result";
+  ExecutionContext exe_ctx;
+  ctx->CalculateExecutionContext(exe_ctx);
+  return ValueObject::CreateValueObjectFromAddress(
+  name, addr, exe_ctx,
+  
valobj->GetCompilerType().GetArrayElementType(ctx.get()).GetPointerType(),
+  /* do_deref */ false);

labath wrote:

```suggestion
  /*do_deref=*/false);
```

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -111,7 +111,36 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
   llvm_unreachable("invalid token kind");
 }
   }
-  return ParsePrimaryExpression();
+  return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+//  postfix_expression:
+//primary_expression
+//postfix_expression "[" expression "]"
+//
+ASTNodeUP DILParser::ParsePostfixExpression() {
+  ASTNodeUP lhs = ParsePrimaryExpression();
+  while (CurToken().Is(Token::l_square)) {
+uint32_t loc = CurToken().GetLocation();
+Token token = CurToken();
+switch (token.GetKind()) {
+case Token::l_square: {

labath wrote:

What's the point? You've already checked the type three lines above

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -24,6 +28,8 @@ qualified_id = ["::"] [nested_name_specifier] unqualified_id
 
 identifier = ? C99 Identifier ? ;
 
+numeric_literal = ? C99 Integer constant ? ;

labath wrote:

I think the C99 part isn't really true. Maybe we should have a separate section 
to explain the number format we accept?

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -108,6 +130,26 @@ class UnaryOpNode : public ASTNode {
   ASTNodeUP m_operand;
 };
 
+class ArraySubscriptNode : public ASTNode {
+public:
+  ArraySubscriptNode(uint32_t location, ASTNodeUP lhs, ASTNodeUP rhs)
+  : ASTNode(location, NodeKind::eArraySubscriptNode), 
m_lhs(std::move(lhs)),
+m_rhs(std::move(rhs)) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  ASTNode *lhs() const { return m_lhs.get(); }
+  ASTNode *rhs() const { return m_rhs.get(); }

labath wrote:

Let's use the GetFoo convention for this (and also in UnaryOpNode, which I 
didn't catch at the time)

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -280,6 +311,52 @@ void DILParser::BailOut(const std::string &error, uint32_t 
loc,
   m_dil_lexer.ResetTokenIdx(m_dil_lexer.NumLexedTokens() - 1);
 }
 
+// Parse a numeric_literal.
+//
+//  numeric_literal:
+//? Token::numeric_constant ?
+//
+ASTNodeUP DILParser::ParseNumericLiteral() {
+  Expect(Token::numeric_constant);
+  ASTNodeUP numeric_constant = ParseNumericConstant();
+  if (numeric_constant->GetKind() == NodeKind::eErrorNode) {
+BailOut(llvm::formatv("Failed to parse token as numeric-constant: {0}",
+  CurToken()),
+CurToken().GetLocation(), CurToken().GetSpelling().length());
+return std::make_unique();
+  }
+  m_dil_lexer.Advance();
+  return numeric_constant;
+}
+
+static constexpr std::pair type_suffixes[] = {
+{"ull", lldb::eBasicTypeUnsignedLongLong},
+{"ul", lldb::eBasicTypeUnsignedLong},
+{"u", lldb::eBasicTypeUnsignedInt},
+{"ll", lldb::eBasicTypeLongLong},
+{"l", lldb::eBasicTypeLong},
+};
+
+ASTNodeUP DILParser::ParseNumericConstant() {
+  Token token = CurToken();
+  auto spelling = token.GetSpelling();
+  llvm::StringRef spelling_ref = spelling;
+  lldb::BasicType type = lldb::eBasicTypeInt;
+  for (auto [suffix, t] : type_suffixes) {
+if (spelling_ref.consume_back_insensitive(suffix)) {
+  type = t;
+  break;
+}
+  }
+  llvm::APInt raw_value;
+  if (!spelling_ref.getAsInteger(0, raw_value)) {

labath wrote:

In the lexer, you accept `_` as a number character. Does this function 
recognise those?

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Pavel Labath via lldb-commits]

@@ -57,6 +64,29 @@ static std::optional IsWord(llvm::StringRef 
expr,
   return candidate;
 }
 
+static void ConsumeNumberBody(char &prev_ch, llvm::StringRef::iterator 
&cur_pos,
+  llvm::StringRef expr) {
+  while (cur_pos != expr.end() &&
+ (IsDigit(*cur_pos) || IsLetter(*cur_pos) || *cur_pos == '_')) {
+prev_ch = *cur_pos;
+cur_pos++;
+  }
+}
+
+static std::optional IsNumber(llvm::StringRef expr,
+   llvm::StringRef &remainder) {
+  llvm::StringRef::iterator cur_pos = remainder.begin();
+  llvm::StringRef::iterator start = cur_pos;
+  char prev_ch = 0;
+  if (IsDigit(*start)) {
+ConsumeNumberBody(prev_ch, cur_pos, expr);
+llvm::StringRef number = expr.substr(start - expr.begin(), cur_pos - 
start);
+if (remainder.consume_front(number))
+  return number;
+  }
+  return std::nullopt;
+}

labath wrote:

I think this should be equivalent to what you're doing here.

```suggestion
static bool IsNumberBodyChar(char ch) { // Or make it a lambda
  return IsDigit(ch) || IsLetter(ch) || ch == '_';
}

static std::optional IsNumber(llvm::StringRef expr,
   llvm::StringRef &remainder) {
  llvm::StringRef::iterator cur_pos = remainder.begin();
  llvm::StringRef::iterator start = cur_pos;
  if (remainder[0]) {
llvm::StringRef number = remainder.take_while(IsNumberBodyChar);
remainder = remainder.drop_front(number.size());
return number;
  }
  return std::nullopt;
}
```

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

[Lldb-commits] [lldb] [lldb][TypeSystemClang] Allow arrays to be dereferenced in C/C++. (PR #135843)

[Pavel Labath via lldb-commits]

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

Thanks. I think this is fine now. @jimingham, @adrian-prantl, do you have 
anything to add.

Heads-up: I believe you will need to implement this method in the Swift type 
system in order to keep dereferencing working.

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

[Lldb-commits] [lldb] [lldb] Parse DWARF CFI for discontinuous functions (PR #137006)

[Pavel Labath via lldb-commits]

labath wrote:

@felipepiovezan, after yesterdays explanation, maybe you feel brave enough to 
review this? :P

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

[Lldb-commits] [lldb] [lldb/docs] Fix/improve the gdb command map for dynamic types (PR #138538)

[Michael Buch via lldb-commits]

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

Makes sense to me

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

[Lldb-commits] [lldb] [lldb] Fix block address resolution for functions in multiple sections (PR #137955)

[David Spickett via lldb-commits]

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

LGTM

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

[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)

[David Spickett via lldb-commits]

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

LGTM.

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

[Lldb-commits] [lldb] [lldb-dap] Implement `runInTerminal` for Windows (PR #121269)

[Hu Jialun via lldb-commits]

SuibianP wrote:

Pinging again for review @ashgti @omjavaid @walter-erquinigo 

Also want to highlight 
https://github.com/SuibianP/llvm-project/commit/f9675fbe23abe59c3cf56a6263b7a78ec20e42d4#diff-ed319b24adfa654beeff8b32f9d8f975c62299fbe5cb6fbe1028aa6bbaa369e7.
 Not sure how it is passing CI though; I might as well be understanding it 
wrongly.

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

[Lldb-commits] [lldb] [LLDB] Add IsCoreDumping to ProcessInstanceInfo (PR #138580)

[David Spickett via lldb-commits]

@@ -115,5 +115,8 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
   }
   ASSERT_TRUE(Info.IsZombie().has_value());
   ASSERT_FALSE(Info.IsZombie().value());
+
+  ASSERT_TRUE(Info.IsCoreDumping().has_value());
+  ASSERT_FALSE(Info.IsCoreDumping().value());

DavidSpickett wrote:

I presume this field has been around for a very long time, we don't expect any 
system to not have it?

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

[Lldb-commits] [lldb] [LLDB] Add IsCoreDumping to ProcessInstanceInfo (PR #138580)

[David Spickett via lldb-commits]

@@ -213,6 +213,11 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo 
&ProcessInfo,
 } else if (Line.consume_front("Tgid:")) {
   Line = Line.ltrim();
   Line.consumeInteger(10, Tgid);
+} else if (Line.consume_front("CoreDumping:")) {
+  uint32_t coredumping;
+  Line = Line.ltrim();
+  Line.consumeInteger(1, coredumping);

DavidSpickett wrote:

This is calling:
```
template  bool consumeInteger(unsigned Radix, T &Result) {
```
* Radix of 1 means binary?
* Parsing can fail, though now I look above and nothing else checks the return 
value, sigh...

This is new though, so can you make it check the return value and not set if 
it's false? The type is optional, so anyone making use of this is 
handling the "I don't know" state already.

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

[Lldb-commits] [lldb] [LLDB] Fix GetIndexOfChildMemberWithName to handle anonymous structs. (PR #138487)

[Michael Buch via lldb-commits]

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

Some day if we could somehow move all of this into Clang, that'd make me happy 
:)

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

[Lldb-commits] [lldb] [LLDB] Fix GetIndexOfChildMemberWithName to handle anonymous structs. (PR #138487)

[Michael Buch via lldb-commits]

@@ -0,0 +1,33 @@
+int main(int argc, char** argv) {

Michael137 wrote:

Can we add a test that involves empty base classes?

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

[Lldb-commits] [lldb] [LLDB] Fix GetIndexOfChildMemberWithName to handle anonymous structs. (PR #138487)

[Michael Buch via lldb-commits]

@@ -6743,7 +6743,11 @@ size_t TypeSystemClang::GetIndexOfChildMemberWithName(
   if (field_name.empty()) {
 CompilerType field_type = GetType(field->getType());
 std::vector save_indices = child_indexes;
-child_indexes.push_back(child_idx);
+// We have to add on the number of non-empty base classes to this
+// index!

Michael137 wrote:

This comment is redundant. The `non-empty base classes` is no longer true now 
that we're forwarding `omit_empty_base_classes`

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

[Lldb-commits] [lldb] Extending LLDB to work on AIX (PR #102601)

[via lldb-commits]

https://github.com/ravindra-shinde2 updated 
https://github.com/llvm/llvm-project/pull/102601



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] 1eaa289 - [lldb/Host] Enable inheriting "non-inheritable" FDs (#126935)

[via lldb-commits]

Author: Pavel Labath
Date: 2025-05-06T15:04:30+02:00
New Revision: 1eaa289472aaddbeabcde10f89cffb161c2dca55

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

LOG: [lldb/Host] Enable inheriting "non-inheritable" FDs (#126935)

Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.

A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.

Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).

To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.

This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.

Added: 


Modified: 
lldb/source/Host/macosx/objcxx/Host.mm
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
lldb/unittests/Host/HostTest.cpp

Removed: 




diff  --git a/lldb/source/Host/macosx/objcxx/Host.mm 
b/lldb/source/Host/macosx/objcxx/Host.mm
index bb270f6a44e43..e187bf98188ae 100644
--- a/lldb/source/Host/macosx/objcxx/Host.mm
+++ b/lldb/source/Host/macosx/objcxx/Host.mm
@@ -1100,7 +1100,7 @@ static bool AddPosixSpawnFileAction(void *_file_actions, 
const FileAction *info,
 else if (info->GetActionArgument() == -1)
   error = Status::FromErrorString(
   "invalid duplicate fd for posix_spawn_file_actions_adddup2(...)");
-else {
+else if (info->GetFD() != info->GetActionArgument()) {
   error =
   Status(::posix_spawn_file_actions_adddup2(file_actions, 
info->GetFD(),
 info->GetActionArgument()),
@@ -1110,6 +1110,15 @@ static bool AddPosixSpawnFileAction(void *_file_actions, 
const FileAction *info,
  "error: {0}, posix_spawn_file_actions_adddup2 "
  "(action={1}, fd={2}, dup_fd={3})",
  error, file_actions, info->GetFD(), 
info->GetActionArgument());
+} else {
+  error =
+  Status(::posix_spawn_file_actions_addinherit_np(file_actions, 
info->GetFD()),
+ eErrorTypePOSIX);
+  if (error.Fail())
+LLDB_LOG(log,
+ "error: {0}, posix_spawn_file_actions_addinherit_np "
+ "(action={1}, fd={2})",
+ error, file_actions, info->GetFD());
 }
 break;
 

diff  --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp 
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 8c6d503fc7fe2..698524349e16a 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -17,6 +17,7 @@
 #include "llvm/Support/Errno.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
 ExitWithError(error_fd, "close");
   break;
 case FileAction::eFileActionDuplicate:
-  if (dup2(action.fd, action.arg) == -1)
-ExitWithError(error_fd, "dup2");
+  if (action.fd != action.arg) {
+if (dup2(action.fd, action.arg) == -1)
+  ExitWithError(error_fd, "dup2");
+  } else {
+if (fcntl(action.fd, F_SETFD,
+  fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
+  ExitWithError(error_fd, "fcntl");
+  }
   break;
 case FileAction::eFileActionOpen:
   DupDescri

[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)

[Pavel Labath via lldb-commits]

labath wrote:

Thank you.

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

[Lldb-commits] [lldb] [lldb/docs] Fix/improve the gdb command map for dynamic types (PR #138538)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] 6a99d81 - [lldb/docs] Fix/improve the gdb command map for dynamic types (#138538)

[via lldb-commits]

Author: Pavel Labath
Date: 2025-05-06T15:06:24+02:00
New Revision: 6a99d817204dfa39afc42f1f6a810d82f6a8794f

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

LOG: [lldb/docs] Fix/improve the gdb command map for dynamic types (#138538)

The setting and option value names were wrong. I'm assuming this changed
over time, but I haven't tried to figure out when.

Added: 


Modified: 
lldb/docs/use/map.rst

Removed: 




diff  --git a/lldb/docs/use/map.rst b/lldb/docs/use/map.rst
index ed285b2d1f6e9..c648b212006e0 100644
--- a/lldb/docs/use/map.rst
+++ b/lldb/docs/use/map.rst
@@ -800,16 +800,24 @@ Print the dynamic type of the result of an expression
   (gdb) p someCPPObjectPtrOrReference
   (Only works for C++ objects)
 
+LLDB does this automatically if determining the dynamic type does not require
+running the target (in C++, running the target is never needed). This default 
is
+controlled by the `target.prefer-dynamic-value` setting. If that is disabled, 
it
+can be re-enabled on a per-command basis:
+
 .. code-block:: shell
 
-  (lldb) expr -d 1 -- [SomeClass returnAnObject]
-  (lldb) expr -d 1 -- someCPPObjectPtrOrReference
+  (lldb) settings set target.prefer-dynamic-value no-dynamic-values
+  (lldb) frame variable -d no-run-target someCPPObjectPtrOrReference
+  (lldb) expr -d no-run-target -- someCPPObjectPtr
 
-or set dynamic type printing to be the default:
+Note that printing of the dynamic type of references is not possible with the
+`expr` command. The workaround is to take the address of the reference and
+instruct lldb to print the children of the resulting pointer.
 
 .. code-block:: shell
 
-  (lldb) settings set target.prefer-dynamic run-target
+  (lldb) expr -P1 -d no-run-target -- &someCPPObjectReference
 
 Call a function so you can stop at a breakpoint in it
 ~



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

[Lldb-commits] [lldb] [lldb][AIX] get host info for AIX (cont..) (PR #138687)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Hemang Gadhavi (HemangGadhavi)


Changes

This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:

1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601

- Added changes to get the host information for AIX (info like 
FindProcessesImpl() GetProgramFileSpec()), 
continue from the PR https://github.com/llvm/llvm-project/pull/134354
[@DavidSpickett](https://github.com/DavidSpickett) [@labath](https://github.com/labath) [@DhruvSrivastavaX](https://github.com/DhruvSrivastavaX)

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


2 Files Affected:

- (modified) lldb/source/Host/aix/Host.cpp (+48-1) 
- (modified) lldb/source/Host/aix/HostInfoAIX.cpp (+15) 


``diff
diff --git a/lldb/source/Host/aix/Host.cpp b/lldb/source/Host/aix/Host.cpp
index a812e061ccae2..ead8202cbbdef 100644
--- a/lldb/source/Host/aix/Host.cpp
+++ b/lldb/source/Host/aix/Host.cpp
@@ -13,6 +13,7 @@
 #include "lldb/Utility/ProcessInfo.h"
 #include "lldb/Utility/Status.h"
 #include "llvm/BinaryFormat/XCOFF.h"
+#include 
 #include 
 #include 
 
@@ -41,6 +42,14 @@ static ProcessInstanceInfo::timespec 
convert(pr_timestruc64_t t) {
   return ts;
 }
 
+static bool IsDirNumeric(const char *dname) {
+  for (; *dname; dname++) {
+if (!isdigit(*dname))
+  return false;
+  }
+  return true;
+}
+
 static bool GetStatusInfo(::pid_t pid, ProcessInstanceInfo &processInfo,
   ProcessState &State) {
   struct pstatus pstatusData;
@@ -133,7 +142,45 @@ static bool GetProcessAndStatInfo(::pid_t pid,
 
 uint32_t Host::FindProcessesImpl(const ProcessInstanceInfoMatch &match_info,
  ProcessInstanceInfoList &process_infos) {
-  return 0;
+  static const char procdir[] = "/proc/";
+
+  DIR *dirproc = opendir(procdir);
+  if (dirproc) {
+struct dirent *direntry = nullptr;
+const uid_t our_uid = getuid();
+const lldb::pid_t our_pid = getpid();
+bool all_users = match_info.GetMatchAllUsers();
+
+while ((direntry = readdir(dirproc)) != nullptr) {
+  if (!IsDirNumeric(direntry->d_name))
+continue;
+
+  lldb::pid_t pid = atoi(direntry->d_name);
+  // Skip this process.
+  if (pid == our_pid)
+continue;
+
+  ProcessState State;
+  ProcessInstanceInfo process_info;
+  if (!GetProcessAndStatInfo(pid, process_info, State))
+continue;
+
+  if (State == ProcessState::Zombie ||
+  State == ProcessState::TracedOrStopped)
+continue;
+
+  // Check for user match if we're not matching all users and not running
+  // as root.
+  if (!all_users && (our_uid != 0) && (process_info.GetUserID() != 
our_uid))
+continue;
+
+  if (match_info.Matches(process_info)) {
+process_infos.push_back(process_info);
+  }
+}
+closedir(dirproc);
+  }
+  return process_infos.size();
 }
 
 bool Host::GetProcessInfo(lldb::pid_t pid, ProcessInstanceInfo &process_info) {
diff --git a/lldb/source/Host/aix/HostInfoAIX.cpp 
b/lldb/source/Host/aix/HostInfoAIX.cpp
index 61b47462dd647..d720f5c52d3b1 100644
--- a/lldb/source/Host/aix/HostInfoAIX.cpp
+++ b/lldb/source/Host/aix/HostInfoAIX.cpp
@@ -7,6 +7,8 @@
 
//===--===//
 
 #include "lldb/Host/aix/HostInfoAIX.h"
+#include "lldb/Host/posix/Support.h"
+#include 
 
 using namespace lldb_private;
 
@@ -18,5 +20,18 @@ void HostInfoAIX::Terminate() { HostInfoBase::Terminate(); }
 
 FileSpec HostInfoAIX::GetProgramFileSpec() {
   static FileSpec g_program_filespec;
+  struct psinfo psinfoData;
+  auto BufferOrError = getProcFile(getpid(), "psinfo");
+  if (BufferOrError) {
+std::unique_ptr PsinfoBuffer =
+std::move(*BufferOrError);
+memcpy(&psinfoData, PsinfoBuffer->getBufferStart(), sizeof(psinfoData));
+llvm::StringRef exe_path(
+psinfoData.pr_psargs,
+strnlen(psinfoData.pr_psargs, sizeof(psinfoData.pr_psargs)));
+if (!exe_path.empty()) {
+  g_program_filespec.SetFile(exe_path, FileSpec::Style::native);
+}
+  }
   return g_program_filespec;
 }

``




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

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[David Spickett via lldb-commits]

@@ -0,0 +1,13 @@
+// Generate a dummy SB API file using lldb-rpc-gen.
+# RUN: mkdir -p %t/server
+# RUN: mkdir -p %t/lib

DavidSpickett wrote:

CI failing with:
```
/var/lib/buildkite-agent/builds/linux-56-59b8f5d88-spx4x-1/llvm-project/github-pull-requests/build/tools/lldb/test/Shell/RPC/Scripts/TestFrameworkIncludeFixScript/Output/CheckSBClass.test.script:
 line 3: fg: no job control
```
Is it passing locally on Linux for you?

I don't see anything that would need job control, I'm wondering if a stray 
character is causing the shell to think that.

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

[Lldb-commits] [lldb] [lldb][AIX] get host info for AIX (cont..) (PR #138687)

[Hemang Gadhavi via lldb-commits]

https://github.com/HemangGadhavi created 
https://github.com/llvm/llvm-project/pull/138687

This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:

1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601

- Added changes to get the host information for AIX (info like 
FindProcessesImpl() GetProgramFileSpec()), 
continue from the PR https://github.com/llvm/llvm-project/pull/134354
[@DavidSpickett](https://github.com/DavidSpickett) 
[@labath](https://github.com/labath) 
[@DhruvSrivastavaX](https://github.com/DhruvSrivastavaX)



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] [LLDB] Add IsCoreDumping to ProcessInstanceInfo (PR #138580)

[Jacob Lalonde via lldb-commits]

@@ -115,5 +115,8 @@ TEST_F(HostTest, GetProcessInfoSetsPriority) {
   }
   ASSERT_TRUE(Info.IsZombie().has_value());
   ASSERT_FALSE(Info.IsZombie().value());
+
+  ASSERT_TRUE(Info.IsCoreDumping().has_value());
+  ASSERT_FALSE(Info.IsCoreDumping().value());

Jlalond wrote:

Since 4.15, so around 2018 was the end of LTO for that version. I think we're 
safe to assume it's going to be ubiquitous on our test hosts. As for customers, 
we would just fail to read it 

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

[Lldb-commits] [lldb] [LLDB] Add IsCoreDumping to ProcessInstanceInfo (PR #138580)

[Jacob Lalonde via lldb-commits]

@@ -213,6 +213,11 @@ static bool GetStatusInfo(::pid_t Pid, ProcessInstanceInfo 
&ProcessInfo,
 } else if (Line.consume_front("Tgid:")) {
   Line = Line.ltrim();
   Line.consumeInteger(10, Tgid);
+} else if (Line.consume_front("CoreDumping:")) {
+  uint32_t coredumping;
+  Line = Line.ltrim();
+  Line.consumeInteger(1, coredumping);

Jlalond wrote:

Good suggestion, I'll validate the return.

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

[Lldb-commits] [lldb] [LLDB] Add IsCoreDumping to ProcessInstanceInfo (PR #138580)

[David Spickett via lldb-commits]

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

Once you've checked the return value, this LGTM.

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

[Lldb-commits] [lldb] [lldb] Upgrade ExtractIndexFromString to use llvm::Expected (PR #138297)

[Charles Zablit via lldb-commits]

@@ -270,10 +270,14 @@ class VectorTypeSyntheticFrontEnd : public 
SyntheticChildrenFrontEnd {
   }
 
   llvm::Expected GetIndexOfChildWithName(ConstString name) override {
-const char *item_name = name.GetCString();
-uint32_t idx = ExtractIndexFromString(item_name);
-if (idx == UINT32_MAX ||
-(idx < UINT32_MAX && idx >= CalculateNumChildrenIgnoringErrors()))
+auto idx_or_err = ExtractIndexFromString(name.AsCString());
+if (!idx_or_err) {
+  llvm::consumeError(idx_or_err.takeError());
+  return llvm::createStringError("Type has no child named '%s'",

charles-zablit wrote:

I ended up switching to `std::optional` following the different discussions. 
The error message are not very descriptive, and not finding an index did not 
mean there was an error, but rather that the name was not found in the string.

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

[Lldb-commits] [lldb] [lldb] Upgrade ExtractIndexFromString to use llvm::Expected (PR #138297)

[Charles Zablit via lldb-commits]

https://github.com/charles-zablit updated 
https://github.com/llvm/llvm-project/pull/138297



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[David Spickett via lldb-commits]

@@ -0,0 +1,94 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches 
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc-gen`` works and what it outputs
+
+LLDB RPC
+*
+
+LLDB RPC is a framework by which processes can communicate with LLDB out of 
process while maintaining compatibility with the SB API. More details are 
explained in the 
`RFC`_ for 
upstreaming LLDB RPC, but the main focus in this doc for this section will be 
how exactly the code is structured for the PRs that will upstream this code.
+
+The ``lldb-rpc-gen`` tool
+*
+
+``lldb-rpc-gen`` is the tool that generates the main client and server 
interfaces for LLDB RPC. It is a ``ClangTool`` that reads all SB API header 
files and their functions and outputs the client/server interfaces and certain 
other pieces of code, such as RPC-specfic versions of Python bindings used for 
the test suite. There's 3 main components behind ``lldb-rpc-gen``:
+
+1. The ``lldb-rpc-gen`` tool itself, which contains the main driver that uses 
the ``ClangTool``.
+2. The code that generates all interfaces, which we call "emitters". All 
generated code for the interfaces are in C++, so the server side has one 
emitter for its generated source code and another for its generated header 
code. The client side has the same.
+3. All common code shared between all emitters, such as helper methods and 
information about exceptions to take when emitting.
+
+The `current PR`_ up for 
upstreaming LLDB RPC upstreams a subset of the code used for the tool. It 
upstreams the ``lldb-rpc-gen`` tool and all code needed for the server side 
emitters. Here's an example of what ``lldb-rpc-gen`` will output for the server 
side interface:
+
+Input
+-
+
+We'll use ``SBDebugger::CreateTarget(const char *filename)`` as an example. 
``lldb-rpc-gen`` will read this method from ``SBDebugger.h``. The output is as 
follows.
+
+Source Code Output
+--
+
+::
+
+   bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall(rpc_common::Connection
 &connection, RPCStream &send, RPCStream &response) {
+   // 1) Make local storage for incoming function arguments
+   lldb::SBDebugger *this_ptr = nullptr;
+   rpc_common::ConstCharPointer filename;
+   // 2) Decode all function arguments
+   this_ptr = RPCServerObjectDecoder(send, 
rpc_common::RPCPacket::ValueType::Argument);
+   if (!this_ptr)
+   return false;
+   if (!RPCValueDecoder(send, rpc_common::RPCPacket::ValueType::Argument, 
filename))
+   return false;
+   // 3) Call the method and encode the return value
+   lldb::SBTarget && __result = this_ptr->CreateTarget(filename.c_str());
+   RPCServerObjectEncoder(response, 
rpc_common::RPCPacket::ValueType::ReturnValue, std::move(__result));
+   return true;
+   }
+
+Function signature
+~~
+
+All server-side source code functions have a function signature that take the 
format ``bool 
rpc_serverHandleRPCCall(rpc_common::Connection 
&connection, RPCStream &send, RPCStream &response)``. Here the ``connection`` 
is what's maintained between the client and server. The ``send`` variable is a 
byte stream that carries information sent from the client. ``response`` is also 
a byte stream that will be populated with the return value obtained from the 
call into the SB API function that will be sent back to the client.

DavidSpickett wrote:

Why mangled function name not just function name? It's in `rpc_server::` so at 
first glance, it doesn't seem like it needs to be mangled.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett commented:

Thanks for writing this up.

When we get to a point where PRs have landed you can just change "will be" / 
"will do" language to "is" / "does" and it should be a good reference for the 
future.

One thing that is missing right now is how to test it. Basic things just like 
what format of test does it use (shell I think) and is it added to a ninja 
check target.

Also, is there a way for a developer to set up an lldb-rpc based session? If we 
have an issue that only happens over lldb-rpc. Which in theory we won't, but we 
might think we do and need to check that.

In other words - if the only way to do that is to use XCode - that would not be 
good.

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

[Lldb-commits] [lldb] [lldb] Upgrade ExtractIndexFromString to use llvm::Expected (PR #138297)

[Charles Zablit via lldb-commits]

https://github.com/charles-zablit updated 
https://github.com/llvm/llvm-project/pull/138297

>From 8f62523c8ccece4a1c11af51ccf320b19b2ed013 Mon Sep 17 00:00:00 2001
From: Charles Zablit 
Date: Fri, 2 May 2025 16:37:09 +0100
Subject: [PATCH 1/2] [lldb] Upgrade ExtractIndexFromString to use
 llvm::Expected

---
 .../lldb/DataFormatters/FormattersHelpers.h   |  2 +-
 .../DataFormatters/FormattersHelpers.cpp  | 11 ++--
 lldb/source/DataFormatters/VectorType.cpp | 12 ++--
 .../Language/CPlusPlus/GenericBitset.cpp  |  8 ++-
 .../Language/CPlusPlus/GenericOptional.cpp|  8 ++-
 .../CPlusPlus/LibCxxInitializerList.cpp   |  7 ++-
 .../Plugins/Language/CPlusPlus/LibCxxList.cpp |  8 ++-
 .../Plugins/Language/CPlusPlus/LibCxxMap.cpp  |  7 ++-
 .../Language/CPlusPlus/LibCxxProxyArray.cpp   |  7 ++-
 .../Language/CPlusPlus/LibCxxSliceArray.cpp   |  8 ++-
 .../Plugins/Language/CPlusPlus/LibCxxSpan.cpp |  7 ++-
 .../Language/CPlusPlus/LibCxxTuple.cpp|  8 ++-
 .../Language/CPlusPlus/LibCxxUnorderedMap.cpp |  7 ++-
 .../Language/CPlusPlus/LibCxxValarray.cpp |  7 ++-
 .../Language/CPlusPlus/LibCxxVariant.cpp  |  8 ++-
 .../Language/CPlusPlus/LibCxxVector.cpp   | 19 +++---
 .../Language/CPlusPlus/LibStdcppTuple.cpp |  7 ++-
 lldb/source/Plugins/Language/ObjC/NSArray.cpp | 24 ---
 .../Plugins/Language/ObjC/NSDictionary.cpp| 62 ---
 .../Plugins/Language/ObjC/NSIndexPath.cpp | 12 ++--
 lldb/source/Plugins/Language/ObjC/NSSet.cpp   | 36 +++
 21 files changed, 174 insertions(+), 101 deletions(-)

diff --git a/lldb/include/lldb/DataFormatters/FormattersHelpers.h 
b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
index a98042fd40f93..82aae705e2a59 100644
--- a/lldb/include/lldb/DataFormatters/FormattersHelpers.h
+++ b/lldb/include/lldb/DataFormatters/FormattersHelpers.h
@@ -53,7 +53,7 @@ void AddFilter(TypeCategoryImpl::SharedPointer category_sp,
llvm::StringRef type_name,
ScriptedSyntheticChildren::Flags flags, bool regex = false);
 
-size_t ExtractIndexFromString(const char *item_name);
+llvm::Expected ExtractIndexFromString(const char *item_name);
 
 Address GetArrayAddressOrPointerValue(ValueObject &valobj);
 
diff --git a/lldb/source/DataFormatters/FormattersHelpers.cpp 
b/lldb/source/DataFormatters/FormattersHelpers.cpp
index 085ed3d0a2f29..5e29794c291be 100644
--- a/lldb/source/DataFormatters/FormattersHelpers.cpp
+++ b/lldb/source/DataFormatters/FormattersHelpers.cpp
@@ -97,18 +97,19 @@ void lldb_private::formatters::AddFilter(
   category_sp->AddTypeFilter(type_name, match_type, filter_sp);
 }
 
-size_t lldb_private::formatters::ExtractIndexFromString(const char *item_name) 
{
+llvm::Expected
+lldb_private::formatters::ExtractIndexFromString(const char *item_name) {
   if (!item_name || !*item_name)
-return UINT32_MAX;
+return llvm::createStringError("String has no item named '%s'", item_name);
   if (*item_name != '[')
-return UINT32_MAX;
+return llvm::createStringError("String has no item named '%s'", item_name);
   item_name++;
   char *endptr = nullptr;
   unsigned long int idx = ::strtoul(item_name, &endptr, 0);
   if (idx == 0 && endptr == item_name)
-return UINT32_MAX;
+return llvm::createStringError("String has no item named '%s'", item_name);
   if (idx == ULONG_MAX)
-return UINT32_MAX;
+return llvm::createStringError("String has no item named '%s'", item_name);
   return idx;
 }
 
diff --git a/lldb/source/DataFormatters/VectorType.cpp 
b/lldb/source/DataFormatters/VectorType.cpp
index eab2612d1e941..3fa616b9d9b14 100644
--- a/lldb/source/DataFormatters/VectorType.cpp
+++ b/lldb/source/DataFormatters/VectorType.cpp
@@ -270,10 +270,14 @@ class VectorTypeSyntheticFrontEnd : public 
SyntheticChildrenFrontEnd {
   }
 
   llvm::Expected GetIndexOfChildWithName(ConstString name) override {
-const char *item_name = name.GetCString();
-uint32_t idx = ExtractIndexFromString(item_name);
-if (idx == UINT32_MAX ||
-(idx < UINT32_MAX && idx >= CalculateNumChildrenIgnoringErrors()))
+auto idx_or_err = ExtractIndexFromString(name.AsCString());
+if (!idx_or_err) {
+  llvm::consumeError(idx_or_err.takeError());
+  return llvm::createStringError("Type has no child named '%s'",
+ name.AsCString());
+}
+uint32_t idx = *idx_or_err;
+if (idx >= CalculateNumChildrenIgnoringErrors())
   return llvm::createStringError("Type has no child named '%s'",
  name.AsCString());
 return idx;
diff --git a/lldb/source/Plugins/Language/CPlusPlus/GenericBitset.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/GenericBitset.cpp
index 234471d5ba518..ebcac0a48bd30 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/GenericBitset.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/GenericBitset.cpp
@@ -29,11 +29,13 @@ class GenericBitsetFrontEnd : public 
SyntheticChildrenFrontEnd {
   Gener

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,80 @@
+//===-- RPCServerSourceEmitter.h 
--===//
+//
+// 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_RPC_GEN_RPCSERVERMETHODEMITTER_H
+#define LLDB_RPC_GEN_RPCSERVERMETHODEMITTER_H
+
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+namespace lldb_rpc_gen {
+class RPCServerSourceEmitter : public FileEmitter {

DavidSpickett wrote:

Please add a top level description to each of these new classes. Even if it is 
just "Emits the .cpp files for bla", at least then I know that it's doing 
headers or code or both maybe.

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{

DavidSpickett wrote:

Is the size of the pointee type not something we can get from clang?

Maybe it does know the type but sizeof the return type is as much as we can do? 
Which would be sizeof(void*) anyway.

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");

DavidSpickett wrote:

Should this have `= nullptr;`? Just to be neater and maybe prevent some 
compiler warnings.

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,73 @@
+//===-- RPCServerHeaderEmitter.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 "RPCServerHeaderEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+void RPCServerHeaderEmitter::EmitMethod(const Method &method) {
+  const std::string &MangledName = method.MangledName;

DavidSpickett wrote:

Why the mangled name? Add a comment explaining why it cannot be the unmangled 
name.

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett commented:

Looks OK in isolation, a bit like looking at a TableGen backend, easier to 
judge the output than the emitters.

Please look over the FIXMEs and see if anything can be done right now, I 
highlighted one that is potentially a problem but the rest don't seem 
important. See if you agree.

Also please remove any that are no longer relevant.

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

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb[RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[David Spickett via lldb-commits]

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Chelsea Cassanova via lldb-commits]

chelcassanova wrote:

Thanks for responding! I'll add a section on testing the tool itself (which we 
do with shell tests) and testing the interfaces (which we do by running the 
main LLDB API test suite against liblldbrpc).

> Also, is there a way for a developer to set up an lldb-rpc based session? If 
> we have an issue that only happens over lldb-rpc. Which in theory we won't, 
> but we might think we do and need to check that.

Both the RPC client and server are built as binaries that each have a main. The 
RPC core code contains the functionality for a client binary to connect to RPC 
and then interface with the `lldb-rpc-server` binary, so Xcode isn't the only 
way to create a session. This is how we set up the API test suite for RPC, as 
Python is used as the client binary for the RPC session.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[David Spickett via lldb-commits]

DavidSpickett wrote:

But there's no lldb-rpc client built into `lldb`, right? Because that would be 
my first instinct to try.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Chelsea Cassanova via lldb-commits]

chelcassanova wrote:

> Ok so if had a very specific situation I wanted to run via lldb-rpc, I could 
> write an API test for it? That's cool, if I do find a bug I'd need to write a 
> test case anyway.

Yes, you could have an API test that could then get run against liblldbrpc. We 
also have decorators to exclude/include tests that run against liblldbrpc.

> But there's no lldb-rpc client built into lldb, right? Because that would be 
> my first instinct to try.

Not directly in lldb itself as the `lldb-rpc-client` binary is a separate build 
object.

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

[Lldb-commits] [lldb] [lldb] Do not bump memory modificator ID when "internal" debugger memory is updated (PR #129092)

[Mikhail Zakharov via lldb-commits]

real-mikhail wrote:

With the current test fix (`TestProcessModificationIdOnExpr`), it is locked to 
`target-x86` but it seems that it should require `target-x86_64` instead. 
Currently it is not run on Windows-x64 and it fails on Windows-x86 (since the 
test is checking low level internal data, and it is different on different 
architectures).
Ideally, I should not check the exact values of `m_stop_id` and `m_memory_id`. 
We are only interested in the fact whether those values are changed between 
several calls `process status -d`. But as far as I know there is no way in 
testing framework to "remember" specific value and refer to it (compare it) 
later.

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

[Lldb-commits] [lldb] [lldb] Fix dynamic type resolutions for core files (PR #138698)

[Michael Buch via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb][docs] Update instructions to build standalone (PR #137383)

[Alex Langford via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCreateEPKcPFPvS3_ES3_PNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadDetachEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS13ThreadCreatedEPKc",
+};
+
+static constexpr llvm::StringRef ClassesWithoutDefaultCtor[] = {
+"SBHostOS",
+"SBReproducer",
+};
+
+static constexpr llvm::StringRef ClassesWithoutCopyOperations[] = {
+"SBHostOS",
+"SBReproducer",
+"SBStream",
+"SBProgress",
+};
+
+static constexpr llvm::StringRef MethodsWithPointerPlusLen[] = {
+"_ZN4lldb6SBData11ReadRawDataERNS_7SBErrorEyPvm",
+"_ZN4lldb6SBData7SetDataERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData20SetDataWithOwnershipERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData25CreateDataFromUInt64ArrayENS_9ByteOrderEjPym",
+"_ZN4lldb6SBData25CreateDataFromUInt32ArrayENS_9ByteOrderEjPjm",
+"_ZN4lldb6SBData25CreateDataFromSInt64ArrayENS_9ByteOrderEjPxm",
+"_ZN4lldb6SBData25CreateDataFromSInt32ArrayENS_9ByteOrderEjPim",
+"_ZN4lldb6SBData25CreateDataFromDoubleArrayENS_9ByteOrderEjPdm",
+"_ZN4lldb6SBData22SetDataFromUInt64ArrayEPym",
+"_ZN4lldb6SBData22SetDataFromUInt32ArrayEPjm",
+"_ZN4lldb6SBData22SetDataFromSInt64ArrayEPxm",
+"_ZN4lldb6SBData22SetDataFromSInt32ArrayEPim",
+"_ZN4lldb6SBData22SetDataFromDoubleArrayEPdm",
+"_ZN4lldb10SBDebugger22GetDefaultArchitectureEPcm",
+"_ZN4lldb10SBDebugger13DispatchInputEPvPKvm",
+"_ZN4lldb10SBDebugger13DispatchInputEPKvm",
+"_ZN4lldb6SBFile4ReadEPhmPm",
+"_ZN4lldb6SBFile5WriteEPKhmPm",
+"_ZNK4lldb10SBFileSpec7GetPathEPcm",
+"_ZN4lldb10SBFileSpec11ResolvePathEPKcPcm",
+"_ZN4lldb8SBModule10GetVersionEPjj",
+"_ZN4lldb12SBModuleSpec12SetUUIDBytesEPKhm",
+"_ZNK4lldb9SBProcess9GetSTDOUTEPcm",
+"_ZNK4lldb9SBProcess9GetSTDERREPcm",
+"_ZNK4lldb9SBProcess19GetAsyncProfileDataEPcm",
+"_ZN4lldb9SBProcess10ReadMemoryEyPvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess11WriteMemoryEyPKvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess21ReadCStringFromMemoryEyPvmRNS_7SBErrorE",
+"_ZNK4lldb16SBStructuredData14GetStringValueEPcm",
+"_ZN4lldb8SBTarget23BreakpointCreateByNamesEPPKcjjRKNS_"
+"14SBFileSpecListES6_",
+"_ZN4lldb8SBTarget10ReadMemoryENS_9SBAddressEPvmRNS_7SBErrorE",
+"_ZN4lldb8SBTarget15GetInstructionsENS_9SBAddressEPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorENS_9SBAddressEPKcPKvm",
+"_ZN4lldb8SBTarget15GetInstructionsEyPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorEyPKcPKvm",
+"_ZN4lldb8SBThread18GetStopDescriptionEPcm",
+// The below mangled names are used for dummy

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCreateEPKcPFPvS3_ES3_PNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadDetachEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS13ThreadCreatedEPKc",
+};
+
+static constexpr llvm::StringRef ClassesWithoutDefaultCtor[] = {
+"SBHostOS",
+"SBReproducer",
+};
+
+static constexpr llvm::StringRef ClassesWithoutCopyOperations[] = {
+"SBHostOS",
+"SBReproducer",
+"SBStream",
+"SBProgress",
+};
+
+static constexpr llvm::StringRef MethodsWithPointerPlusLen[] = {
+"_ZN4lldb6SBData11ReadRawDataERNS_7SBErrorEyPvm",
+"_ZN4lldb6SBData7SetDataERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData20SetDataWithOwnershipERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData25CreateDataFromUInt64ArrayENS_9ByteOrderEjPym",
+"_ZN4lldb6SBData25CreateDataFromUInt32ArrayENS_9ByteOrderEjPjm",
+"_ZN4lldb6SBData25CreateDataFromSInt64ArrayENS_9ByteOrderEjPxm",
+"_ZN4lldb6SBData25CreateDataFromSInt32ArrayENS_9ByteOrderEjPim",
+"_ZN4lldb6SBData25CreateDataFromDoubleArrayENS_9ByteOrderEjPdm",
+"_ZN4lldb6SBData22SetDataFromUInt64ArrayEPym",
+"_ZN4lldb6SBData22SetDataFromUInt32ArrayEPjm",
+"_ZN4lldb6SBData22SetDataFromSInt64ArrayEPxm",
+"_ZN4lldb6SBData22SetDataFromSInt32ArrayEPim",
+"_ZN4lldb6SBData22SetDataFromDoubleArrayEPdm",
+"_ZN4lldb10SBDebugger22GetDefaultArchitectureEPcm",
+"_ZN4lldb10SBDebugger13DispatchInputEPvPKvm",
+"_ZN4lldb10SBDebugger13DispatchInputEPKvm",
+"_ZN4lldb6SBFile4ReadEPhmPm",
+"_ZN4lldb6SBFile5WriteEPKhmPm",
+"_ZNK4lldb10SBFileSpec7GetPathEPcm",
+"_ZN4lldb10SBFileSpec11ResolvePathEPKcPcm",
+"_ZN4lldb8SBModule10GetVersionEPjj",
+"_ZN4lldb12SBModuleSpec12SetUUIDBytesEPKhm",
+"_ZNK4lldb9SBProcess9GetSTDOUTEPcm",
+"_ZNK4lldb9SBProcess9GetSTDERREPcm",
+"_ZNK4lldb9SBProcess19GetAsyncProfileDataEPcm",
+"_ZN4lldb9SBProcess10ReadMemoryEyPvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess11WriteMemoryEyPKvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess21ReadCStringFromMemoryEyPvmRNS_7SBErrorE",
+"_ZNK4lldb16SBStructuredData14GetStringValueEPcm",
+"_ZN4lldb8SBTarget23BreakpointCreateByNamesEPPKcjjRKNS_"
+"14SBFileSpecListES6_",
+"_ZN4lldb8SBTarget10ReadMemoryENS_9SBAddressEPvmRNS_7SBErrorE",
+"_ZN4lldb8SBTarget15GetInstructionsENS_9SBAddressEPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorENS_9SBAddressEPKcPKvm",
+"_ZN4lldb8SBTarget15GetInstructionsEyPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorEyPKcPKvm",
+"_ZN4lldb8SBThread18GetStopDescriptionEPcm",
+// The below mangled names are used for dummy

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

https://github.com/bulbazord commented:

Given that I wrote some of this code, it looks mostly good to me 😄 Note that 
this has a dependency on the emitters so this probably shouldn't land quite yet.
I commented on some of the FIXMEs because I think now is the time to really 
address them. It would also be great to get a fresh pair of eyes on this...

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",

bulbazord wrote:

I wonder if we could take advantage of the `deprecated` annotation on these 
methods and remove this... 🤔 

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,540 @@
+#include "RPCBindingsHarnessEmitter.h"

bulbazord wrote:

This file will need a license header.

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCreateEPKcPFPvS3_ES3_PNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadDetachEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS13ThreadCreatedEPKc",
+};
+
+static constexpr llvm::StringRef ClassesWithoutDefaultCtor[] = {
+"SBHostOS",
+"SBReproducer",
+};
+
+static constexpr llvm::StringRef ClassesWithoutCopyOperations[] = {
+"SBHostOS",
+"SBReproducer",
+"SBStream",
+"SBProgress",
+};
+
+static constexpr llvm::StringRef MethodsWithPointerPlusLen[] = {

bulbazord wrote:

I'd love if we could remove this list...

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCreateEPKcPFPvS3_ES3_PNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadDetachEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS13ThreadCreatedEPKc",
+};
+
+static constexpr llvm::StringRef ClassesWithoutDefaultCtor[] = {
+"SBHostOS",
+"SBReproducer",
+};
+
+static constexpr llvm::StringRef ClassesWithoutCopyOperations[] = {
+"SBHostOS",
+"SBReproducer",
+"SBStream",
+"SBProgress",
+};
+
+static constexpr llvm::StringRef MethodsWithPointerPlusLen[] = {
+"_ZN4lldb6SBData11ReadRawDataERNS_7SBErrorEyPvm",
+"_ZN4lldb6SBData7SetDataERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData20SetDataWithOwnershipERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData25CreateDataFromUInt64ArrayENS_9ByteOrderEjPym",
+"_ZN4lldb6SBData25CreateDataFromUInt32ArrayENS_9ByteOrderEjPjm",
+"_ZN4lldb6SBData25CreateDataFromSInt64ArrayENS_9ByteOrderEjPxm",
+"_ZN4lldb6SBData25CreateDataFromSInt32ArrayENS_9ByteOrderEjPim",
+"_ZN4lldb6SBData25CreateDataFromDoubleArrayENS_9ByteOrderEjPdm",
+"_ZN4lldb6SBData22SetDataFromUInt64ArrayEPym",
+"_ZN4lldb6SBData22SetDataFromUInt32ArrayEPjm",
+"_ZN4lldb6SBData22SetDataFromSInt64ArrayEPxm",
+"_ZN4lldb6SBData22SetDataFromSInt32ArrayEPim",
+"_ZN4lldb6SBData22SetDataFromDoubleArrayEPdm",
+"_ZN4lldb10SBDebugger22GetDefaultArchitectureEPcm",
+"_ZN4lldb10SBDebugger13DispatchInputEPvPKvm",
+"_ZN4lldb10SBDebugger13DispatchInputEPKvm",
+"_ZN4lldb6SBFile4ReadEPhmPm",
+"_ZN4lldb6SBFile5WriteEPKhmPm",
+"_ZNK4lldb10SBFileSpec7GetPathEPcm",
+"_ZN4lldb10SBFileSpec11ResolvePathEPKcPcm",
+"_ZN4lldb8SBModule10GetVersionEPjj",
+"_ZN4lldb12SBModuleSpec12SetUUIDBytesEPKhm",
+"_ZNK4lldb9SBProcess9GetSTDOUTEPcm",
+"_ZNK4lldb9SBProcess9GetSTDERREPcm",
+"_ZNK4lldb9SBProcess19GetAsyncProfileDataEPcm",
+"_ZN4lldb9SBProcess10ReadMemoryEyPvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess11WriteMemoryEyPKvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess21ReadCStringFromMemoryEyPvmRNS_7SBErrorE",
+"_ZNK4lldb16SBStructuredData14GetStringValueEPcm",
+"_ZN4lldb8SBTarget23BreakpointCreateByNamesEPPKcjjRKNS_"
+"14SBFileSpecListES6_",
+"_ZN4lldb8SBTarget10ReadMemoryENS_9SBAddressEPvmRNS_7SBErrorE",
+"_ZN4lldb8SBTarget15GetInstructionsENS_9SBAddressEPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorENS_9SBAddressEPKcPKvm",
+"_ZN4lldb8SBTarget15GetInstructionsEyPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorEyPKcPKvm",
+"_ZN4lldb8SBThread18GetStopDescriptionEPcm",
+// The below mangled names are used for dummy

[Lldb-commits] [lldb] [lldb][RPC] Upstream lldb-rpc-gen tool (PR #138031)

[Alex Langford via lldb-commits]

@@ -0,0 +1,535 @@
+//===-- RPCCommon.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 "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/AST/Mangle.h"
+#include "clang/Lex/Lexer.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace clang;
+
+// We intentionally do not generate some classes because they are currently
+// inconvenient, they aren't really used by most consumers, or we're not sure
+// why they exist.
+static constexpr llvm::StringRef DisallowedClasses[] = {
+"SBCommunication",  // What is this used for?
+"SBInputReader",// What is this used for?
+"SBCommandPluginInterface", // This is hard to support, we can do it if
+// really needed though.
+"SBCommand", // There's nothing too difficult about this one, but many of
+ // its methods take a SBCommandPluginInterface pointer so
+ // there's no reason to support this.
+};
+
+// We intentionally avoid generating certain methods either because they are
+// difficult to support correctly or they aren't really used much from C++.
+// FIXME: We should be able to annotate these methods instead of maintaining a
+// list in the generator itself.
+static constexpr llvm::StringRef DisallowedMethods[] = {
+// The threading functionality in SBHostOS is deprecated and thus we do not
+// generate them. It would be ideal to add the annotations to the methods
+// and then support not generating deprecated methods. However, without
+// annotations the generator generates most things correctly. This one is
+// problematic because it returns a pointer to an "opaque" structure
+// (thread_t) that is not `void *`, so special casing it is more effort 
than
+// it's worth.
+"_ZN4lldb8SBHostOS10ThreadJoinEP17_opaque_pthread_tPPvPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCancelEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadCreateEPKcPFPvS3_ES3_PNS_7SBErrorE",
+"_ZN4lldb8SBHostOS12ThreadDetachEP17_opaque_pthread_tPNS_7SBErrorE",
+"_ZN4lldb8SBHostOS13ThreadCreatedEPKc",
+};
+
+static constexpr llvm::StringRef ClassesWithoutDefaultCtor[] = {
+"SBHostOS",
+"SBReproducer",
+};
+
+static constexpr llvm::StringRef ClassesWithoutCopyOperations[] = {
+"SBHostOS",
+"SBReproducer",
+"SBStream",
+"SBProgress",
+};
+
+static constexpr llvm::StringRef MethodsWithPointerPlusLen[] = {
+"_ZN4lldb6SBData11ReadRawDataERNS_7SBErrorEyPvm",
+"_ZN4lldb6SBData7SetDataERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData20SetDataWithOwnershipERNS_7SBErrorEPKvmNS_9ByteOrderEh",
+"_ZN4lldb6SBData25CreateDataFromUInt64ArrayENS_9ByteOrderEjPym",
+"_ZN4lldb6SBData25CreateDataFromUInt32ArrayENS_9ByteOrderEjPjm",
+"_ZN4lldb6SBData25CreateDataFromSInt64ArrayENS_9ByteOrderEjPxm",
+"_ZN4lldb6SBData25CreateDataFromSInt32ArrayENS_9ByteOrderEjPim",
+"_ZN4lldb6SBData25CreateDataFromDoubleArrayENS_9ByteOrderEjPdm",
+"_ZN4lldb6SBData22SetDataFromUInt64ArrayEPym",
+"_ZN4lldb6SBData22SetDataFromUInt32ArrayEPjm",
+"_ZN4lldb6SBData22SetDataFromSInt64ArrayEPxm",
+"_ZN4lldb6SBData22SetDataFromSInt32ArrayEPim",
+"_ZN4lldb6SBData22SetDataFromDoubleArrayEPdm",
+"_ZN4lldb10SBDebugger22GetDefaultArchitectureEPcm",
+"_ZN4lldb10SBDebugger13DispatchInputEPvPKvm",
+"_ZN4lldb10SBDebugger13DispatchInputEPKvm",
+"_ZN4lldb6SBFile4ReadEPhmPm",
+"_ZN4lldb6SBFile5WriteEPKhmPm",
+"_ZNK4lldb10SBFileSpec7GetPathEPcm",
+"_ZN4lldb10SBFileSpec11ResolvePathEPKcPcm",
+"_ZN4lldb8SBModule10GetVersionEPjj",
+"_ZN4lldb12SBModuleSpec12SetUUIDBytesEPKhm",
+"_ZNK4lldb9SBProcess9GetSTDOUTEPcm",
+"_ZNK4lldb9SBProcess9GetSTDERREPcm",
+"_ZNK4lldb9SBProcess19GetAsyncProfileDataEPcm",
+"_ZN4lldb9SBProcess10ReadMemoryEyPvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess11WriteMemoryEyPKvmRNS_7SBErrorE",
+"_ZN4lldb9SBProcess21ReadCStringFromMemoryEyPvmRNS_7SBErrorE",
+"_ZNK4lldb16SBStructuredData14GetStringValueEPcm",
+"_ZN4lldb8SBTarget23BreakpointCreateByNamesEPPKcjjRKNS_"
+"14SBFileSpecListES6_",
+"_ZN4lldb8SBTarget10ReadMemoryENS_9SBAddressEPvmRNS_7SBErrorE",
+"_ZN4lldb8SBTarget15GetInstructionsENS_9SBAddressEPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorENS_9SBAddressEPKcPKvm",
+"_ZN4lldb8SBTarget15GetInstructionsEyPKvm",
+"_ZN4lldb8SBTarget25GetInstructionsWithFlavorEyPKcPKvm",
+"_ZN4lldb8SBThread18GetStopDescriptionEPcm",
+// The below mangled names are used for dummy

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,18 @@
+// Copy lldb-rpc-defines.h from source.
+# RUN: mkdir -p %t/input
+# RUN: mkdir -p %t/output
+# RUN: cp %p/../../../../../include/lldb/lldb-defines.h %t/input
+
+// Run the convert script on it, then run the framework include fix on it. The 
framework version fix script
+// expects that all lldb references have been renamed to lldb-rpc in order for 
it to modify the includes
+// to go into the framework.
+# RUN: %python %p/../../../../../scripts/convert-lldb-header-to-rpc-header.py 
%t/input/lldb-defines.h %t/output/lldb-rpc-defines.h
+# RUN: %python %p/../../../../../scripts/framework-header-version-fix.py 
%t/output/lldb-rpc-defines.h %t/output/lldb-rpc-defines.h 17 0 0
+
+// Check the output
+# RUN: cat %t/output/lldb-rpc-defines.h | FileCheck %s
+
+// The LLDB version defines must be uncommented and filled in with the values 
passed into the script.
+# CHECK: #define LLDB_RPC_VERSION 17
+# CHECK: #define LLDB_RPC_REVISION 0
+# CHECK: #define LLDB_RPC_VERSION_STRING "17.0.0"

chelcassanova wrote:

I'll try this 👍🏾 

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,65 @@
+#!/usr/bin/env python3
+# Usage: framework-header-version-fix.py  
 MAJOR MINOR PATCH
+# This script modifies lldb-rpc-defines.h to uncomment the macro defines used 
for the LLDB
+# major, minor and patch values as well as populating their definitions.
+
+import argparse
+import os
+import re
+
+
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument("input")
+parser.add_argument("output")
+parser.add_argument("lldb_version_major")
+parser.add_argument("lldb_version_minor")
+parser.add_argument("lldb_version_patch")
+args = parser.parse_args()
+input_path = str(args.input)
+output_path = str(args.output)
+lldb_version_major = args.lldb_version_major
+lldb_version_minor = args.lldb_version_minor
+lldb_version_patch = args.lldb_version_patch
+
+with open(input_path, "r") as input_file:
+lines = input_file.readlines()
+
+with open(output_path, "w") as output_file:
+for line in lines:
+# Uncomment the line that defines the LLDB major version and 
populate its value.
+if re.match(r"//#define LLDB_RPC_VERSION$", line):

chelcassanova wrote:

I used `$` to make sure that the match here for `LLDB_RPC_VERSION` can't have 
something past the `VERSION` so I think it's possible to try using `//#define 
LLDB_RPC_VERSION$` as the sub match here. Either that or my regex knowledge is 
out of whack.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Ok so if had a very specific situation I wanted to run via lldb-rpc, I could 
write an API test for it? That's cool, if I do find a bug I'd need to write a 
test case anyway.

Please add that as a suggestion in the document where you describe / will 
describe the testing process.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Chelsea Cassanova via lldb-commits]

https://github.com/chelcassanova updated 
https://github.com/llvm/llvm-project/pull/138612



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,94 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches 
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc-gen`` works and what it outputs
+
+LLDB RPC
+*
+
+LLDB RPC is a framework by which processes can communicate with LLDB out of 
process while maintaining compatibility with the SB API. More details are 
explained in the 
`RFC`_ for 
upstreaming LLDB RPC, but the main focus in this doc for this section will be 
how exactly the code is structured for the PRs that will upstream this code.
+
+The ``lldb-rpc-gen`` tool
+*
+
+``lldb-rpc-gen`` is the tool that generates the main client and server 
interfaces for LLDB RPC. It is a ``ClangTool`` that reads all SB API header 
files and their functions and outputs the client/server interfaces and certain 
other pieces of code, such as RPC-specfic versions of Python bindings used for 
the test suite. There's 3 main components behind ``lldb-rpc-gen``:
+
+1. The ``lldb-rpc-gen`` tool itself, which contains the main driver that uses 
the ``ClangTool``.
+2. The code that generates all interfaces, which we call "emitters". All 
generated code for the interfaces are in C++, so the server side has one 
emitter for its generated source code and another for its generated header 
code. The client side has the same.
+3. All common code shared between all emitters, such as helper methods and 
information about exceptions to take when emitting.
+
+The `current PR`_ up for 
upstreaming LLDB RPC upstreams a subset of the code used for the tool. It 
upstreams the ``lldb-rpc-gen`` tool and all code needed for the server side 
emitters. Here's an example of what ``lldb-rpc-gen`` will output for the server 
side interface:
+
+Input
+-
+
+We'll use ``SBDebugger::CreateTarget(const char *filename)`` as an example. 
``lldb-rpc-gen`` will read this method from ``SBDebugger.h``. The output is as 
follows.
+
+Source Code Output
+--
+
+::
+
+   bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall(rpc_common::Connection
 &connection, RPCStream &send, RPCStream &response) {
+   // 1) Make local storage for incoming function arguments
+   lldb::SBDebugger *this_ptr = nullptr;
+   rpc_common::ConstCharPointer filename;
+   // 2) Decode all function arguments
+   this_ptr = RPCServerObjectDecoder(send, 
rpc_common::RPCPacket::ValueType::Argument);
+   if (!this_ptr)
+   return false;
+   if (!RPCValueDecoder(send, rpc_common::RPCPacket::ValueType::Argument, 
filename))
+   return false;
+   // 3) Call the method and encode the return value
+   lldb::SBTarget && __result = this_ptr->CreateTarget(filename.c_str());
+   RPCServerObjectEncoder(response, 
rpc_common::RPCPacket::ValueType::ReturnValue, std::move(__result));
+   return true;
+   }
+
+Function signature
+~~
+
+All server-side source code functions have a function signature that take the 
format ``bool 
rpc_serverHandleRPCCall(rpc_common::Connection 
&connection, RPCStream &send, RPCStream &response)``. Here the ``connection`` 
is what's maintained between the client and server. The ``send`` variable is a 
byte stream that carries information sent from the client. ``response`` is also 
a byte stream that will be populated with the return value obtained from the 
call into the SB API function that will be sent back to the client.

chelcassanova wrote:

Since we have interfaces for all functions, we want to differentiate them in 
the event of overloaded functions, e.g. `SBDebugger::CreateTarget` has 2 
signatures, so each signature gets registered on the server side as:

- `bool rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall`
- `bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKcS2_S2_bRNS_7SBErrorE::HandleRPCCall`

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

[Lldb-commits] [lldb] [lldb] Use llvm::bit_ceil (NFC) (PR #138723)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Kazu Hirata (kazutakahirata)


Changes

This patch replaces a local implementation of bit_ceil with
llvm::bit_ceil.  Technically, the local implementation evaluates to 0
on input 0, whereas llvm::bit_ceil evaluates to 1, but that doesn't
matter because we have:

  // Can't watch zero bytes.
  if (user_size == 0)
return {};


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


1 Files Affected:

- (modified) lldb/source/Breakpoint/WatchpointAlgorithms.cpp (+1-11) 


``diff
diff --git a/lldb/source/Breakpoint/WatchpointAlgorithms.cpp 
b/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
index 3caf29b04317f..d65de13db1dad 100644
--- a/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
+++ b/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
@@ -58,16 +58,6 @@ WatchpointAlgorithms::AtomizeWatchpointRequest(
   return resources;
 }
 
-// This should be `std::bit_ceil(aligned_size)` but
-// that requires C++20.
-// Calculates the smallest integral power of two that is not smaller than x.
-static uint64_t bit_ceil(uint64_t input) {
-  if (input <= 1 || llvm::popcount(input) == 1)
-return input;
-
-  return 1ULL << (64 - llvm::countl_zero(input));
-}
-
 /// Convert a user's watchpoint request (\a user_addr and \a user_size)
 /// into hardware watchpoints, for a target that can watch a power-of-2
 /// region of memory (1, 2, 4, 8, etc), aligned to that same power-of-2
@@ -102,7 +92,7 @@ WatchpointAlgorithms::PowerOf2Watchpoints(addr_t user_addr, 
size_t user_size,
   /// Round up \a user_size to the next power-of-2 size
   /// user_size == 8   -> aligned_size == 8
   /// user_size == 9   -> aligned_size == 16
-  aligned_size = bit_ceil(aligned_size);
+  aligned_size = llvm::bit_ceil(aligned_size);
 
   addr_t aligned_start = user_addr & ~(aligned_size - 1);
 

``




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

[Lldb-commits] [lldb] [lldb] Use llvm::bit_ceil (NFC) (PR #138723)

[Kazu Hirata via lldb-commits]

https://github.com/kazutakahirata created 
https://github.com/llvm/llvm-project/pull/138723

This patch replaces a local implementation of bit_ceil with
llvm::bit_ceil.  Technically, the local implementation evaluates to 0
on input 0, whereas llvm::bit_ceil evaluates to 1, but that doesn't
matter because we have:

  // Can't watch zero bytes.
  if (user_size == 0)
return {};


>From ddf9dd335a5d63ff414370b4c1162fa2bac4195a Mon Sep 17 00:00:00 2001
From: Kazu Hirata 
Date: Tue, 6 May 2025 10:02:55 -0700
Subject: [PATCH] [lldb] Use llvm::bit_ceil (NFC)

This patch replaces a local implementation of bit_ceil with
llvm::bit_ceil.  Technically, the local implementation evaluates to 0
on input 0, whereas llvm::bit_ceil evaluates to 1, but that doesn't
matter because we have:

  // Can't watch zero bytes.
  if (user_size == 0)
return {};
---
 lldb/source/Breakpoint/WatchpointAlgorithms.cpp | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/lldb/source/Breakpoint/WatchpointAlgorithms.cpp 
b/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
index 3caf29b04317f..d65de13db1dad 100644
--- a/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
+++ b/lldb/source/Breakpoint/WatchpointAlgorithms.cpp
@@ -58,16 +58,6 @@ WatchpointAlgorithms::AtomizeWatchpointRequest(
   return resources;
 }
 
-// This should be `std::bit_ceil(aligned_size)` but
-// that requires C++20.
-// Calculates the smallest integral power of two that is not smaller than x.
-static uint64_t bit_ceil(uint64_t input) {
-  if (input <= 1 || llvm::popcount(input) == 1)
-return input;
-
-  return 1ULL << (64 - llvm::countl_zero(input));
-}
-
 /// Convert a user's watchpoint request (\a user_addr and \a user_size)
 /// into hardware watchpoints, for a target that can watch a power-of-2
 /// region of memory (1, 2, 4, 8, etc), aligned to that same power-of-2
@@ -102,7 +92,7 @@ WatchpointAlgorithms::PowerOf2Watchpoints(addr_t user_addr, 
size_t user_size,
   /// Round up \a user_size to the next power-of-2 size
   /// user_size == 8   -> aligned_size == 8
   /// user_size == 9   -> aligned_size == 16
-  aligned_size = bit_ceil(aligned_size);
+  aligned_size = llvm::bit_ceil(aligned_size);
 
   addr_t aligned_start = user_addr & ~(aligned_size - 1);
 

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

[Lldb-commits] [lldb] [lldb-dap] Migrate attach to typed RequestHandler. (PR #137911)

[John Harrison via lldb-commits]

https://github.com/ashgti updated 
https://github.com/llvm/llvm-project/pull/137911



  



Rate limit · GitHub


  body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe 
UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;
font-size: 14px;
line-height: 1.5;
margin: 0;
  }

  .container { margin: 50px auto; max-width: 600px; text-align: center; 
padding: 0 24px; }

  a { color: #0366d6; text-decoration: none; }
  a:hover { text-decoration: underline; }

  h1 { line-height: 60px; font-size: 48px; font-weight: 300; margin: 0px; 
text-shadow: 0 1px 0 #fff; }
  p { color: rgba(0, 0, 0, 0.5); margin: 20px 0 40px; }

  ul { list-style: none; margin: 25px 0; padding: 0; }
  li { display: table-cell; font-weight: bold; width: 1%; }

  .logo { display: inline-block; margin-top: 35px; }
  .logo-img-2x { display: none; }
  @media
  only screen and (-webkit-min-device-pixel-ratio: 2),
  only screen and (   min--moz-device-pixel-ratio: 2),
  only screen and ( -o-min-device-pixel-ratio: 2/1),
  only screen and (min-device-pixel-ratio: 2),
  only screen and (min-resolution: 192dpi),
  only screen and (min-resolution: 2dppx) {
.logo-img-1x { display: none; }
.logo-img-2x { display: inline-block; }
  }

  #suggestions {
margin-top: 35px;
color: #ccc;
  }
  #suggestions a {
color: #66;
font-weight: 200;
font-size: 14px;
margin: 0 10px;
  }


  
  



  Whoa there!
  You have exceeded a secondary rate limit.
Please wait a few minutes before you try again;
in some cases this may take up to an hour.
  
  
https://support.github.com/contact";>Contact Support —
https://githubstatus.com";>GitHub Status —
https://twitter.com/githubstatus";>@githubstatus
  

  

  

  

  

  


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

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,65 @@
+#!/usr/bin/env python3
+# Usage: convert-lldb-header-to-rpc-header.py  

+# This scripts takes common LLDB headers (such as lldb-defines.h) and replaces 
references to LLDB
+# with those for RPC. This happens for:
+# - namespace definitions
+# - namespace usage
+# - version string macros
+# - ifdef/ifndef lines
+
+import argparse
+import os
+import re
+
+
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument("input")
+parser.add_argument("output")
+args = parser.parse_args()
+input_path = str(args.input)
+output_path = str(args.output)
+with open(input_path, "r") as input_file:
+lines = input_file.readlines()
+
+with open(output_path, "w") as output_file:
+for line in lines:
+# NOTE: We do not use lldb-forward.h or lldb-versioning.h in RPC, 
so remove
+# all includes that are found for these files.
+if re.match(
+r'#include "lldb/lldb-forward|#include "lldb/lldb-versioning', 
line
+):
+continue
+# For lldb-rpc-defines.h, replace the ifndef LLDB_LLDB_ portion 
with LLDB_RPC_ as we're not
+# using LLDB private definitions in RPC.
+elif re.match(r".+LLDB_LLDB_", line):
+output_file.write(re.sub(r"LLDB_LLDB_", r"LLDB_RPC_", line))
+# Similarly to lldb-rpc-defines.h, replace the ifndef for LLDB_API 
in SBDefines.h to LLDB_RPC_API_ for the same reason.
+elif re.match(r".+LLDB_API_", line):
+output_file.write(re.sub(r"LLDB_API_", r"LLDB_RPC_API_", line))

chelcassanova wrote:

> if matches this then sub with this

I can try this instances where the pattern that gets checked with both `if` and 
then `sub` are the same thing.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Alex Langford via lldb-commits]

@@ -0,0 +1,107 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches 
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc-gen`` works and what it outputs
+
+LLDB RPC
+*
+
+LLDB RPC is a framework by which processes can communicate with LLDB out of 
process while maintaining compatibility with the SB API. More details are 
explained in the 
`RFC`_ for 
upstreaming LLDB RPC, but the main focus in this doc for this section will be 
how exactly the code is structured for the PRs that will upstream this code.
+
+The ``lldb-rpc-gen`` tool
+*
+
+``lldb-rpc-gen`` is the tool that generates the main client and server 
interfaces for LLDB RPC. It is a ``ClangTool`` that reads all SB API header 
files and their functions and outputs the client/server interfaces and certain 
other pieces of code, such as RPC-specfic versions of Python bindings used for 
the test suite. There's 3 main components behind ``lldb-rpc-gen``:
+
+1. The ``lldb-rpc-gen`` tool itself, which contains the main driver that uses 
the ``ClangTool``.
+2. The code that generates all interfaces, which we call "emitters". All 
generated code for the interfaces are in C++, so the server side has one 
emitter for its generated source code and another for its generated header 
code. The client side has the same.
+3. All common code shared between all emitters, such as helper methods and 
information about exceptions to take when emitting.
+
+There are currently 3 PRs up for upstreaming RPC:
+- One that adds the ``lldb-rpc-gen`` tool and its common code: 
https://github.com/llvm/llvm-project/pull/138031
+- One that adds the RPC server-side interface code emitters: 
https://github.com/llvm/llvm-project/pull/138032
+- One that adds Python scripts to modify the LLDB private headers for use with 
RPC: https://github.com/llvm/llvm-project/pull/138028
+
+The `current PR`_ up for 
upstreaming LLDB RPC upstreams a subset of the code used for the tool. It 
upstreams the ``lldb-rpc-gen`` tool and all code needed for the server side 
emitters. Here's an example of what ``lldb-rpc-gen`` will output for the server 
side interface:
+
+Input
+-
+
+We'll use ``SBDebugger::CreateTarget(const char *filename)`` as an example. 
``lldb-rpc-gen`` will read this method from ``SBDebugger.h``. The output is as 
follows.
+
+Source Code Output
+--
+
+::
+
+   bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall(rpc_common::Connection
 &connection, RPCStream &send, RPCStream &response) {
+   // 1) Make local storage for incoming function arguments
+   lldb::SBDebugger *this_ptr = nullptr;
+   rpc_common::ConstCharPointer filename;
+   // 2) Decode all function arguments
+   this_ptr = RPCServerObjectDecoder(send, 
rpc_common::RPCPacket::ValueType::Argument);
+   if (!this_ptr)
+   return false;
+   if (!RPCValueDecoder(send, rpc_common::RPCPacket::ValueType::Argument, 
filename))
+   return false;
+   // 3) Call the method and encode the return value
+   lldb::SBTarget && __result = this_ptr->CreateTarget(filename.c_str());
+   RPCServerObjectEncoder(response, 
rpc_common::RPCPacket::ValueType::ReturnValue, std::move(__result));
+   return true;
+   }
+
+Function signature
+~~
+
+All server-side source code functions have a function signature that take the 
format ``bool 
rpc_serverHandleRPCCall(rpc_common::Connection 
&connection, RPCStream &send, RPCStream &response)``. Here the ``connection`` 
is what's maintained between the client and server. The ``send`` variable is a 
byte stream that carries information sent from the client. ``response`` is also 
a byte stream that will be populated with the return value obtained from the 
call into the SB API function that will be sent back to the client.
+
+Local variable storage
+~~
+
+First, variables are created to hold all arguments coming in from the client 
side. These variables will be a pointer for the SB API class in question, and 
corresponding variables for all parameters that the function has. Since this 
signature for ``SBDebugger::CreateTarget()`` only has one parameter, a ``const 
char *``, 2 local variables get created. A pointer for an ``SBDebugger`` 
object, and an ``RPCCommon::ConstCharPointer`` for the ``const char * 
filename`` parameter. The ``ConstCharPointer`` is a typedef over ``const char 
*`` in the main RPC core code.
+
+Incoming stream decoding
+
+
+Following this, ``RPCServerObjectDecoder`` is used to decode the ``send`` byte 
stream. In this case, we're decoding this stream into the ``SBDebugger`` 
pointer we created earlier. We then decode the ``send`` stream again to obtain 
the ``const char 

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Alex Langford via lldb-commits]

@@ -0,0 +1,94 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches 
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc-gen`` works and what it outputs
+
+LLDB RPC
+*
+
+LLDB RPC is a framework by which processes can communicate with LLDB out of 
process while maintaining compatibility with the SB API. More details are 
explained in the 
`RFC`_ for 
upstreaming LLDB RPC, but the main focus in this doc for this section will be 
how exactly the code is structured for the PRs that will upstream this code.
+
+The ``lldb-rpc-gen`` tool
+*
+
+``lldb-rpc-gen`` is the tool that generates the main client and server 
interfaces for LLDB RPC. It is a ``ClangTool`` that reads all SB API header 
files and their functions and outputs the client/server interfaces and certain 
other pieces of code, such as RPC-specfic versions of Python bindings used for 
the test suite. There's 3 main components behind ``lldb-rpc-gen``:
+
+1. The ``lldb-rpc-gen`` tool itself, which contains the main driver that uses 
the ``ClangTool``.
+2. The code that generates all interfaces, which we call "emitters". All 
generated code for the interfaces are in C++, so the server side has one 
emitter for its generated source code and another for its generated header 
code. The client side has the same.
+3. All common code shared between all emitters, such as helper methods and 
information about exceptions to take when emitting.
+
+The `current PR`_ up for 
upstreaming LLDB RPC upstreams a subset of the code used for the tool. It 
upstreams the ``lldb-rpc-gen`` tool and all code needed for the server side 
emitters. Here's an example of what ``lldb-rpc-gen`` will output for the server 
side interface:
+
+Input
+-
+
+We'll use ``SBDebugger::CreateTarget(const char *filename)`` as an example. 
``lldb-rpc-gen`` will read this method from ``SBDebugger.h``. The output is as 
follows.
+
+Source Code Output
+--
+
+::
+
+   bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall(rpc_common::Connection
 &connection, RPCStream &send, RPCStream &response) {
+   // 1) Make local storage for incoming function arguments
+   lldb::SBDebugger *this_ptr = nullptr;
+   rpc_common::ConstCharPointer filename;
+   // 2) Decode all function arguments
+   this_ptr = RPCServerObjectDecoder(send, 
rpc_common::RPCPacket::ValueType::Argument);
+   if (!this_ptr)
+   return false;
+   if (!RPCValueDecoder(send, rpc_common::RPCPacket::ValueType::Argument, 
filename))
+   return false;
+   // 3) Call the method and encode the return value
+   lldb::SBTarget && __result = this_ptr->CreateTarget(filename.c_str());
+   RPCServerObjectEncoder(response, 
rpc_common::RPCPacket::ValueType::ReturnValue, std::move(__result));
+   return true;
+   }
+
+Function signature
+~~
+
+All server-side source code functions have a function signature that take the 
format ``bool 
rpc_serverHandleRPCCall(rpc_common::Connection 
&connection, RPCStream &send, RPCStream &response)``. Here the ``connection`` 
is what's maintained between the client and server. The ``send`` variable is a 
byte stream that carries information sent from the client. ``response`` is also 
a byte stream that will be populated with the return value obtained from the 
call into the SB API function that will be sent back to the client.

bulbazord wrote:

For context, this choice was originally made by @clayborg when he was at Apple. 
I worked on the earliest incarnation of lldb-rpc-gen and decided to keep the 
mangled name for the reason Chelsea mentioned, but the choice is indeed 
arbitrary.

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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Alex Langford via lldb-commits]

bulbazord wrote:

> > But there's no lldb-rpc client built into lldb, right? Because that would 
> > be my first instinct to try.
> 
> Not directly in lldb itself as the `lldb-rpc-client` binary is a separate 
> build object.

To add to this, LLDBRPC's API should be *almost* the same as LLDB's. The major 
difference is that some methods and constructors will need to take an 
additional `connection` parameter. It would be possible to write some 
`lldb-rpc` driver, but we haven't done.



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

[Lldb-commits] [lldb] [DRAFT][lldb][RPC] Design doc for upstreaming PR (PR #138612)

[Alex Langford via lldb-commits]

@@ -0,0 +1,107 @@
+LLDB RPC Upstreaming Design Doc
+===
+
+This document aims to explain the general structure of the upstreaming patches 
for adding LLDB RPC. The 2 primary concepts explained here will be:
+
+* How LLDB RPC is used
+* How the ``lldb-rpc-gen`` works and what it outputs
+
+LLDB RPC
+*
+
+LLDB RPC is a framework by which processes can communicate with LLDB out of 
process while maintaining compatibility with the SB API. More details are 
explained in the 
`RFC`_ for 
upstreaming LLDB RPC, but the main focus in this doc for this section will be 
how exactly the code is structured for the PRs that will upstream this code.
+
+The ``lldb-rpc-gen`` tool
+*
+
+``lldb-rpc-gen`` is the tool that generates the main client and server 
interfaces for LLDB RPC. It is a ``ClangTool`` that reads all SB API header 
files and their functions and outputs the client/server interfaces and certain 
other pieces of code, such as RPC-specfic versions of Python bindings used for 
the test suite. There's 3 main components behind ``lldb-rpc-gen``:
+
+1. The ``lldb-rpc-gen`` tool itself, which contains the main driver that uses 
the ``ClangTool``.
+2. The code that generates all interfaces, which we call "emitters". All 
generated code for the interfaces are in C++, so the server side has one 
emitter for its generated source code and another for its generated header 
code. The client side has the same.
+3. All common code shared between all emitters, such as helper methods and 
information about exceptions to take when emitting.
+
+There are currently 3 PRs up for upstreaming RPC:
+- One that adds the ``lldb-rpc-gen`` tool and its common code: 
https://github.com/llvm/llvm-project/pull/138031
+- One that adds the RPC server-side interface code emitters: 
https://github.com/llvm/llvm-project/pull/138032
+- One that adds Python scripts to modify the LLDB private headers for use with 
RPC: https://github.com/llvm/llvm-project/pull/138028
+
+The `current PR`_ up for 
upstreaming LLDB RPC upstreams a subset of the code used for the tool. It 
upstreams the ``lldb-rpc-gen`` tool and all code needed for the server side 
emitters. Here's an example of what ``lldb-rpc-gen`` will output for the server 
side interface:
+
+Input
+-
+
+We'll use ``SBDebugger::CreateTarget(const char *filename)`` as an example. 
``lldb-rpc-gen`` will read this method from ``SBDebugger.h``. The output is as 
follows.
+
+Source Code Output
+--
+
+::
+
+   bool 
rpc_server::_ZN4lldb10SBDebugger12CreateTargetEPKc::HandleRPCCall(rpc_common::Connection
 &connection, RPCStream &send, RPCStream &response) {
+   // 1) Make local storage for incoming function arguments
+   lldb::SBDebugger *this_ptr = nullptr;
+   rpc_common::ConstCharPointer filename;
+   // 2) Decode all function arguments
+   this_ptr = RPCServerObjectDecoder(send, 
rpc_common::RPCPacket::ValueType::Argument);
+   if (!this_ptr)
+   return false;
+   if (!RPCValueDecoder(send, rpc_common::RPCPacket::ValueType::Argument, 
filename))
+   return false;
+   // 3) Call the method and encode the return value
+   lldb::SBTarget && __result = this_ptr->CreateTarget(filename.c_str());
+   RPCServerObjectEncoder(response, 
rpc_common::RPCPacket::ValueType::ReturnValue, std::move(__result));
+   return true;
+   }
+
+Function signature
+~~
+
+All server-side source code functions have a function signature that take the 
format ``bool 
rpc_serverHandleRPCCall(rpc_common::Connection 
&connection, RPCStream &send, RPCStream &response)``. Here the ``connection`` 
is what's maintained between the client and server. The ``send`` variable is a 
byte stream that carries information sent from the client. ``response`` is also 
a byte stream that will be populated with the return value obtained from the 
call into the SB API function that will be sent back to the client.
+
+Local variable storage
+~~
+
+First, variables are created to hold all arguments coming in from the client 
side. These variables will be a pointer for the SB API class in question, and 
corresponding variables for all parameters that the function has. Since this 
signature for ``SBDebugger::CreateTarget()`` only has one parameter, a ``const 
char *``, 2 local variables get created. A pointer for an ``SBDebugger`` 
object, and an ``RPCCommon::ConstCharPointer`` for the ``const char * 
filename`` parameter. The ``ConstCharPointer`` is a typedef over ``const char 
*`` in the main RPC core code.

bulbazord wrote:

Note: `ConstCharPointer` is not a typedef but a full-fledged class. It's backed 
by a `std::string` but has lots of convenience methods for operating at the RPC 
layer.

https://github.com/llvm/llvm-project/pull/138612
___
lldb-c

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,44 @@
+#!/usr/bin/env python3
+# Usage: framework-header-include-fix.py  

+# This script modifies all #include lines in all lldb-rpc headers
+# from either filesystem or local includes to liblldbrpc includes.
+
+import argparse
+import os
+import re
+
+
+def main():
+parser = argparse.ArgumentParser()
+parser.add_argument("input")
+parser.add_argument("output")
+args = parser.parse_args()
+input_path = str(args.input)
+output_path = str(args.output)
+with open(input_path, "r+") as input_file:

chelcassanova wrote:

This was a mistake from an earlier implementation, I shoud've had all of these 
replaced with just `r` or `w` from your original set of comments on the larger 
PR.

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Alex Langford via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");

bulbazord wrote:

`rpc_common::ConstCharPointer` is a class with a default constructor. The 
generated code would look like:
```
rpc_common::ConstCharPointer foo;
```

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Alex Langford via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{

bulbazord wrote:

These methods are difficult for clang to reason about because their return type 
is `const uint8_t *`.

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Alex Langford via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Alex Langford via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Alex Langford via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb][RPC] Upstream Python scripts (PR #138028)

[Chelsea Cassanova via lldb-commits]

chelcassanova wrote:

For what it's worth, while these scripts do work for intended purpose for now, 
an approach I'd love is to have all this header modification be a subtool of 
the `lldb-rpc-gen` tool itself. Subtooling a ClangTool is something I'm not too 
sure on how to do so maybe a better Clang expert can help guide the way on 
this? :)

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

[Lldb-commits] [lldb] [lldb] Do not bump memory modificator ID when "internal" debugger memory is updated (PR #129092)

[David Spickett via lldb-commits]

DavidSpickett wrote:

Please correct the REQUIRES if you have access to such machines to confirm it. 
Maybe the test is so specific that it is fine to be on only one architecture/os 
combination.

I recall a way in codegen tests to capture a line number in one pattern and 
re-use that in a check pattern, I'll have a look for it tomorrow.

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

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,592 @@
+//===-- RPCServerSourceEmitter.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 "RPCServerSourceEmitter.h"
+#include "RPCCommon.h"
+
+#include "clang/AST/AST.h"
+#include "clang/Frontend/CompilerInstance.h"
+
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+
+using namespace clang;
+using namespace lldb_rpc_gen;
+
+// For methods with pointer return types, it's important that we know how big
+// the type of the pointee is. We must correctly size a buffer (in the form of 
a
+// Bytes object) before we can actually use it.
+static const std::map MethodsWithPointerReturnTypes = 
{
+{"_ZN4lldb12SBModuleSpec12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+{"_ZNK4lldb8SBModule12GetUUIDBytesEv", 16}, // sizeof(uuid_t) -> 16
+};
+
+void RPCServerSourceEmitter::EmitMethod(const Method &method) {
+  if (method.ContainsFunctionPointerParameter)
+EmitCallbackFunction(method);
+
+  EmitCommentHeader(method);
+  EmitFunctionHeader(method);
+  EmitFunctionBody(method);
+  EmitFunctionFooter();
+}
+
+void RPCServerSourceEmitter::EmitCommentHeader(const Method &method) {
+  std::string CommentLine;
+  llvm::raw_string_ostream CommentStream(CommentLine);
+
+  CommentStream << "// " << method.QualifiedName << "("
+<< method.CreateParamListAsString(eServer) << ")";
+  if (method.IsConst)
+CommentStream << " const";
+
+  EmitLine("//");
+  EmitLine(CommentLine);
+  EmitLine("//");
+}
+
+void RPCServerSourceEmitter::EmitFunctionHeader(const Method &method) {
+  std::string FunctionHeader;
+  llvm::raw_string_ostream FunctionHeaderStream(FunctionHeader);
+  FunctionHeaderStream
+  << "bool rpc_server::" << method.MangledName
+  << "::HandleRPCCall(rpc_common::Connection &connection, RPCStream "
+ "&send, RPCStream &response) {";
+  EmitLine(FunctionHeader);
+  IndentLevel++;
+}
+
+void RPCServerSourceEmitter::EmitFunctionBody(const Method &method) {
+  EmitLine("// 1) Make local storage for incoming function arguments");
+  EmitStorageForParameters(method);
+  EmitLine("// 2) Decode all function arguments");
+  EmitDecodeForParameters(method);
+  EmitLine("// 3) Call the method and encode the return value");
+  EmitMethodCallAndEncode(method);
+}
+
+void RPCServerSourceEmitter::EmitFunctionFooter() {
+  EmitLine("return true;");
+  IndentLevel--;
+  EmitLine("}");
+}
+
+void RPCServerSourceEmitter::EmitStorageForParameters(const Method &method) {
+  // If we have an instance method and it isn't a constructor, we'll need to
+  // emit a "this" pointer.
+  if (method.IsInstance && !method.IsCtor)
+EmitStorageForOneParameter(method.ThisType, "this_ptr", method.Policy,
+   /* IsFollowedByLen = */ false);
+  for (auto Iter = method.Params.begin(); Iter != method.Params.end(); Iter++) 
{
+EmitStorageForOneParameter(Iter->Type, Iter->Name, method.Policy,
+   Iter->IsFollowedByLen);
+// Skip over the length parameter, we don't emit it.
+if (!lldb_rpc_gen::TypeIsConstCharPtrPtr(Iter->Type) &&
+Iter->IsFollowedByLen)
+  Iter++;
+  }
+}
+
+void RPCServerSourceEmitter::EmitStorageForOneParameter(
+QualType ParamType, const std::string &ParamName,
+const PrintingPolicy &Policy, bool IsFollowedByLen) {
+  // First, we consider `const char *`, `const char **`. They have special
+  // server-side types.
+  if (TypeIsConstCharPtr(ParamType)) {
+EmitLine("rpc_common::ConstCharPointer " + ParamName + ";");
+return;
+  } else if (TypeIsConstCharPtrPtr(ParamType)) {
+EmitLine("rpc_common::StringList " + ParamName + ";");
+return;
+  }
+
+  QualType UnderlyingType =
+  lldb_rpc_gen::GetUnqualifiedUnderlyingType(ParamType);
+  const bool IsSBClass = lldb_rpc_gen::TypeIsSBClass(UnderlyingType);
+
+  if (ParamType->isPointerType() && !IsSBClass) {
+// Void pointer with no length is usually a baton for a callback. We're
+// going to hold onto the pointer value so we can send it back to the
+// client-side when we implement callbacks.
+if (ParamType->isVoidPointerType() && !IsFollowedByLen) {
+  EmitLine("void * " + ParamName + " = nullptr;");
+  return;
+}
+
+if (!ParamType->isFunctionPointerType()) {
+  EmitLine("Bytes " + ParamName + ";");
+  return;
+}
+
+assert(ParamType->isFunctionPointerType() && "Unhandled pointer type");
+EmitLine("rpc_common::function_ptr_t " + Pa

[Lldb-commits] [lldb] [lldb][RPC] Upstream RPC server interface emitters (PR #138032)

[Chelsea Cassanova via lldb-commits]

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

kuilpd wrote:

> Apart from the pointer indexing question, this PR also opens the question of 
> "how should the numbers be represented". Here you represent them as 
> ValueObjects, which means you have to give them types, which means you have 
> to find a type system for them, ...

Why is that a bad thing? Can we do math operations later without types? Plus 
it's a unified interface, node evaluation returns a `ValueObject`.

> I'm not sure I agree with how are those steps implemented (in fact, I'm 
> pretty sure I don't agree with at least some of those steps). In order to 
> keep this PR focused, and because a first-class number representation is not 
> necessary for replacing the current "frame var", my suggestion would be to 
> dumb down the implementation of `postfix_expression`: Instead of 
> `postfix_expression "[" expression "]"`, you could implement something like 
> `postfix_expression "[" integer "]"`. Then we can store the RHS of the `[]` 
> expression directly as a (u)int64 (or AP(S)Int, or whatever), and we can 
> completely sidestep the question its type.

I mean... this works and is a basis for future patches, why remove something 
that we will have to bring back shortly afterwards? After replacing frame var, 
DIL will just have a little bit of extra capabilities, like using another 
variable as an index.

> My reason for that is that I believe that after this is implemented (and 
> @cmtice finishes member access), we will be in a position to flip the flag on 
> this and make it the default -- which I think is the real proof of the 
> pudding, and I sort of expect we will need to tweak the implementation until 
> everything settles into place. I think it's better to not introduce 
> additional complexity while we're doing that.

We still need to implement bit extraction that current `frame var` allows, 
which looks like this: `integer[4-8]`, another node we will have to 
re-implement later if we redo how numbers are stored now.

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

@@ -24,6 +28,8 @@ qualified_id = ["::"] [nested_name_specifier] unqualified_id
 
 identifier = ? C99 Identifier ? ;
 
+numeric_literal = ? C99 Integer constant ? ;

kuilpd wrote:

Yeah, `0b...` and `0o...` formats supported here are missing from C99. How 
should I explain the format without writing its full grammar as well?

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

@@ -280,6 +311,52 @@ void DILParser::BailOut(const std::string &error, uint32_t 
loc,
   m_dil_lexer.ResetTokenIdx(m_dil_lexer.NumLexedTokens() - 1);
 }
 
+// Parse a numeric_literal.
+//
+//  numeric_literal:
+//? Token::numeric_constant ?
+//
+ASTNodeUP DILParser::ParseNumericLiteral() {
+  Expect(Token::numeric_constant);
+  ASTNodeUP numeric_constant = ParseNumericConstant();
+  if (numeric_constant->GetKind() == NodeKind::eErrorNode) {
+BailOut(llvm::formatv("Failed to parse token as numeric-constant: {0}",
+  CurToken()),
+CurToken().GetLocation(), CurToken().GetSpelling().length());
+return std::make_unique();
+  }
+  m_dil_lexer.Advance();
+  return numeric_constant;
+}
+
+static constexpr std::pair type_suffixes[] = {
+{"ull", lldb::eBasicTypeUnsignedLongLong},
+{"ul", lldb::eBasicTypeUnsignedLong},
+{"u", lldb::eBasicTypeUnsignedInt},
+{"ll", lldb::eBasicTypeLongLong},
+{"l", lldb::eBasicTypeLong},
+};
+
+ASTNodeUP DILParser::ParseNumericConstant() {
+  Token token = CurToken();
+  auto spelling = token.GetSpelling();
+  llvm::StringRef spelling_ref = spelling;
+  lldb::BasicType type = lldb::eBasicTypeInt;
+  for (auto [suffix, t] : type_suffixes) {
+if (spelling_ref.consume_back_insensitive(suffix)) {
+  type = t;
+  break;
+}
+  }
+  llvm::APInt raw_value;
+  if (!spelling_ref.getAsInteger(0, raw_value)) {

kuilpd wrote:

It doesn't, I guess we don't really need this character in numbers.

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

@@ -111,7 +111,36 @@ ASTNodeUP DILParser::ParseUnaryExpression() {
   llvm_unreachable("invalid token kind");
 }
   }
-  return ParsePrimaryExpression();
+  return ParsePostfixExpression();
+}
+
+// Parse a postfix_expression.
+//
+//  postfix_expression:
+//primary_expression
+//postfix_expression "[" expression "]"
+//
+ASTNodeUP DILParser::ParsePostfixExpression() {
+  ASTNodeUP lhs = ParsePrimaryExpression();
+  while (CurToken().Is(Token::l_square)) {
+uint32_t loc = CurToken().GetLocation();
+Token token = CurToken();
+switch (token.GetKind()) {
+case Token::l_square: {

kuilpd wrote:

This is for when other postfix expressions get added here, `.` and `->` from 
the other PR.

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

https://github.com/kuilpd updated 
https://github.com/llvm/llvm-project/pull/138551

>From cfe7359bd16c1e87932e2ebb8bcdfc88130e9729 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin 
Date: Wed, 30 Apr 2025 22:03:50 +0500
Subject: [PATCH 1/3] [LLDB] Add array subscription and integer parsing to DIL

---
 lldb/docs/dil-expr-lang.ebnf  |  12 +-
 lldb/include/lldb/ValueObject/DILAST.h|  46 +
 lldb/include/lldb/ValueObject/DILEval.h   |   6 +
 lldb/include/lldb/ValueObject/DILLexer.h  |   3 +
 lldb/include/lldb/ValueObject/DILParser.h |   3 +
 lldb/source/ValueObject/DILAST.cpp|  10 ++
 lldb/source/ValueObject/DILEval.cpp   | 159 ++
 lldb/source/ValueObject/DILLexer.cpp  |  43 -
 lldb/source/ValueObject/DILParser.cpp |  79 -
 .../var-dil/basics/ArraySubscript/Makefile|   3 +
 .../TestFrameVarDILArraySubscript.py  |  88 ++
 .../var-dil/basics/ArraySubscript/main.cpp|  31 
 lldb/unittests/ValueObject/DILLexerTests.cpp  |  34 +++-
 13 files changed, 506 insertions(+), 11 deletions(-)
 create mode 100644 
lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/Makefile
 create mode 100644 
lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/TestFrameVarDILArraySubscript.py
 create mode 100644 
lldb/test/API/commands/frame/var-dil/basics/ArraySubscript/main.cpp

diff --git a/lldb/docs/dil-expr-lang.ebnf b/lldb/docs/dil-expr-lang.ebnf
index c8bf4231b3e4a..0cbb5403785db 100644
--- a/lldb/docs/dil-expr-lang.ebnf
+++ b/lldb/docs/dil-expr-lang.ebnf
@@ -6,16 +6,20 @@
 expression = unary_expression ;
 
 unary_expression = unary_operator expression
- | primary_expression ;
+ | postfix_expression ;
 
 unary_operator = "*" | "&" ;
 
-primary_expression = id_expression
+postfix_expression = primary_expression
+   | postfix_expression "[" expression "]";
+
+primary_expression = numeric_literal
+   | id_expression
| "(" expression ")";
 
 id_expression = unqualified_id
   | qualified_id
- | register ;
+  | register ;
 
 unqualified_id = identifier ;
 
@@ -24,6 +28,8 @@ qualified_id = ["::"] [nested_name_specifier] unqualified_id
 
 identifier = ? C99 Identifier ? ;
 
+numeric_literal = ? C99 Integer constant ? ;
+
 register = "$" ? Register name ? ;
 
 nested_name_specifier = type_name "::"
diff --git a/lldb/include/lldb/ValueObject/DILAST.h 
b/lldb/include/lldb/ValueObject/DILAST.h
index fe3827ef0516a..6908deed7aee3 100644
--- a/lldb/include/lldb/ValueObject/DILAST.h
+++ b/lldb/include/lldb/ValueObject/DILAST.h
@@ -18,8 +18,10 @@ namespace lldb_private::dil {
 
 /// The various types DIL AST nodes (used by the DIL parser).
 enum class NodeKind {
+  eArraySubscriptNode,
   eErrorNode,
   eIdentifierNode,
+  eScalarLiteralNode,
   eUnaryOpNode,
 };
 
@@ -71,6 +73,26 @@ class ErrorNode : public ASTNode {
   }
 };
 
+class ScalarLiteralNode : public ASTNode {
+public:
+  ScalarLiteralNode(uint32_t location, lldb::BasicType type, Scalar value)
+  : ASTNode(location, NodeKind::eScalarLiteralNode), m_type(type),
+m_value(value) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  lldb::BasicType GetType() const { return m_type; }
+  Scalar GetValue() const & { return m_value; }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eScalarLiteralNode;
+  }
+
+private:
+  lldb::BasicType m_type;
+  Scalar m_value;
+};
+
 class IdentifierNode : public ASTNode {
 public:
   IdentifierNode(uint32_t location, std::string name)
@@ -108,6 +130,26 @@ class UnaryOpNode : public ASTNode {
   ASTNodeUP m_operand;
 };
 
+class ArraySubscriptNode : public ASTNode {
+public:
+  ArraySubscriptNode(uint32_t location, ASTNodeUP lhs, ASTNodeUP rhs)
+  : ASTNode(location, NodeKind::eArraySubscriptNode), 
m_lhs(std::move(lhs)),
+m_rhs(std::move(rhs)) {}
+
+  llvm::Expected Accept(Visitor *v) const override;
+
+  ASTNode *lhs() const { return m_lhs.get(); }
+  ASTNode *rhs() const { return m_rhs.get(); }
+
+  static bool classof(const ASTNode *node) {
+return node->GetKind() == NodeKind::eArraySubscriptNode;
+  }
+
+private:
+  ASTNodeUP m_lhs;
+  ASTNodeUP m_rhs;
+};
+
 /// This class contains one Visit method for each specialized type of
 /// DIL AST node. The Visit methods are used to dispatch a DIL AST node to
 /// the correct function in the DIL expression evaluator for evaluating that
@@ -116,9 +158,13 @@ class Visitor {
 public:
   virtual ~Visitor() = default;
   virtual llvm::Expected
+  Visit(const ScalarLiteralNode *node) = 0;
+  virtual llvm::Expected
   Visit(const IdentifierNode *node) = 0;
   virtual llvm::Expected
   Visit(const UnaryOpNode *node) = 0;
+  virtual llvm::Expected
+  Visit(const ArraySubscriptNode *node) = 0;
 };
 
 } // namespace lldb_private::dil
diff --git a/lldb/include/lldb/ValueObject/DILEval.h 
b/

[Lldb-commits] [lldb] [lldb-dap] Change the launch sequence (PR #138219)

[via lldb-commits]

kusmour wrote:

Unblocked!

> @kusmour Please take another look. In the current state all the test pass 
> (reliably) locally and the linux bot seems happy too. Not sure if we want to 
> keep the test disabled for now or turn them back on and see what the 
> reliability is like on the bots.

I don't know much about the build bot infra but looks like the only way to get 
the tests running is to land an enablement patch?

Looks like a bunch of tests got disabled today: 
https://github.com/llvm/llvm-project/issues/137660
I don't think we should keep ignoring tests if we want to land this tho. I am 
all for re-enable them with the risk of reverting. But I will let others to 
chime in.

cc. @IanWood1 @felipepiovezan  

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

[Lldb-commits] [lldb] [LLDB] Add array subscription and integer parsing to DIL (PR #138551)

[Ilia Kuklin via lldb-commits]

kuilpd wrote:

> I don't have an answer to that, but I do know that it's possible to index 
> pointers in the current implementation. I suggest checking out how it 
> achieves that and seeing if it can be translated to here.

I found `GetSyntheticArrayMember`, hopefully this is the one you're referring 
to.

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

[Lldb-commits] [lldb] [lldb-dap] Change the launch sequence (PR #138219)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> Unblocked!

Thanks!

> > @kusmour Please take another look. In the current state all the test pass 
> > (reliably) locally and the linux bot seems happy too. Not sure if we want 
> > to keep the test disabled for now or turn them back on and see what the 
> > reliability is like on the bots.
> 
> I don't know much about the build bot infra but looks like the only way to 
> get the tests running is to land an enablement patch?

We  have pre-commit  testing (which passed) but that doesn't say much about the 
reliability. We'll need to enable them to see what the impact is on the 
post-commit CI. I think I'll split off the test-reenablement into a separate PR 
so we don't have to revert the whole thing here.

> Looks like a bunch of tests got disabled today: #137660 I don't think we 
> should keep ignoring tests if we want to land this tho. I am all for 
> re-enable them with the risk of reverting. But I will let others to chime in.
> 
> cc. @IanWood1 @felipepiovezan

I don't t think those got disabled today, they're cherrypicks on forks from the 
upstream commits (the ones I mentioned on Discouse):

- [[lldb][test] Disable a bunch of flakey lldb-dap tests · 
llvm/llvm-project@2dbab4c · 
GitHub](https://github.com/llvm/llvm-project/commit/2dbab4ca8ddb218af555d8d1fd86b72612387582)
- [[lldb] Disable TestDAP_attachByPortNum · llvm/llvm-project@b73169a · 
GitHub](https://github.com/llvm/llvm-project/commit/b73169ad3edc56fe2b4f5bd3d5259310168da50c)
- [[lldb] Disable TestDAP_attach · llvm/llvm-project@55b4e5e · 
GitHub](https://github.com/llvm/llvm-project/commit/55b4e5e5154550ba981af08ca9bd1e3da00e6fea)

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