date:20240722

[Lldb-commits] [lldb] [lldb/Target] Add GetStartSymbol method to DynamicLoader plugins (PR #99673)

2024-07-22 Thread Pavel Labath via lldb-commits


labath wrote:

I'd like to note that, at least in the ELF world, there's no guarantee that 
there will be an actual *symbol* at the address where the process starts 
executing. The convention is to call this `_start` but nothing in the system 
actually relies on that. The ELF header contains the address of the first 
instruction, the OS jumps to that, and that's it.

So, I think that a more generic interface would be to return an `Address` 
(which the caller can try to resolve to a symbol if it wants to).

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

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-07-22 Thread via lldb-commits

dlav-sc wrote:

> > Thanks for the patches (if we end up going down this route you'll probably 
> > want to split out the LLVM JIT changes into a separate PR).
> 
> I know little about the JIT side but this is my first reaction too. I wonder 
> if that has its own tests that need adding, and it'll get more expert eyes on 
> it.
> 
> > without RISCV large code model, which has not been implemented yet
> 
> I presume the work to do this is much greater than the work shown here?

To be fair I'm not sure. We have this MR: 
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/388#issuecomment-1737115297
 . This review is taking quite a while
already. So I presume there are some issue there. On the hand we can always 
disable the suggested path if needed.

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

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-07-22 Thread via lldb-commits


dlav-sc wrote:

> A quick look at the RISCV ISA and it says that the JAL instruction is pc 
> relative and can jump +/- 1MB. JALR gets the upper 20 bits from a general 
> purpose register and it includes 12 low bits in its instruction encoding. I 
> know almost nothing about rv32, but is this what you mean by a Large Memory 
> Model, the use of the JALR instruction? I didn't find the part that talks 
> about how JALR works in rv64, but it seems likely it can specify an arbitrary 
> 64-bit address?

> I know almost nothing about rv32, but is this what you mean by a Large Memory 
> Model, the use of the JALR instruction? 

yep.



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

[Lldb-commits] [lldb] [LLDB][SBSaveCoreOptions] Fix TestProcessSaveCore (PR #99692)

2024-07-22 Thread Leandro Lupori via lldb-commits


luporl wrote:

@Jlalond Thanks for the fix.

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

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-07-22 Thread via lldb-commits


dlav-sc wrote:

> Thanks for the patches (if we end up going down this route you'll probably 
> want to split out the LLVM JIT changes into a separate PR).
> 
> Not very familiar with RISCV. Could you elaborate on the exact failures you 
> were seeing and why we need the extra IR pass?
> 
> > Also it adds RISCV specific DirectToIndirectFunctionCallsReplacement IR 
> > pass, that allows to make assembly jumps at any 64bit address without RISCV 
> > large code model, which has not been implemented yet.
> 
> I guess this summarizes it, but would be good to see actual example failures

> I guess this summarizes it, but would be good to see actual example failures

Consider a simple function call:

`main.cpp`:
```
void foo() {


   
 int a = 42;
}   


   

int main() {



 
 foo(); 


  
 return 0;  


  
} 
```

```
(lldb) file main.x
(lldb) b main
(lldb) run
(lldb) expr foo()
```
Before patch:

Lldb generates a wrapper, obtains its IR and tries to interpret it with 
IRInterpreter, but fails on a function call:

IR:
```
lldb Module as passed in to IRForTarget: 
"; ModuleID = '$__lldb_module'
source_filename = "$__lldb_module"
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "riscv64-unknown-linux-gnu"

; Function Attrs: convergent mustprogress noinline nounwind optnone
define dso_local void @"_Z12$__lldb_exprPv"(ptr %"$__lldb_arg") #0 {
entry:
  %"$__lldb_arg.addr" = alloca ptr, align 8, !clang.decl.ptr !8
  store ptr %"$__lldb_arg", ptr %"$__lldb_arg.addr", align 8
  call void @_Z3foov() #2
  ret void
}

; Function Attrs: convergent
declare void @_Z3foov() #1

attributes #0 = { convergent mustprogress noinline nounwind optnone 
"frame-pointer"="all" "no-builtins" "no-trapping-math"="true" 
"stack-protector-buffer-size"="0" "target-features"="+64bit" }
attributes #1 = { convergent "frame-pointer"="all" "no-builtins" 
"no-trapping-math"="true" "stack-protector-buffer-size"="0" 
"target-features"="+64bit" }
attributes #2 = { convergent "no-builtins" }

!llvm.module.flags = !{!0, !1, !2, !3, !4}
!clang.global.decl.ptrs = !{!5, !6}
!llvm.ident = !{!7}

!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 1, !"target-abi", !"lp64"}
!2 = !{i32 7, !"direct-access-external-data", i32 0}
!3 = !{i32 7, !"frame-pointer", i32 2}
!4 = !{i32 8, !"SmallDataLimit", i32 0}
!5 = !{ptr @"_Z12$__lldb_exprPv", i64 94163729942528}
!6 = !{ptr @_Z3foov, i64 94163729942816}
!7 = !{!"Syntacore clang version 18.1.4-sc (SC git:/tools/llvm/llvm-project/ 
fefe1910746c1b7e0e23cd64767b3f08ba788cf1)"}
!8 = !{i64 94163729942296}
"
```
Output:
```
lldb Couldn't find result variable
lldb MaybeHandleCallArguments(  call void @_Z3foov() #2)
lldb Element arrangement:
lldb Arg: "ptr %"$__lldb_arg""
lldb Total structure [align 8, size 0]
lldb Saw function with body: _Z12$__lldb_exprPv
lldb Unsupported instruction: call void @_Z3foov() #2
lldb [ClangASTImporter] Forgetting destination 
(ASTContext*)0x55A433716B10
lldb [ClangASTImporter] Forgetting source->dest 
(ASTContext*)0x55A433716B10->(ASTContext*)0x55A433A119D0
error: Can't evaluate the expression without a running target due to: 
Interpreter doesn't handle one of the expression's opcodes
```

After patch:

Lldb also generates a wrapper, obtains its IR but sends it to a JIT compiler 
instead of IRInterpreter. MCJIT generates an assembly, puts it into a process 
stack memory, resolves relocations and finally executes:

IR the same.

Assembly:
```
lldb Function disassembly:

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-07-22 Thread via lldb-commits



@@ -0,0 +1,58 @@
+//===--- DirectToIndirectFCR.h - RISC-V specific pass 
-===//
+//
+// 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
+//
+//===--===//
+
+#pragma once
+
+#include "lldb/lldb-types.h"
+
+#include "llvm/IR/Instructions.h"
+#include "llvm/Pass.h"
+
+namespace lldb_private {
+
+class ExecutionContext;
+
+// During the lldb expression execution lldb wraps a user expression, jittes
+// fabricated code and then puts it into the stack memory. Thus, if user tried

dlav-sc wrote:

I think your expression is simple enough to be interpreted by IRInterpreter, 
instead of be sent to JIT compiler, so in this case there are no stack 
allocations.

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

[Lldb-commits] [lldb] [llvm] [lldb][RISCV] function calls support in lldb expressions (PR #99336)

2024-07-22 Thread via lldb-commits



@@ -0,0 +1,58 @@
+//===--- DirectToIndirectFCR.h - RISC-V specific pass 
-===//
+//
+// 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
+//
+//===--===//
+
+#pragma once
+
+#include "lldb/lldb-types.h"
+
+#include "llvm/IR/Instructions.h"
+#include "llvm/Pass.h"
+
+namespace lldb_private {
+
+class ExecutionContext;
+
+// During the lldb expression execution lldb wraps a user expression, jittes
+// fabricated code and then puts it into the stack memory. Thus, if user tried
+// to make a function call there will be a jump from a stack address to a code
+// sections's address. RISC-V Architecture doesn't have a large code model yet
+// and can make only a +-2GiB jumps, but in 64-bit architecture a distance
+// between stack addresses and code sections's addresses is longer. Therefore,
+// relocations resolver obtains an invalid address. To avoid such problem, this
+// pass should be used. It replaces function calls with appropriate function's
+// addresses explicitly. By doing so it removes relocations related to function
+// calls. This pass should be cosidered as temprorary solution until a large
+// code model will be approved.
+class DirectToIndirectFCR : public llvm::FunctionPass {

dlav-sc wrote:

Just `Direct To Indirect Function Calls Replacement`. Maybe it's not the best 
name, but I have a poor fantasy, so if you have any sugestions, feel free to 
leave them here.

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

[Lldb-commits] [lldb] [lldb/Target] Add GetStartSymbol method to DynamicLoader plugins (PR #99673)

2024-07-22 Thread via lldb-commits


jimingham wrote:

I agree with Pavel, we don't for most purposes care whether there's a symbol at 
the start address (for instance we can use it for the "expression evaluation 
return breakpoint" as an address.  So we shouldn't require the symbol.

Jim

> On Jul 22, 2024, at 12:04 AM, Pavel Labath ***@***.***> wrote:
> 
> 
> I'd like to note that, at least in the ELF world, there's no guarantee that 
> there will be an actual symbol at the address where the process starts 
> executing. The convention is to call this _start but nothing in the system 
> actually relies on that. The ELF header contains the address of the first 
> instruction, the OS jumps to that, and that's it.
> 
> So, I think that a more generic interface would be to return an Address 
> (which the caller can try to resolve to a symbol if it wants to).
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



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

[Lldb-commits] [lldb] [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (PR #99909)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/99909

On linux, the start address doesn't necessarily have a symbol attached to it.

This is why this patch replaces `DynamicLoader::GetStartSymbol` with 
`DynamicLoader::GetStartAddress` instead.

>From f74357959ab8b8a7bdc68f358c802a06e62ab134 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 22 Jul 2024 10:50:30 -0700
Subject: [PATCH] [lldb] Change GetStartSymbol to GetStartAddress in
 DynamicLoader

On linux, the start address doesn't necessarily have a symbol attached
to it.

This is why this patch replaces `DynamicLoader::GetStartSymbol` with
`DynamicLoader::GetStartAddress` instead.

Signed-off-by: Med Ismail Bennani 
---
 lldb/include/lldb/Target/DynamicLoader.h | 9 +
 .../DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp| 4 ++--
 .../DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h  | 4 ++--
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/lldb/include/lldb/Target/DynamicLoader.h 
b/lldb/include/lldb/Target/DynamicLoader.h
index 15384245194b0..0629e2faae7e9 100644
--- a/lldb/include/lldb/Target/DynamicLoader.h
+++ b/lldb/include/lldb/Target/DynamicLoader.h
@@ -9,8 +9,8 @@
 #ifndef LLDB_TARGET_DYNAMICLOADER_H
 #define LLDB_TARGET_DYNAMICLOADER_H
 
+#include "lldb/Core/Address.h"
 #include "lldb/Core/PluginInterface.h"
-#include "lldb/Symbol/Symbol.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/UUID.h"
@@ -25,6 +25,7 @@ namespace lldb_private {
 class ModuleList;
 class Process;
 class SectionList;
+class Symbol;
 class SymbolContext;
 class SymbolContextList;
 class Thread;
@@ -329,10 +330,10 @@ class DynamicLoader : public PluginInterface {
   /// safe to call certain APIs or SPIs.
   virtual bool IsFullyInitialized() { return true; }
 
-  /// Return the `start` function \b symbol in the dynamic loader module.
-  /// This is the symbol the process will begin executing with
+  /// Return the `start` \b address in the dynamic loader module.
+  /// This is the address the process will begin executing with
   /// `process launch --stop-at-entry`.
-  virtual std::optional GetStartSymbol() {
+  virtual std::optional GetStartAddress() {
 return std::nullopt;
   }
 
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 5c6331735bde8..3863b6b3520db 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -609,7 +609,7 @@ void 
DynamicLoaderDarwin::UpdateDYLDImageInfoFromNewImageInfo(
   }
 }
 
-std::optional DynamicLoaderDarwin::GetStartSymbol() {
+std::optional DynamicLoaderDarwin::GetStartAddress() {
   Log *log = GetLog(LLDBLog::DynamicLoader);
 
   auto log_err = [log](llvm::StringLiteral err_msg) -> std::nullopt_t {
@@ -626,7 +626,7 @@ std::optional 
DynamicLoaderDarwin::GetStartSymbol() {
   if (!symbol)
 return log_err("Cannot find `start` symbol in DYLD module.");
 
-  return *symbol;
+  return symbol->GetAddress();
 }
 
 void DynamicLoaderDarwin::SetDYLDModule(lldb::ModuleSP &dyld_module_sp) {
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
index 4ac55fdf6f3af..3613c4c29b178 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
@@ -56,6 +56,8 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
 
   virtual bool NeedToDoInitialImageFetch() = 0;
 
+  std::optional GetStartAddress() override;
+
 protected:
   void PrivateInitialize(lldb_private::Process *process);
 
@@ -67,8 +69,6 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
   // Clear method for classes derived from this one
   virtual void DoClear() = 0;
 
-  std::optional GetStartSymbol() override;
-
   void SetDYLDModule(lldb::ModuleSP &dyld_module_sp);
 
   lldb::ModuleSP GetDYLDModule();

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

[Lldb-commits] [lldb] [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (PR #99909)

2024-07-22 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Med Ismail Bennani (medismailben)


Changes

On linux, the start address doesn't necessarily have a symbol attached to it.

This is why this patch replaces `DynamicLoader::GetStartSymbol` with 
`DynamicLoader::GetStartAddress` instead.

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


3 Files Affected:

- (modified) lldb/include/lldb/Target/DynamicLoader.h (+5-4) 
- (modified) 
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp (+2-2) 
- (modified) 
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h (+2-2) 


``diff
diff --git a/lldb/include/lldb/Target/DynamicLoader.h 
b/lldb/include/lldb/Target/DynamicLoader.h
index 15384245194b0..0629e2faae7e9 100644
--- a/lldb/include/lldb/Target/DynamicLoader.h
+++ b/lldb/include/lldb/Target/DynamicLoader.h
@@ -9,8 +9,8 @@
 #ifndef LLDB_TARGET_DYNAMICLOADER_H
 #define LLDB_TARGET_DYNAMICLOADER_H
 
+#include "lldb/Core/Address.h"
 #include "lldb/Core/PluginInterface.h"
-#include "lldb/Symbol/Symbol.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/UUID.h"
@@ -25,6 +25,7 @@ namespace lldb_private {
 class ModuleList;
 class Process;
 class SectionList;
+class Symbol;
 class SymbolContext;
 class SymbolContextList;
 class Thread;
@@ -329,10 +330,10 @@ class DynamicLoader : public PluginInterface {
   /// safe to call certain APIs or SPIs.
   virtual bool IsFullyInitialized() { return true; }
 
-  /// Return the `start` function \b symbol in the dynamic loader module.
-  /// This is the symbol the process will begin executing with
+  /// Return the `start` \b address in the dynamic loader module.
+  /// This is the address the process will begin executing with
   /// `process launch --stop-at-entry`.
-  virtual std::optional GetStartSymbol() {
+  virtual std::optional GetStartAddress() {
 return std::nullopt;
   }
 
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 5c6331735bde8..3863b6b3520db 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -609,7 +609,7 @@ void 
DynamicLoaderDarwin::UpdateDYLDImageInfoFromNewImageInfo(
   }
 }
 
-std::optional DynamicLoaderDarwin::GetStartSymbol() {
+std::optional DynamicLoaderDarwin::GetStartAddress() {
   Log *log = GetLog(LLDBLog::DynamicLoader);
 
   auto log_err = [log](llvm::StringLiteral err_msg) -> std::nullopt_t {
@@ -626,7 +626,7 @@ std::optional 
DynamicLoaderDarwin::GetStartSymbol() {
   if (!symbol)
 return log_err("Cannot find `start` symbol in DYLD module.");
 
-  return *symbol;
+  return symbol->GetAddress();
 }
 
 void DynamicLoaderDarwin::SetDYLDModule(lldb::ModuleSP &dyld_module_sp) {
diff --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
index 4ac55fdf6f3af..3613c4c29b178 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
@@ -56,6 +56,8 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
 
   virtual bool NeedToDoInitialImageFetch() = 0;
 
+  std::optional GetStartAddress() override;
+
 protected:
   void PrivateInitialize(lldb_private::Process *process);
 
@@ -67,8 +69,6 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
   // Clear method for classes derived from this one
   virtual void DoClear() = 0;
 
-  std::optional GetStartSymbol() override;
-
   void SetDYLDModule(lldb::ModuleSP &dyld_module_sp);
 
   lldb::ModuleSP GetDYLDModule();

``




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

[Lldb-commits] [lldb] [lldb/Target] Add GetStartSymbol method to DynamicLoader plugins (PR #99673)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


medismailben wrote:

@labath @jimingham I've addressed your comment in 
https://github.com/llvm/llvm-project/pull/99909

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

[Lldb-commits] [lldb] [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (PR #99909)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

[Lldb-commits] [lldb] [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (PR #99909)

2024-07-22 Thread Jonas Devlieghere via lldb-commits


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


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

[Lldb-commits] [lldb] bb8a740 - [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (#99909)

2024-07-22 Thread via lldb-commits


Author: Med Ismail Bennani
Date: 2024-07-22T11:43:32-07:00
New Revision: bb8a74075b164ea0d9b3155f64d0590fc6072cdd

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

LOG: [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (#99909)

On linux, the start address doesn't necessarily have a symbol attached
to it.

This is why this patch replaces `DynamicLoader::GetStartSymbol` with
`DynamicLoader::GetStartAddress` instead to make it more generic.

Signed-off-by: Med Ismail Bennani 

Added: 


Modified: 
lldb/include/lldb/Target/DynamicLoader.h
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h

Removed: 




diff  --git a/lldb/include/lldb/Target/DynamicLoader.h 
b/lldb/include/lldb/Target/DynamicLoader.h
index 15384245194b0..0629e2faae7e9 100644
--- a/lldb/include/lldb/Target/DynamicLoader.h
+++ b/lldb/include/lldb/Target/DynamicLoader.h
@@ -9,8 +9,8 @@
 #ifndef LLDB_TARGET_DYNAMICLOADER_H
 #define LLDB_TARGET_DYNAMICLOADER_H
 
+#include "lldb/Core/Address.h"
 #include "lldb/Core/PluginInterface.h"
-#include "lldb/Symbol/Symbol.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/UUID.h"
@@ -25,6 +25,7 @@ namespace lldb_private {
 class ModuleList;
 class Process;
 class SectionList;
+class Symbol;
 class SymbolContext;
 class SymbolContextList;
 class Thread;
@@ -329,10 +330,10 @@ class DynamicLoader : public PluginInterface {
   /// safe to call certain APIs or SPIs.
   virtual bool IsFullyInitialized() { return true; }
 
-  /// Return the `start` function \b symbol in the dynamic loader module.
-  /// This is the symbol the process will begin executing with
+  /// Return the `start` \b address in the dynamic loader module.
+  /// This is the address the process will begin executing with
   /// `process launch --stop-at-entry`.
-  virtual std::optional GetStartSymbol() {
+  virtual std::optional GetStartAddress() {
 return std::nullopt;
   }
 

diff  --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 5c6331735bde8..3863b6b3520db 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -609,7 +609,7 @@ void 
DynamicLoaderDarwin::UpdateDYLDImageInfoFromNewImageInfo(
   }
 }
 
-std::optional DynamicLoaderDarwin::GetStartSymbol() {
+std::optional DynamicLoaderDarwin::GetStartAddress() {
   Log *log = GetLog(LLDBLog::DynamicLoader);
 
   auto log_err = [log](llvm::StringLiteral err_msg) -> std::nullopt_t {
@@ -626,7 +626,7 @@ std::optional 
DynamicLoaderDarwin::GetStartSymbol() {
   if (!symbol)
 return log_err("Cannot find `start` symbol in DYLD module.");
 
-  return *symbol;
+  return symbol->GetAddress();
 }
 
 void DynamicLoaderDarwin::SetDYLDModule(lldb::ModuleSP &dyld_module_sp) {

diff  --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
index 4ac55fdf6f3af..3613c4c29b178 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.h
@@ -56,6 +56,8 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
 
   virtual bool NeedToDoInitialImageFetch() = 0;
 
+  std::optional GetStartAddress() override;
+
 protected:
   void PrivateInitialize(lldb_private::Process *process);
 
@@ -67,8 +69,6 @@ class DynamicLoaderDarwin : public 
lldb_private::DynamicLoader {
   // Clear method for classes derived from this one
   virtual void DoClear() = 0;
 
-  std::optional GetStartSymbol() override;
-
   void SetDYLDModule(lldb::ModuleSP &dyld_module_sp);
 
   lldb::ModuleSP GetDYLDModule();



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

[Lldb-commits] [lldb] [lldb] Change GetStartSymbol to GetStartAddress in DynamicLoader (PR #99909)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

[Lldb-commits] [lldb] [lldb-dap] Updated README.md for newly added attach properties. (PR #99926)

2024-07-22 Thread Santhosh Kumar Ellendula via lldb-commits


https://github.com/santhoshe447 created 
https://github.com/llvm/llvm-project/pull/99926

Added "gdb-remote-port" and "gdb-remote-hostname" attach properties usage in
README.md.

This was missed in PR https://github.com/llvm/llvm-project/pull/91570

>From 960351c9abf51f42d92604ac6297aa5b76ddfba5 Mon Sep 17 00:00:00 2001
From: Santhosh Kumar Ellendula 
Date: Fri, 17 Nov 2023 15:09:10 +0530
Subject: [PATCH 01/18] [lldb][test] Add the ability to extract the variable
 value out of the summary.

---
 .../Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py   | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index 9d79872b029a3..0cf9d4fde4948 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -195,6 +195,9 @@ def collect_console(self, duration):
 
 def get_local_as_int(self, name, threadId=None):
 value = self.dap_server.get_local_variable_value(name, 
threadId=threadId)
+# 'value' may have the variable value and summary.
+# Extract the variable value since summary can have nonnumeric 
characters.
+value = value.split(" ")[0]
 if value.startswith("0x"):
 return int(value, 16)
 elif value.startswith("0"):

>From ab44a6991c5bc8ac5764c3f71cbe3acc747b3776 Mon Sep 17 00:00:00 2001
From: Santhosh Kumar Ellendula 
Date: Fri, 3 May 2024 02:47:05 -0700
Subject: [PATCH 02/18] [lldb-dap] Added "port" property to vscode "attach"
 command.

Adding a "port" property to the VsCode "attach" command likely extends the 
functionality of the debugger configuratiuon to allow attaching to a process 
using PID or PORT number.
Currently, the "Attach" configuration lets the user specify a pid. We tell the 
user to use the attachCommands property to run "gdb-remote ".
Followed the below conditions for "attach" command with "port" and "pid"
We should add a "port" property. If port is specified and pid is not, use that 
port to attach. If both port and pid are specified, return an error saying that 
the user can't specify both pid and port.

Ex - launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "lldb-dap Debug",
"type": "lldb-dap",
"request": "attach",
"port":1234,
"program": "${workspaceFolder}/a.out",
"args": [],
"stopOnEntry": false,
"cwd": "${workspaceFolder}",
"env": [],

}
]
}
---
 lldb/include/lldb/lldb-defines.h  |   1 +
 .../Python/lldbsuite/test/lldbtest.py |   9 ++
 .../test/tools/lldb-dap/dap_server.py |   6 +
 .../test/tools/lldb-dap/lldbdap_testcase.py   |  20 +++
 .../attach/TestDAP_attachByPortNum.py | 120 ++
 lldb/tools/lldb-dap/lldb-dap.cpp  |  36 +-
 lldb/tools/lldb-dap/package.json  |  11 ++
 7 files changed, 199 insertions(+), 4 deletions(-)
 create mode 100644 
lldb/test/API/tools/lldb-dap/attach/TestDAP_attachByPortNum.py

diff --git a/lldb/include/lldb/lldb-defines.h b/lldb/include/lldb/lldb-defines.h
index c7bd019c5c90e..a1e6ee2ce468c 100644
--- a/lldb/include/lldb/lldb-defines.h
+++ b/lldb/include/lldb/lldb-defines.h
@@ -96,6 +96,7 @@
 #define LLDB_INVALID_QUEUE_ID 0
 #define LLDB_INVALID_CPU_ID UINT32_MAX
 #define LLDB_INVALID_WATCHPOINT_RESOURCE_ID UINT32_MAX
+#define LLDB_INVALID_PORT_NUMBER 0
 
 /// CPU Type definitions
 #define LLDB_ARCH_DEFAULT "systemArch"
diff --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 5fd686c143e9f..fb3cd22959df2 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1572,6 +1572,15 @@ def findBuiltClang(self):
 
 return os.environ["CC"]
 
+def getBuiltServerTool(self, server_tool):
+# Tries to find simulation/lldb-server/gdbserver tool at the same 
folder as the lldb.
+lldb_dir = os.path.dirname(lldbtest_config.lldbExec)
+path = shutil.which(server_tool, path=lldb_dir)
+if path is not None:
+return path
+
+return ""
+
 def yaml2obj(self, yaml_path, obj_path, max_size=None):
 """
 Create an object file at the given path from a yaml file.
diff --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
index 5838281bcb1a1..96d312565f953 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
@@ -568,6 +568,8 @@ def request_attach(
 coreFile=None,
 postRunCommands=None,
 sourceMap=None,
+port=None,
+hostn

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Alex Langford via lldb-commits


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

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Alex Langford via lldb-commits


https://github.com/bulbazord commented:

Seems alright to me, left a few minor suggestions inline. 

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

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Alex Langford via lldb-commits



@@ -329,6 +330,13 @@ class DynamicLoader : public PluginInterface {
   /// safe to call certain APIs or SPIs.
   virtual bool IsFullyInitialized() { return true; }
 
+  /// Return the `start` function \b symbol in the dynamic loader module.
+  /// This is the symbol the process will begin executing with
+  /// `process launch --stop-at-entry`.
+  virtual std::optional GetStartSymbol() {

bulbazord wrote:

You'll probably need to rebase this change right?

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

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Alex Langford via lldb-commits



@@ -127,9 +129,127 @@ class CommandObjectScriptingRun : public CommandObjectRaw 
{
   CommandOptions m_options;
 };
 
-#pragma mark CommandObjectMultiwordScripting
+#define LLDB_OPTIONS_scripting_template_list
+#include "CommandOptions.inc"
+
+class CommandObjectScriptingTemplateList : public CommandObjectParsed {
+public:
+  CommandObjectScriptingTemplateList(CommandInterpreter &interpreter)
+  : CommandObjectParsed(
+interpreter, "scripting template list",
+"List all the available scripting extension templates. ",
+"scripting template list [--language  --]") {}
+
+  ~CommandObjectScriptingTemplateList() override = default;
+
+  Options *GetOptions() override { return &m_options; }
+
+  class CommandOptions : public Options {
+  public:
+CommandOptions() = default;
+~CommandOptions() override = default;
+Status SetOptionValue(uint32_t option_idx, llvm::StringRef option_arg,
+  ExecutionContext *execution_context) override {
+  Status error;
+  const int short_option = m_getopt_table[option_idx].val;
 
-// CommandObjectMultiwordScripting
+  switch (short_option) {
+  case 'l':
+m_language = (lldb::ScriptLanguage)OptionArgParser::ToOptionEnum(
+option_arg, GetDefinitions()[option_idx].enum_values,
+eScriptLanguageNone, error);
+if (!error.Success())
+  error.SetErrorStringWithFormat("unrecognized value for language 
'%s'",

bulbazord wrote:

Suggestion: `SetErrorStringWithFormatv` to avoid the `.str().c_str()` dance

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

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

2024-07-22 Thread via lldb-commits



@@ -160,6 +160,8 @@ class LLDB_API SBProcess {
 
   lldb::SBError Continue();
 
+  lldb::SBError ReverseContinue();

jimingham wrote:

For programming uses, it might be more useful to have one API with a bool or 
RunDirection or something? It's nicer to write:

`  process.Continue(direction)
`
rather than:

  if (direction = lldb.eRunBackwards):
process.ReverseContinue()
  else:
process.Continue()

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

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

2024-07-22 Thread via lldb-commits


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

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

2024-07-22 Thread via lldb-commits



@@ -1395,6 +1395,94 @@ Status ProcessGDBRemote::DoResume() {
   return error;
 }
 
+Status ProcessGDBRemote::DoResumeReverse() {
+  Status error;
+  Log *log = GetLog(GDBRLog::Process);
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse()");
+
+  ListenerSP listener_sp(
+  Listener::MakeListener("gdb-remote.resume-packet-sent"));
+  if (listener_sp->StartListeningForEvents(
+  &m_gdb_comm, GDBRemoteClientBase::eBroadcastBitRunPacketSent)) {
+listener_sp->StartListeningForEvents(
+&m_async_broadcaster,
+ProcessGDBRemote::eBroadcastBitAsyncThreadDidExit);
+
+const size_t num_threads = GetThreadList().GetSize();
+
+StreamString continue_packet;
+
+// Number of threads continuing with "C", i.e. continuing with a signal to 
deliver.
+const size_t num_continue_C_tids = m_continue_C_tids.size();
+// Number of threads continuing with "s", i.e. single-stepping.
+const size_t num_continue_s_tids = m_continue_s_tids.size();
+// Number of threads continuing with "S", i.e. single-stepping with a 
signal to deliver.
+const size_t num_continue_S_tids = m_continue_S_tids.size();
+// We can only `bc` to reverse-continue all threads,
+// or `bs` to reverse-step the current thread (which may also
+// reverse-continue other threads by some amount).
+// These packets do not support delivering signals.
+if (num_continue_C_tids > 0 || num_continue_S_tids > 0) {
+  error.SetErrorString("can't deliver signals while running in reverse");
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: Signals not 
supported");
+  return error;
+}
+
+if (num_continue_s_tids > 0) {
+  if (num_continue_s_tids > 1) {
+error.SetErrorString("can't step multiple threads while 
reverse-stepping");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: can't step multiple 
threads");
+return error;
+  }
+
+  if (!m_gdb_comm.GetReverseStepSupported()) {
+error.SetErrorString("target does not support reverse-stepping");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: target does not 
support reverse-stepping");
+return error;
+  }
+
+  m_gdb_comm.SetCurrentThreadForRun(m_continue_s_tids.front());
+  continue_packet.PutCString("bs");
+} else {
+  if (!m_gdb_comm.GetReverseContinueSupported()) {
+error.SetErrorString("target does not support reverse-continue");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: target does not 
support reverse-continue");
+return error;
+  }
+
+  // All threads continue whether requested or not ---
+  // we can't change how threads ran in the past.
+  continue_packet.PutCString("bc");
+}
+
+EventSP event_sp;
+if (!m_async_thread.IsJoinable()) {
+  error.SetErrorString("Trying to resume but the async thread is dead.");
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: Trying to resume but 
the "
+ "async thread is dead.");
+  return error;
+}
+
+auto data_sp =
+std::make_shared(continue_packet.GetString());
+m_async_broadcaster.BroadcastEvent(eBroadcastBitAsyncContinue, data_sp);
+
+if (!listener_sp->GetEvent(event_sp, std::chrono::seconds(5))) {

jimingham wrote:

I try to avoid any hard coded timeouts, mostly because it's easy to lose track 
of where timeouts are occurring.   If you make a constant with a good name and 
use that they are easier to find.

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

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

2024-07-22 Thread via lldb-commits



@@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
   // filters before resuming.
   UpdateAutomaticSignalFiltering();
 
+  if (m_last_run_direction != direction) {

jimingham wrote:

It might be hard, but it would be nice if this wasn't necessary.  For instance, 
I do a forward-next over a function and hit a breakpoint.  In lldb at present, 
I can do a couple of steps around where I hit the breakpoint, then I can just 
"continue" to conclude the forward-next.  But with this change, if I hit the 
breakpoint, forward step, decide I stepped too far, backwards step, find what I 
wanted, and then do "continue" now I get an actual continue, we've forgotten 
about the forward-next.

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

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

2024-07-22 Thread via lldb-commits



@@ -3281,7 +3288,11 @@ Status Process::PrivateResume() {
 "Process::PrivateResume PreResumeActions failed, not resuming.");
   } else {
 m_mod_id.BumpResumeID();
-error = DoResume();
+if (direction == eRunForward) {
+  error = DoResume();

jimingham wrote:

What do we get out of the asymmetry between all the other resume methods that 
take a direction, and the doResume methods that don't?  It just looks awkward 
to my eyes.

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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse from lldb test utilities (PR #99934)

2024-07-22 Thread Andrew Rogers via lldb-commits


https://github.com/andrurogerz created 
https://github.com/llvm/llvm-project/pull/99934

## Issue
Attempting to run the lldb API tests against a remote-android target fails with 
the error `NameError: name 'urlparse' is not defined`.

## Root Cause
It looks the Python import of `urlparse` was removed by mistake in 
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when running 
the lldb API tests against a remote-android target so it went unnoticed.

## Fix
This change simply puts back the missing import. It is a one line change.

fixes 99931

## Validation
Tested on Fedora 39 with an attached Android device:

`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb' 
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver 
--platform-name=remote-android --platform-working-dir=/data/local/tmp/ds2 
--platform-url=connect://localhost:5432 --compiler 
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`

>From 0dc32f964a0f8d03d9c1aaebd453167738d461d8 Mon Sep 17 00:00:00 2001
From: Andrew Rogers 
Date: Mon, 22 Jul 2024 08:48:13 -0700
Subject: [PATCH] android: fix missing import for urlparse

This import is only used on the Android path. It looks like it was
removed by mistake in 22ea97d7bfd65abf68a68b13bf96ad69be23df54.
---
 lldb/packages/Python/lldbsuite/test/lldbplatformutil.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py 
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index b7e6f240f59f6..e3c6fd1a99568 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -9,6 +9,7 @@
 import sys
 import os
 from packaging import version
+from urllib.parse import urlparse
 
 # LLDB modules
 import lldb

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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse from lldb test utilities (PR #99934)

2024-07-22 Thread via lldb-commits


github-actions[bot] wrote:



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

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

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

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

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

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

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

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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse from lldb test utilities (PR #99934)

2024-07-22 Thread Andrew Rogers via lldb-commits


andrurogerz wrote:

cc @compnerd

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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse from lldb test utilities (PR #99934)

2024-07-22 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Andrew Rogers (andrurogerz)


Changes

## Issue
Attempting to run the lldb API tests against a remote-android target fails with 
the error `NameError: name 'urlparse' is not defined`.

## Root Cause
It looks the Python import of `urlparse` was removed by mistake in 
22ea97d7bfd65abf68a68b13bf96ad69be23df54. This import is only used when running 
the lldb API tests against a remote-android target so it went unnoticed.

## Fix
This change simply puts back the missing import. It is a one line change.

fixes 99931

## Validation
Tested on Fedora 39 with an attached Android device:

`cd llvm-project`
`cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS='clang;lldb' 
-DCMAKE_BUILD_TYPE=Release -DLLDB_ENABLE_PYTHON=On`
`ninja -C build`
`./build/bin/lldb-dotest --arch aarch64 --out-of-tree-debugserver 
--platform-name=remote-android --platform-working-dir=/data/local/tmp/ds2 
--platform-url=connect://localhost:5432 --compiler 
~/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin/clang`

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


1 Files Affected:

- (modified) lldb/packages/Python/lldbsuite/test/lldbplatformutil.py (+1) 


``diff
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py 
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index b7e6f240f59f6..e3c6fd1a99568 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -9,6 +9,7 @@
 import sys
 import os
 from packaging import version
+from urllib.parse import urlparse
 
 # LLDB modules
 import lldb

``




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

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

>From faa1aec645e26145467b94260df7ca3abc012f62 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Wed, 17 Jul 2024 02:21:21 -0700
Subject: [PATCH] [lldb/Commands] Add `scripting template list` command with
 auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.

Signed-off-by: Med Ismail Bennani 
---
 lldb/include/lldb/Core/PluginManager.h|  20 +++
 .../Interfaces/ScriptedInterface.h|   7 +
 .../Interfaces/ScriptedInterfaceUsages.h  |  43 ++
 lldb/include/lldb/lldb-private-interfaces.h   |   3 +
 .../Commands/CommandObjectScripting.cpp   | 127 +-
 lldb/source/Commands/Options.td   |   6 +
 lldb/source/Core/PluginManager.cpp|  65 +
 lldb/source/Interpreter/CMakeLists.txt|   4 +
 .../Interpreter/Interfaces/CMakeLists.txt |  10 ++
 .../Interfaces/ScriptedInterfaceUsages.cpp|  37 +
 lldb/source/Plugins/CMakeLists.txt|   3 +
 .../Python/Interfaces/CMakeLists.txt  |   6 +
 .../OperatingSystemPythonInterface.cpp|  17 +++
 .../OperatingSystemPythonInterface.h  |  13 +-
 .../ScriptedProcessPythonInterface.cpp|  23 
 .../ScriptedProcessPythonInterface.h  |  13 +-
 .../ScriptedThreadPlanPythonInterface.cpp |  18 +++
 .../ScriptedThreadPlanPythonInterface.h   |  13 +-
 18 files changed, 423 insertions(+), 5 deletions(-)
 create mode 100644 
lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h
 create mode 100644 lldb/source/Interpreter/Interfaces/CMakeLists.txt
 create mode 100644 
lldb/source/Interpreter/Interfaces/ScriptedInterfaceUsages.cpp

diff --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index f2296e2920238..8c1b93f1653d3 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -10,6 +10,7 @@
 #define LLDB_CORE_PLUGINMANAGER_H
 
 #include "lldb/Core/Architecture.h"
+#include "lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h"
 #include "lldb/Symbol/TypeSystem.h"
 #include "lldb/Utility/CompletionRequest.h"
 #include "lldb/Utility/FileSpec.h"
@@ -487,6 +488,25 @@ class PluginManager {
 
   static LanguageSet GetAllTypeSystemSupportedLanguagesForExpressions();
 
+  // Scripted Interface
+  static bool RegisterPlugin(llvm::StringRef name, llvm::StringRef description,
+ ScriptedInterfaceCreateInstance create_callback,
+ lldb::ScriptLanguage language,
+ ScriptedInterfaceUsages usages);
+
+  static bool UnregisterPlugin(ScriptedInterfaceCreateInstance 
create_callback);
+
+  static uint32_t GetNumScriptedInterfaces();
+
+  static llvm::StringRef GetScriptedInterfaceNameAtIndex(uint32_t idx);
+
+  static llvm::StringRef GetScriptedInterfaceDescriptionAtIndex(uint32_t idx);
+
+  static lldb::ScriptLanguage GetScriptedInterfaceLanguageAtIndex(uint32_t 
idx);
+
+  static ScriptedInterfaceUsages
+  GetScriptedInterfaceUsagesAtIndex(uint32_t idx);
+
   // REPL
   static bool RegisterPlugin(llvm::StringRef name, llvm::StringRef description,
  REPLCreateInstance create_callback,
diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h 
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
index 69504dbcda5dc..3ce47d0584a8a 100644
--- a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterface.h
@@ -9,6 +9,8 @@
 #ifndef LLDB_INTERPRETER_INTERFACES_SCRIPTEDINTERFACE_H
 #define LLDB_INTERPRETER_INTERFACES_SCRIPTEDINTERFACE_H
 
+#include "ScriptedInterfaceUsages.h"
+
 #include "lldb/Core/StructuredDataImpl.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
@@ -68,6 +70,11 @@ class ScriptedInterface {
 return true;
   }
 
+  static bool CreateInstance(lldb::ScriptLanguage language,
+ ScriptedInterfaceUsages usages) {
+return false;
+  }
+
 protected:
   StructuredData::GenericSP m_object_instance_sp;
 };
diff --git a/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h 
b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h
new file mode 100644
index 0..36c0cfdca546e
--- /dev/null
+++ b/lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h
@@ -0,0 +1,43 @@
+//===-- ScriptedInterfaceUsages.h  -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LL

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse in lldb test utilities (PR #99934)

2024-07-22 Thread Andrew Rogers via lldb-commits


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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse in lldb test utilities (PR #99934)

2024-07-22 Thread Andrew Rogers via lldb-commits


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

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

>From d40b66db50800e83ef2d9a74471e031fae1d78ae Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 22 Jul 2024 13:59:50 -0700
Subject: [PATCH] [lldb/Commands] Add `scripting template list` command with
 auto discovery

This patch introduces a new `template` multiword sub-command to the
`scripting` top-level command. As the name suggests, this sub-command
operates on scripting templates, and currently has the ability to
automatically discover the various scripting extensions that lldb
supports.

Signed-off-by: Med Ismail Bennani 
---
 lldb/include/lldb/Core/PluginManager.h|  20 +++
 .../Interfaces/ScriptedInterface.h|   7 +
 .../Interfaces/ScriptedInterfaceUsages.h  |  43 ++
 lldb/include/lldb/lldb-private-interfaces.h   |   3 +
 .../Commands/CommandObjectScripting.cpp   | 127 +-
 lldb/source/Commands/Options.td   |   6 +
 lldb/source/Core/PluginManager.cpp|  65 +
 lldb/source/Interpreter/CMakeLists.txt|   4 +
 .../Interpreter/Interfaces/CMakeLists.txt |  10 ++
 .../Interfaces/ScriptedInterfaceUsages.cpp|  37 +
 lldb/source/Plugins/CMakeLists.txt|   3 +
 .../Python/Interfaces/CMakeLists.txt  |   9 +-
 .../CMakeLists.txt|  15 +++
 .../OperatingSystemPythonInterface.cpp|  24 +++-
 .../OperatingSystemPythonInterface.h  |  18 ++-
 .../CMakeLists.txt|  15 +++
 .../ScriptedPlatformPythonInterface.cpp   |  23 +++-
 .../ScriptedPlatformPythonInterface.h |  17 ++-
 .../CMakeLists.txt|  15 +++
 .../ScriptedProcessPythonInterface.cpp|  36 -
 .../ScriptedProcessPythonInterface.h  |  18 ++-
 .../CMakeLists.txt|  15 +++
 .../ScriptedThreadPlanPythonInterface.cpp |  25 +++-
 .../ScriptedThreadPlanPythonInterface.h   |  18 ++-
 .../Python/ScriptInterpreterPython.cpp|   8 +-
 25 files changed, 538 insertions(+), 43 deletions(-)
 create mode 100644 
lldb/include/lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h
 create mode 100644 lldb/source/Interpreter/Interfaces/CMakeLists.txt
 create mode 100644 
lldb/source/Interpreter/Interfaces/ScriptedInterfaceUsages.cpp
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/OperatingSystemPythonInterface/CMakeLists.txt
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
OperatingSystemPythonInterface}/OperatingSystemPythonInterface.cpp (77%)
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
OperatingSystemPythonInterface}/OperatingSystemPythonInterface.h (83%)
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedPlatformPythonInterface/CMakeLists.txt
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedPlatformPythonInterface}/ScriptedPlatformPythonInterface.cpp (85%)
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedPlatformPythonInterface}/ScriptedPlatformPythonInterface.h (84%)
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedProcessPythonInterface/CMakeLists.txt
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedProcessPythonInterface}/ScriptedProcessPythonInterface.cpp (86%)
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedProcessPythonInterface}/ScriptedProcessPythonInterface.h (88%)
 create mode 100644 
lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/ScriptedThreadPlanPythonInterface/CMakeLists.txt
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedThreadPlanPythonInterface}/ScriptedThreadPlanPythonInterface.cpp (79%)
 rename lldb/source/Plugins/ScriptInterpreter/Python/Interfaces/{ => 
ScriptedThreadPlanPythonInterface}/ScriptedThreadPlanPythonInterface.h (82%)

diff --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index 38a291d9f0afd..a23f834f471fb 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -10,6 +10,7 @@
 #define LLDB_CORE_PLUGINMANAGER_H
 
 #include "lldb/Core/Architecture.h"
+#include "lldb/Interpreter/Interfaces/ScriptedInterfaceUsages.h"
 #include "lldb/Symbol/TypeSystem.h"
 #include "lldb/Utility/CompletionRequest.h"
 #include "lldb/Utility/FileSpec.h"
@@ -487,6 +488,25 @@ class PluginManager {
 
   static LanguageSet GetAllTypeSystemSupportedLanguagesForExpressions();
 
+  // Scripted Interface
+  static bool RegisterPlugin(llvm::StringRef name, llvm::StringRef description,
+ ScriptedInterfaceCreateInstance create_callback,
+ lldb::ScriptLanguage language,
+ ScriptedInterfaceUsages usages);
+
+  static bool UnregisterPlugin(Scrip

[Lldb-commits] [lldb] [lldb/Commands] Add `scripting template list` command with auto discovery (PR #97273)

2024-07-22 Thread Alex Langford via lldb-commits


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

LGTM, you'll probably want sign off from Jonas too though since he had a ton of 
comments.

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -299,6 +301,35 @@ SBPlatform::SBPlatform(const char *platform_name) {
   m_opaque_sp = Platform::Create(platform_name);
 }
 
+SBPlatform::SBPlatform(const char *platform_name, const SBDebugger &debugger,
+   const char *script_name, const SBStructuredData &dict)
+: SBPlatform(platform_name) {
+  LLDB_INSTRUMENT_VA(this, platform_name, debugger, script_name, dict);
+
+  if (!m_opaque_sp)
+return;
+
+  if (!script_name || !dict.IsValid() || !dict.m_impl_up)

bulbazord wrote:

Problem: Exiting here with a valid `m_opaque_sp` means that the created 
`SBPlatform` will look valid, but it won't be the one you expect to get back. I 
would suggest creating a separate constructor that does not call another 
constructor (in case the base constructor succeeds) OR creating a static 
constructor method. That goes for every early return.

nit: Checking `!dict.m_impl_up` is going to be redundant right? We should 
always have an existing unique_ptr there.

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {

bulbazord wrote:

2 Questions about this method:
1. What is a `ScriptedObject` in this context?
2. Why does this return a `bool` and take a mutable `Status &` as argument? Why 
doesn't it just return a `Status` object directly?

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");

bulbazord wrote:

nit: The error message isn't really accurate right? It's not a `Debugger` 
language as much as it's a `Scripting` language here.

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -10,6 +10,7 @@
 #define LLDB_SOURCE_COMMANDS_COMMANDOBJECTPLATFORM_H
 
 #include "lldb/Interpreter/CommandObjectMultiword.h"
+#include "lldb/Interpreter/OptionGroupPlatform.h"

bulbazord wrote:

Why do you need this include here?

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -299,6 +301,35 @@ SBPlatform::SBPlatform(const char *platform_name) {
   m_opaque_sp = Platform::Create(platform_name);
 }
 
+SBPlatform::SBPlatform(const char *platform_name, const SBDebugger &debugger,
+   const char *script_name, const SBStructuredData &dict)
+: SBPlatform(platform_name) {
+  LLDB_INSTRUMENT_VA(this, platform_name, debugger, script_name, dict);
+
+  if (!m_opaque_sp)

bulbazord wrote:

Does this mean it isn't going to be possible to define a completely 
different/standalone platform that lldb doesn't know about a priori with 
scripted platforms?

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -299,6 +301,35 @@ SBPlatform::SBPlatform(const char *platform_name) {
   m_opaque_sp = Platform::Create(platform_name);
 }
 
+SBPlatform::SBPlatform(const char *platform_name, const SBDebugger &debugger,
+   const char *script_name, const SBStructuredData &dict)
+: SBPlatform(platform_name) {
+  LLDB_INSTRUMENT_VA(this, platform_name, debugger, script_name, dict);
+
+  if (!m_opaque_sp)
+return;
+
+  if (!script_name || !dict.IsValid() || !dict.m_impl_up)
+return;
+
+  StructuredData::ObjectSP obj_sp = dict.m_impl_up->GetObjectSP();
+
+  if (!obj_sp)
+return;
+
+  StructuredData::DictionarySP dict_sp =
+  std::make_shared(obj_sp);
+  if (!dict_sp || dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
+return;
+
+  const ScriptedMetadata scripted_metadata(script_name, dict_sp);
+
+  auto metadata =

bulbazord wrote:

nit: name this one `platform_metadata` since you also have a variable called 
`scripted_metadata` above. `scripted_metadata` and `metadata` is a bit 
confusing to read IMO.

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {
+  if (!m_metadata)
+return false;
+
+  Status error;
+  return SetupScriptedObject(error);
+}
+
+void ScriptedPlatform::Initialize() {
+  if (g_initialize_count++ == 0) {

bulbazord wrote:

Why does this get initialized multiple times? Once per script?

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -15,8 +15,8 @@
 namespace lldb_private {
 class ScriptedMetadata {
 public:
-  ScriptedMetadata(llvm::StringRef class_name,
-   StructuredData::DictionarySP dict_sp)
+  ScriptedMetadata(const llvm::StringRef class_name,
+   const StructuredData::DictionarySP dict_sp)
   : m_class_name(class_name.data()), m_args_sp(dict_sp) {}

bulbazord wrote:

Not related to this PR, but we should probably be initializing `m_class_name` 
with `class_name.str()` and not `class_name.data()`.

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);

bulbazord wrote:

Do you need this explicit ArrayRef definition? Or can you just do this?
```
return llvm::is_contained({g_supported_script_languages}, language);
```

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

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {
+  if (!m_metadata)
+return false;
+
+  Status error;
+  return SetupScriptedObject(error);
+}
+
+void ScriptedPlatform::Initialize() {
+  if (g_initialize_count++ == 0) {
+// NOTE: This should probably be using the driving process platform
+PluginManager::RegisterPlugin(ScriptedPlatform::GetPluginNameStatic(),
+  ScriptedPlatform::GetDescriptionStatic(),
+  ScriptedPlatform::CreateInstance);
+  }
+}
+
+void ScriptedPlatform::Terminate() {
+  if (g_initialize_count > 0) {
+if (--g_initialize_count == 0) {
+  PluginManager::UnregisterPlugin(ScriptedPlatform::CreateInstance);
+}
+  }
+}
+
+std::vector
+ScriptedPlatform::GetSupportedArchitectures(const ArchSpec &process_host_arch) 
{
+  std::vector result;
+  result.push_back(process_host_arch);
+  return result;
+}
+
+lldb::ProcessSP
+ScriptedPlatform::Attach(lldb_private::ProcessAttachInfo &attach_info,
+ lldb_private::Debugger &debugger,
+ lldb_private::Target *target, // Can be nullptr, if
+   // nullptr create a new
+   // target, else use
+   // existing one
+ lldb_private::Status &error) {
+  lldb::ProcessAttachInfoSP attach

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {
+  if (!m_metadata)
+return false;
+
+  Status error;
+  return SetupScriptedObject(error);
+}
+
+void ScriptedPlatform::Initialize() {
+  if (g_initialize_count++ == 0) {
+// NOTE: This should probably be using the driving process platform
+PluginManager::RegisterPlugin(ScriptedPlatform::GetPluginNameStatic(),
+  ScriptedPlatform::GetDescriptionStatic(),
+  ScriptedPlatform::CreateInstance);
+  }
+}
+
+void ScriptedPlatform::Terminate() {
+  if (g_initialize_count > 0) {
+if (--g_initialize_count == 0) {
+  PluginManager::UnregisterPlugin(ScriptedPlatform::CreateInstance);
+}
+  }
+}
+
+std::vector
+ScriptedPlatform::GetSupportedArchitectures(const ArchSpec &process_host_arch) 
{
+  std::vector result;
+  result.push_back(process_host_arch);
+  return result;
+}
+
+lldb::ProcessSP
+ScriptedPlatform::Attach(lldb_private::ProcessAttachInfo &attach_info,
+ lldb_private::Debugger &debugger,
+ lldb_private::Target *target, // Can be nullptr, if
+   // nullptr create a new
+   // target, else use
+   // existing one
+ lldb_private::Status &error) {
+  lldb::ProcessAttachInfoSP attach

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

2024-07-22 Thread Alex Langford via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {

bulbazord wrote:

Why does this return a `bool`? If you want to know what happened, does it not 
make sense to return a `Status` object directly? Or an `llvm::Error` if that's 
your thing.

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

[Lldb-commits] [lldb] lldb: android: fix missing Python import of urlparse in lldb test utilities (PR #99934)

2024-07-22 Thread Saleem Abdulrasool via lldb-commits


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


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

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits



@@ -299,6 +301,35 @@ SBPlatform::SBPlatform(const char *platform_name) {
   m_opaque_sp = Platform::Create(platform_name);
 }
 
+SBPlatform::SBPlatform(const char *platform_name, const SBDebugger &debugger,
+   const char *script_name, const SBStructuredData &dict)
+: SBPlatform(platform_name) {
+  LLDB_INSTRUMENT_VA(this, platform_name, debugger, script_name, dict);
+
+  if (!m_opaque_sp)

medismailben wrote:

new user-defined standalone scripted platform instances, yes

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -160,6 +160,8 @@ class LLDB_API SBProcess {
 
   lldb::SBError Continue();
 
+  lldb::SBError ReverseContinue();

rocallahan wrote:

Yeah OK.

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -1395,6 +1395,94 @@ Status ProcessGDBRemote::DoResume() {
   return error;
 }
 
+Status ProcessGDBRemote::DoResumeReverse() {
+  Status error;
+  Log *log = GetLog(GDBRLog::Process);
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse()");
+
+  ListenerSP listener_sp(
+  Listener::MakeListener("gdb-remote.resume-packet-sent"));
+  if (listener_sp->StartListeningForEvents(
+  &m_gdb_comm, GDBRemoteClientBase::eBroadcastBitRunPacketSent)) {
+listener_sp->StartListeningForEvents(
+&m_async_broadcaster,
+ProcessGDBRemote::eBroadcastBitAsyncThreadDidExit);
+
+const size_t num_threads = GetThreadList().GetSize();
+
+StreamString continue_packet;
+
+// Number of threads continuing with "C", i.e. continuing with a signal to 
deliver.
+const size_t num_continue_C_tids = m_continue_C_tids.size();
+// Number of threads continuing with "s", i.e. single-stepping.
+const size_t num_continue_s_tids = m_continue_s_tids.size();
+// Number of threads continuing with "S", i.e. single-stepping with a 
signal to deliver.
+const size_t num_continue_S_tids = m_continue_S_tids.size();
+// We can only `bc` to reverse-continue all threads,
+// or `bs` to reverse-step the current thread (which may also
+// reverse-continue other threads by some amount).
+// These packets do not support delivering signals.
+if (num_continue_C_tids > 0 || num_continue_S_tids > 0) {
+  error.SetErrorString("can't deliver signals while running in reverse");
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: Signals not 
supported");
+  return error;
+}
+
+if (num_continue_s_tids > 0) {
+  if (num_continue_s_tids > 1) {
+error.SetErrorString("can't step multiple threads while 
reverse-stepping");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: can't step multiple 
threads");
+return error;
+  }
+
+  if (!m_gdb_comm.GetReverseStepSupported()) {
+error.SetErrorString("target does not support reverse-stepping");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: target does not 
support reverse-stepping");
+return error;
+  }
+
+  m_gdb_comm.SetCurrentThreadForRun(m_continue_s_tids.front());
+  continue_packet.PutCString("bs");
+} else {
+  if (!m_gdb_comm.GetReverseContinueSupported()) {
+error.SetErrorString("target does not support reverse-continue");
+LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: target does not 
support reverse-continue");
+return error;
+  }
+
+  // All threads continue whether requested or not ---
+  // we can't change how threads ran in the past.
+  continue_packet.PutCString("bc");
+}
+
+EventSP event_sp;
+if (!m_async_thread.IsJoinable()) {
+  error.SetErrorString("Trying to resume but the async thread is dead.");
+  LLDB_LOGF(log, "ProcessGDBRemote::DoResumeReverse: Trying to resume but 
the "
+ "async thread is dead.");
+  return error;
+}
+
+auto data_sp =
+std::make_shared(continue_packet.GetString());
+m_async_broadcaster.BroadcastEvent(eBroadcastBitAsyncContinue, data_sp);
+
+if (!listener_sp->GetEvent(event_sp, std::chrono::seconds(5))) {

rocallahan wrote:

This was copied from `ProcessGDBRemote::DoResume()`. I can refactor that.

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
   // filters before resuming.
   UpdateAutomaticSignalFiltering();
 
+  if (m_last_run_direction != direction) {

rocallahan wrote:

TBH I don't understand thread plans very well yet so I was trying to avoid 
interacting with them. I guess implementing your suggestion means extending 
thread plans with a `RunDirection`, and/or creating new plan subclasses? And 
then we'd have to test a lot of interactions. Would it be OK to defer that to a 
future patch to keep this patch reasonably small?

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
   // filters before resuming.
   UpdateAutomaticSignalFiltering();
 
+  if (m_last_run_direction != direction) {

rocallahan wrote:

I'm a bit worried that in general thread plans have a lot of complexity, and 
adding more complexity by allowing multiple stacked plans with different 
directions might be bad enough for maintainability that it's overall a bad idea.

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
   // filters before resuming.
   UpdateAutomaticSignalFiltering();
 
+  if (m_last_run_direction != direction) {

rocallahan wrote:

If the user does "continue", hits a breakpoint, does "reverse-step", and then 
"reverse-continue" presumably we do have to abandon the original "continue". 
Since this patch only implements "reverse-continue" maybe always abandoning the 
thread plans actually the right thing to do for now?

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

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {

medismailben wrote:

1. A Scripted Object is the class instance that we will use to make the calls 
to.
2. This could just return an `llvm::Error` actually.

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits


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

[Lldb-commits] [clang] [lldb] [llvm] [BOLT][DWARF][NFC] Split processUnitDIE into two lambdas (PR #99957)

2024-07-22 Thread Sayhaan Siddiqui via lldb-commits


https://github.com/sayhaan created 
https://github.com/llvm/llvm-project/pull/99957

Split processUnitDIE into two lambdas to separate the processing of DWO CUs and 
CUs in the main binary.

>From 29feff4a9abed4bacb6615232daed84269d4a699 Mon Sep 17 00:00:00 2001
From: Amir Ayupov 
Date: Tue, 1 Jun 2021 11:37:41 -0700
Subject: [PATCH 1/2] Rebase: [Facebook] Add clang driver options to test debug
 info and BOLT

Summary:
This is an essential piece of infrastructure for us to be
continuously testing debug info with BOLT. We can't only make changes
to a test repo because we need to change debuginfo tests to call BOLT,
hence, this diff needs to sit in our opensource repo. But when upstreaming
to LLVM, this should be kept BOLT-only outside of LLVM. When upstreaming,
we need to git diff and check all folders that are being modified by our
commits and discard this one (and leave as an internal diff).

To test BOLT in debuginfo tests, configure it with -DLLVM_TEST_BOLT=ON.
Then run check-lldb and check-debuginfo.

Manual rebase conflict history:
https://phabricator.intern.facebook.com/D29205224
https://phabricator.intern.facebook.com/D29564078
https://phabricator.intern.facebook.com/D33289118
https://phabricator.intern.facebook.com/D34957174
https://phabricator.intern.facebook.com/D35317341

Test Plan:
tested locally
Configured with:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;compiler-rt;bolt;debuginfo-tests"
-DLLVM_TEST_BOLT=ON
Ran test suite with:
ninja check-debuginfo
ninja check-lldb

Reviewers: maks, #llvm-bolt

Reviewed By: maks

Subscribers: ayermolo, phabricatorlinter

Differential Revision: https://phabricator.intern.facebook.com/D46256657

Tasks: T92898286
---
 clang/include/clang/Driver/Options.td  |  4 
 clang/lib/Driver/ToolChains/Gnu.cpp| 29 ++
 cross-project-tests/lit.cfg.py | 14 -
 cross-project-tests/lit.site.cfg.py.in |  4 
 lldb/test/API/lit.cfg.py   |  5 +
 lldb/test/API/lit.site.cfg.py.in   |  8 +++
 lldb/test/Shell/helper/toolchain.py|  5 +
 lldb/test/Shell/lit.site.cfg.py.in |  9 
 llvm/CMakeLists.txt|  4 
 9 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 9c6cebd77ff0a..8ccbc4b372ba3 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5553,6 +5553,10 @@ def pg : Flag<["-"], "pg">, HelpText<"Enable mcount 
instrumentation">,
   MarshallingInfoFlag>;
 def pipe : Flag<["-", "--"], "pipe">,
   HelpText<"Use pipes between commands, when possible">;
+// Facebook T92898286
+def post_link_optimize : Flag<["--"], "post-link-optimize">,
+  HelpText<"Apply post-link optimizations using BOLT">;
+// End Facebook T92898286
 def prebind__all__twolevel__modules : Flag<["-"], 
"prebind_all_twolevel_modules">;
 def prebind : Flag<["-"], "prebind">;
 def preload : Flag<["-"], "preload">;
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 52c2ee90b1b28..ff20deb9c4f86 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -672,12 +672,41 @@ void tools::gnutools::Linker::ConstructJob(Compilation 
&C, const JobAction &JA,
 }
   }
 
+  // Facebook T92898286
+  if (Args.hasArg(options::OPT_post_link_optimize))
+CmdArgs.push_back("-q");
+  // End Facebook T92898286
+
   Args.AddAllArgs(CmdArgs, options::OPT_T);
 
   const char *Exec = Args.MakeArgString(ToolChain.GetLinkerPath());
   C.addCommand(std::make_unique(JA, *this,
  ResponseFileSupport::AtFileCurCP(),
  Exec, CmdArgs, Inputs, Output));
+  // Facebook T92898286
+  if (!Args.hasArg(options::OPT_post_link_optimize) || !Output.isFilename())
+return;
+
+  const char *MvExec = Args.MakeArgString(ToolChain.GetProgramPath("mv"));
+  ArgStringList MoveCmdArgs;
+  MoveCmdArgs.push_back(Output.getFilename());
+  const char *PreBoltBin =
+  Args.MakeArgString(Twine(Output.getFilename()) + ".pre-bolt");
+  MoveCmdArgs.push_back(PreBoltBin);
+  C.addCommand(std::make_unique(JA, *this, 
ResponseFileSupport::None(),
+ MvExec, MoveCmdArgs, std::nullopt));
+
+  ArgStringList BoltCmdArgs;
+  const char *BoltExec =
+  Args.MakeArgString(ToolChain.GetProgramPath("llvm-bolt"));
+  BoltCmdArgs.push_back(PreBoltBin);
+  BoltCmdArgs.push_back("-reorder-blocks=reverse");
+  BoltCmdArgs.push_back("-update-debug-sections");
+  BoltCmdArgs.push_back("-o");
+  BoltCmdArgs.push_back(Output.getFilename());
+  C.addCommand(std::make_unique(JA, *this, 
ResponseFileSupport::None(),
+ BoltExec, BoltCmdArgs, std::nullopt));
+  // End Facebook T92898286
 }
 
 void tools::gnutools::Assembler::ConstructJob(Compilation &C,
diff --git a/cross-project-tests/lit.cfg.py b/cross-proje

[Lldb-commits] [lldb] [lldb][debugserver] Retry sleep(0.25s) when interrupted (PR #99962)

2024-07-22 Thread Jason Molenda via lldb-commits


https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/99962

After lldb has ptrace()'ed the process, it sleeps for 0.25 seconds before 
trying to pause the process.  We see logging that in some rare cases, this 
sleep is interrupted and the pause fails, the attach fails.  usleep(3) says 
that the only errno it will return is EINTR if interrupted, so retry on that 
case.  I capped it at four retries so the process can't hang infinitely if it's 
being spammed with asynchronous signals.

I don't know what environment setup results in this behavior, it's only rarely 
seen by end users and we see evidence, after the fact of it, in logging.

rdar://131602093

>From 01255f7c906c9b5995b0f33c420c7c7eb707bddf Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Mon, 22 Jul 2024 14:55:04 -0700
Subject: [PATCH] [lldb][debugserver] Retry sleep(0.25s) when interrupted

After lldb has ptrace()'ed the process, it sleeps for 0.25 seconds
before trying to pause the process.  We see logging that in some
rare cases, this sleep is interrupted and the pause fails.  usleep(3)
says that the only errno it will return is EINTR if interrupted,
so retry on that case.  I capped it at four retries so the process
can't hang infinitely if it's being spammed with asynchronous
signals.

I don't know what environment setup results in this behavior,
it's only rarely seen by end users and we see evidence, after
the factof it, in logging.

rdar://131602093
---
 lldb/tools/debugserver/source/MacOSX/MachProcess.mm | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm 
b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
index cbe3c5459e91f..89c031fdc75d6 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
@@ -2846,9 +2846,12 @@ static uint64_t bits(uint64_t value, uint32_t msbit, 
uint32_t lsbit) {
 if (err.Success()) {
   m_flags |= eMachProcessFlagsAttached;
   // Sleep a bit to let the exception get received and set our process
-  // status
-  // to stopped.
-  ::usleep(25);
+  // status to stopped.
+  int max_retry = 4;
+  do {
+errno = 0;
+usleep(25); // If our 0.25 second sleep is interrupted, redo
+  } while (errno == EINTR && --max_retry > 0);
   DNBLog("[LaunchAttach] (%d) Done napping after ptrace(PT_ATTACHEXC)'ing",
  getpid());
   DNBLogThreadedIf(LOG_PROCESS, "successfully attached to pid %d", pid);

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

[Lldb-commits] [lldb] [lldb][debugserver] Retry sleep(0.25s) when interrupted (PR #99962)

2024-07-22 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

After lldb has ptrace()'ed the process, it sleeps for 0.25 seconds before 
trying to pause the process.  We see logging that in some rare cases, this 
sleep is interrupted and the pause fails, the attach fails.  usleep(3) says 
that the only errno it will return is EINTR if interrupted, so retry on that 
case.  I capped it at four retries so the process can't hang infinitely if it's 
being spammed with asynchronous signals.

I don't know what environment setup results in this behavior, it's only rarely 
seen by end users and we see evidence, after the fact of it, in logging.

rdar://131602093

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


1 Files Affected:

- (modified) lldb/tools/debugserver/source/MacOSX/MachProcess.mm (+6-3) 


``diff
diff --git a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm 
b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
index cbe3c5459e91f..89c031fdc75d6 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
@@ -2846,9 +2846,12 @@ static uint64_t bits(uint64_t value, uint32_t msbit, 
uint32_t lsbit) {
 if (err.Success()) {
   m_flags |= eMachProcessFlagsAttached;
   // Sleep a bit to let the exception get received and set our process
-  // status
-  // to stopped.
-  ::usleep(25);
+  // status to stopped.
+  int max_retry = 4;
+  do {
+errno = 0;
+usleep(25); // If our 0.25 second sleep is interrupted, redo
+  } while (errno == EINTR && --max_retry > 0);
   DNBLog("[LaunchAttach] (%d) Done napping after ptrace(PT_ATTACHEXC)'ing",
  getpid());
   DNBLogThreadedIf(LOG_PROCESS, "successfully attached to pid %d", pid);

``




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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -3281,7 +3288,11 @@ Status Process::PrivateResume() {
 "Process::PrivateResume PreResumeActions failed, not resuming.");
   } else {
 m_mod_id.BumpResumeID();
-error = DoResume();
+if (direction == eRunForward) {
+  error = DoResume();

rocallahan wrote:

The advantage of separate `DoResume()` and `DoResumeReverse()` methods is that 
`Process` subclasses that don't support reverse execution don't have to change 
at all; they inherit the default `DoResumeReverse()` that returns an error. If 
I make `DoResume()` take a direction parameter then those implementations 
(three out of four AFAICT) need to add a check of the direction parameter. It's 
not a big deal, I'll change it.

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

[Lldb-commits] [lldb] [lldb][debugserver] Retry sleep(0.25s) when interrupted (PR #99962)

2024-07-22 Thread Jason Molenda via lldb-commits


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

[Lldb-commits] [lldb] [lldb][debugserver] Retry sleep(0.25s) when interrupted (PR #99962)

2024-07-22 Thread Jason Molenda via lldb-commits


jasonmolenda wrote:

Ah, Jonas points out that I've fixed the wrong sleep.  He has a patch he'll put 
up for the real problem.  This does not fix a known problem.

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

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

2024-07-22 Thread via lldb-commits

jimingham wrote:

> On Jul 22, 2024, at 2:52 PM, rocallahan ***@***.***> wrote:
> 
> 
> @rocallahan commented on this pull request.
> 
> In lldb/source/Target/Process.cpp 
> :
> 
> > @@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
>// filters before resuming.
>UpdateAutomaticSignalFiltering();
>  
> +  if (m_last_run_direction != direction) {
> TBH I don't understand thread plans very well yet so I was trying to avoid 
> interacting with them. I guess implementing your suggestion means extending 
> thread plans with a RunDirection, and/or creating new plan subclasses? And 
> then we'd have to test a lot of interactions. Would it be OK to defer that to 
> a future patch to keep this patch reasonably small?
> 
Oh, for sure.  

In the end you will have to do something of that sort.  Otherwise you'll get 
unexpected behavior mixing forward & backwards stepping.  Plans that complete 
without interruption should be fine, but ones returning control to the user 
will start to cancel each other out, and that will get confusing.  

However, straight-line execution forward or backwards should be fine, and 
forward/backwards continue are not affected by this either.  So this should 
still be mostly functional without the added complexity, making it appropriate 
to do that work as a follow-on.

Jim

> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 

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

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

2024-07-22 Thread via lldb-commits

jimingham wrote:

> On Jul 22, 2024, at 2:56 PM, rocallahan ***@***.***> wrote:
> 
> 
> @rocallahan commented on this pull request.
> 
> In lldb/source/Target/Process.cpp 
> :
> 
> > @@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
>// filters before resuming.
>UpdateAutomaticSignalFiltering();
>  
> +  if (m_last_run_direction != direction) {
> If the user does "continue", hits a breakpoint, does "reverse-step", and then 
> "reverse-continue" presumably we do have to abandon the original "continue". 
> Since this patch only implements "reverse-continue" maybe always abandoning 
> the thread plans is actually the right thing to do for now?
> 
"Continue" isn't a persistent operation for thread plans.  The thing that would 
be "persistent" in this case would be the "ThreadPlanStepOverRange(forward)" 
plan which the "next" operation pushed on the stack.  When you hit the 
breakpoint, that plan was asked "did you explain this stop" - the answer to 
that was "no" this was just a random breakpoint hit.  It was asked also  "are 
you done" - the answer to which was still no since the next-ing frame is still 
on the stack, and finally "are you stale - no longer relevant" but the frame is 
still on the Thread's stack, so that was answered "false" the 
"ThreadPlanStepOverRange stayed on the ThreadPlan stack.

Then in my scenario I did a couple of forward steps, and some "reverse steps".  
At each point the next plan was asked the same question, and so long as that 
StackFrame is still on the thread stack, the plan stays active.

If you did a reverse-continue that stopped when the process is in a state where 
the next-ing StackFrame is no longer on the stack, that plan will return 
"false" to the "is stale" question and get popped at that point.

But so long as the reverse continues stays in the time-line where that frame is 
on the stack, we should honor the user intentions that came with it.

There are some things you will have to do to make all this really work (for 
instance, a "forward-next" plan can't explain stops from backward execution, so 
the plans will have to know about that.

As I said on another thread, I think you will have to make the plans cooperate 
with forward and backward behavior at some point.  But for this patch it's fine 
to not allow that mixing, and in that case it is probably best to just dump all 
the extant and dumpable plans.

You might have to be careful in the case where someone runs a function call, 
stops at a breakpoint in the function call and decides to go backwards in the 
function execution (if that's possible).  Dumping the function plan removes the 
function calling frames from the stack, so if you throw away that plan you will 
end up exiting the function call - which wasn't what the user expected.

Jim

> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 

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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits


rocallahan wrote:

> You might have to be careful in the case where someone runs a function call, 
> stops at a breakpoint in the function call and decides to go backwards in the 
> function execution (if that's possible).

That is not possible in rr. During user function calls it responds to reverse 
execution requests with an immediate stop.

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

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

2024-07-22 Thread via lldb-commits


jimingham wrote:



> On Jul 22, 2024, at 2:54 PM, rocallahan ***@***.***> wrote:
> 
> 
> @rocallahan commented on this pull request.
> 
> In lldb/source/Target/Process.cpp 
> :
> 
> > @@ -3264,6 +3266,11 @@ Status Process::PrivateResume() {
>// filters before resuming.
>UpdateAutomaticSignalFiltering();
>  
> +  if (m_last_run_direction != direction) {
> I'm a bit worried that in general thread plans have a lot of complexity, and 
> adding more complexity by allowing multiple stacked plans with different 
> directions might be bad enough for maintainability that it's overall a bad 
> idea.
> 
I hope that's not true.  I don't think we need to have the thread plans have 
some pinning to the time-line of the user's actions.  For instance, if you were 
doing a "forward-next", hit a breakpoint and did some forward and backwards 
stepping, then did a backwards continue to a point where that thread no longer 
existed, then a forward continue back to where you started from, we do NOT need 
to preserve the next behavior at that point.  However, so long as the forward 
and backward operations always happen under the frame we were next-ing on, we 
should be able to preserve the behavior in that case. 

It shouldn't be too unnatural, every time we stop we do a sanity check on the 
plans to see if they are still relevant before we return control to the user.  
For instance, if you were nexting over a call that threw an exception, which 
was caught above the frame you were `nexting` in we have to do the same sort of 
"is stale" pruning.  As long as we're appropriately firm about pruning plans as 
they stop being relevant, this should be manageable.

Jim


> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



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

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

2024-07-22 Thread via lldb-commits


jimingham wrote:



> On Jul 22, 2024, at 3:44 PM, rocallahan ***@***.***> wrote:
> 
> 
> You might have to be careful in the case where someone runs a function call, 
> stops at a breakpoint in the function call and decides to go backwards in the 
> function execution (if that's possible).
> 
> That is not possible in rr. During user function calls it responds to reverse 
> execution requests with an immediate stop.
> 
So long as you haven't pruned the plans that control the function call before 
doing that, you should be fine.

Jim



> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because you are on a team that was mentioned.
> 



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

[Lldb-commits] [lldb] [lldb][debugserver] Retry sleep(0.25s) when interrupted (PR #99962)

2024-07-22 Thread Jason Molenda via lldb-commits


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

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

2024-07-22 Thread Robert O'Callahan via lldb-commits


https://github.com/rocallahan updated 
https://github.com/llvm/llvm-project/pull/99736

>From 5ecca71b03027e132f3b75612c0783a68eafdf4f Mon Sep 17 00:00:00 2001
From: Robert O'Callahan 
Date: Fri, 19 Jul 2024 22:46:42 +1200
Subject: [PATCH] [lldb] Implement basic support for reverse-continue

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command
for this will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`)
providing support for the `bc` and `bs` packets. `lldb-server`
does not support those packets, and there is no plan to change that.
So, for testing purposes, `lldbreverse.py` wraps `lldb-server`
with a Python implementation of *very limited* record-and-replay
functionality.
---
 lldb/include/lldb/API/SBProcess.h |   2 +-
 lldb/include/lldb/Target/Process.h|  20 +-
 lldb/include/lldb/Target/StopInfo.h   |   3 +
 lldb/include/lldb/lldb-enumerations.h |   6 +
 .../Python/lldbsuite/test/gdbclientutils.py   |   5 +-
 .../Python/lldbsuite/test/lldbgdbproxy.py | 176 
 .../Python/lldbsuite/test/lldbreverse.py  | 418 ++
 .../Python/lldbsuite/test/lldbtest.py |   2 +
 lldb/source/API/SBProcess.cpp |   6 +-
 lldb/source/API/SBThread.cpp  |   2 +
 .../source/Interpreter/CommandInterpreter.cpp |   3 +-
 .../Process/Linux/NativeThreadLinux.cpp   |   3 +
 .../Process/MacOSX-Kernel/ProcessKDP.cpp  |   9 +-
 .../Process/MacOSX-Kernel/ProcessKDP.h|   2 +-
 .../Process/Windows/Common/ProcessWindows.cpp |   8 +-
 .../Process/Windows/Common/ProcessWindows.h   |   2 +-
 .../GDBRemoteCommunicationClient.cpp  |  22 +
 .../gdb-remote/GDBRemoteCommunicationClient.h |   6 +
 .../GDBRemoteCommunicationServerLLGS.cpp  |   1 +
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |  78 +++-
 .../Process/gdb-remote/ProcessGDBRemote.h |   2 +-
 .../Process/scripted/ScriptedProcess.cpp  |  11 +-
 .../Process/scripted/ScriptedProcess.h|   2 +-
 lldb/source/Target/Process.cpp|  25 +-
 lldb/source/Target/StopInfo.cpp   |  29 ++
 lldb/source/Target/Thread.cpp |   8 +-
 .../reverse-execution/Makefile|   3 +
 .../TestReverseContinueBreakpoints.py | 119 +
 .../TestReverseContinueNotSupported.py|  29 ++
 .../functionalities/reverse-execution/main.c  |  14 +
 lldb/tools/lldb-dap/JSONUtils.cpp |   3 +
 lldb/tools/lldb-dap/LLDBUtils.cpp |   1 +
 32 files changed, 976 insertions(+), 44 deletions(-)
 create mode 100644 lldb/packages/Python/lldbsuite/test/lldbgdbproxy.py
 create mode 100644 lldb/packages/Python/lldbsuite/test/lldbreverse.py
 create mode 100644 lldb/test/API/functionalities/reverse-execution/Makefile
 create mode 100644 
lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py
 create mode 100644 
lldb/test/API/functionalities/reverse-execution/TestReverseContinueNotSupported.py
 create mode 100644 lldb/test/API/functionalities/reverse-execution/main.c

diff --git a/lldb/include/lldb/API/SBProcess.h 
b/lldb/include/lldb/API/SBProcess.h
index 778be79583990..cb7775ae94e46 100644
--- a/lldb/include/lldb/API/SBProcess.h
+++ b/lldb/include/lldb/API/SBProcess.h
@@ -158,7 +158,7 @@ class LLDB_API SBProcess {
 
   lldb::SBError Destroy();
 
-  lldb::SBError Continue();
+  lldb::SBError Continue(RunDirection direction = RunDirection::eRunForward);
 
   lldb::SBError Stop();
 
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index c8475db8ae160..51d9c166fdda5 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -874,10 +874,10 @@ class Process : public 
std::enable_shared_from_this,
   /// \see Thread:Resume()
   /// \see Thread:Step()
   /// \see Thread:Suspend()
-  Status Resume();
+  Status Resume(lldb::RunDirection direction = lldb::eRunForward);
 
   /// Resume a process, and wait for it to stop.
-  Status ResumeSynchronous(Stream *stream);
+  Status ResumeSynchronous(Stream *stream, lldb::RunDirection direction = 
lldb::eRunForward);
 
   /// Halts a running process.
   ///
@@ -1129,10 +1129,15 @@ class Process : public 
std::enable_shared_from_this,
   /// \see Thread:Resume()
   /// \see Thread:Step()
   /// \see Thread:Suspend()
-  virtual Status DoResume() {
+  virtual Status DoResume(lldb::RunDirection direction) {
 Status error;
-error.SetErrorStringWithFormatv(
-"error: {0} does not support resuming processes", GetPluginName());
+if (direction == lldb::RunDirection::eRunForward) {
+  error.SetErrorStringWithFormatv(
+  "error: {0} does not support resuming processes", GetPluginName());
+} else {
+  error.SetErrorStringWithFormatv(
+  "error: {0} does not support reverse execution of processes", 
GetPluginName());
+}
 return error;
   }
 
@@ -2

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

2024-07-22 Thread Robert O'Callahan via lldb-commits



@@ -3281,7 +3288,11 @@ Status Process::PrivateResume() {
 "Process::PrivateResume PreResumeActions failed, not resuming.");
   } else {
 m_mod_id.BumpResumeID();
-error = DoResume();
+if (direction == eRunForward) {
+  error = DoResume();

rocallahan wrote:

I've updated the branch with all these changes.

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

[Lldb-commits] [lldb] [lldb] Unify WaitForSetEvents and WaitForEventsToReset (PR #99997)

2024-07-22 Thread via lldb-commits


llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

Unify the implementations of WaitForSetEvents and WaitForEventsToReset. The 
former deals with the possibility of a race between the timeout and the 
predicate while the latter does not. The functions were also inconsistent in 
when they would recompute the mask. This patch unifies the two implementations 
and make them behave exactly the same modulo the predicate.

rdar://130562344

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


2 Files Affected:

- (modified) lldb/tools/debugserver/source/PThreadEvent.cpp (+29-53) 
- (modified) lldb/tools/debugserver/source/PThreadEvent.h (+7) 


``diff
diff --git a/lldb/tools/debugserver/source/PThreadEvent.cpp 
b/lldb/tools/debugserver/source/PThreadEvent.cpp
index e77c7511ae5ba..f9166a1b63d06 100644
--- a/lldb/tools/debugserver/source/PThreadEvent.cpp
+++ b/lldb/tools/debugserver/source/PThreadEvent.cpp
@@ -108,79 +108,55 @@ void PThreadEvent::ResetEvents(const uint32_t mask) {
 // Wait until 'timeout_abstime' for any events that are set in
 // 'mask'. If 'timeout_abstime' is NULL, then wait forever.
 uint32_t
-PThreadEvent::WaitForSetEvents(const uint32_t mask,
-   const struct timespec *timeout_abstime) const {
+PThreadEvent::WaitForEventsImpl(const uint32_t mask,
+const struct timespec *timeout_abstime,
+std::function predicate) const {
   // DNBLogThreadedIf(LOG_EVENTS, "%p PThreadEvent::%s (0x%8.8x, %p)", this,
   // __FUNCTION__, mask, timeout_abstime);
+
   int err = 0;
+
   // pthread_cond_timedwait() or pthread_cond_wait() will atomically
   // unlock the mutex and wait for the condition to be set. When either
   // function returns, they will re-lock the mutex. We use an auto lock/unlock
   // class (PThreadMutex::Locker) to allow us to return at any point in this
   // function and not have to worry about unlocking the mutex.
   PTHREAD_MUTEX_LOCKER(locker, m_mutex);
-  do {
-// Check our predicate (event bits) in case any are already set
-if (mask & m_bits) {
-  uint32_t bits_set = mask & m_bits;
-  // Our PThreadMutex::Locker will automatically unlock our mutex
-  return bits_set;
-}
+
+  // Check the predicate and the error code. The functions below do not return
+  // EINTR so that's not something we need to handle.
+  while (!predicate() && err == 0) {
 if (timeout_abstime) {
   // Wait for condition to get broadcast, or for a timeout. If we get
-  // a timeout we will drop out of the do loop and return false which
-  // is what we want.
+  // a timeout we will drop out of the loop on the next iteration and we
+  // will recompute the mask in case of a race between the condition and 
the
+  // timeout.
   err = ::pthread_cond_timedwait(m_set_condition.Condition(),
  m_mutex.Mutex(), timeout_abstime);
-  // Retest our predicate in case of a race condition right at the end
-  // of the timeout.
-  if (err == ETIMEDOUT) {
-uint32_t bits_set = mask & m_bits;
-return bits_set;
-  }
 } else {
-  // Wait for condition to get broadcast. The only error this function
-  // should return is if
+  // Wait for condition to get broadcast.
   err = ::pthread_cond_wait(m_set_condition.Condition(), m_mutex.Mutex());
 }
-  } while (err == 0);
-  return 0;
+  }
+
+  // Either the predicate passed, we hit the specified timeout (ETIMEDOUT) or 
we
+  // encountered an unrecoverable error (EINVAL, EPERM). Regardless of how we
+  // got here, recompute and return the mask indicating which bits (if any) are
+  // set.
+  return GetBitsMasked(mask);
+}
+
+uint32_t
+PThreadEvent::WaitForSetEvents(const uint32_t mask,
+   const struct timespec *timeout_abstime) const {
+  auto predicate = [&]() -> uint32_t { return GetBitsMasked(mask) != 0; };
+  return WaitForEventsImpl(mask, timeout_abstime, predicate);
 }
 
-// Wait until 'timeout_abstime' for any events in 'mask' to reset.
-// If 'timeout_abstime' is NULL, then wait forever.
 uint32_t PThreadEvent::WaitForEventsToReset(
 const uint32_t mask, const struct timespec *timeout_abstime) const {
-  // DNBLogThreadedIf(LOG_EVENTS, "%p PThreadEvent::%s (0x%8.8x, %p)", this,
-  // __FUNCTION__, mask, timeout_abstime);
-  int err = 0;
-  // pthread_cond_timedwait() or pthread_cond_wait() will atomically
-  // unlock the mutex and wait for the condition to be set. When either
-  // function returns, they will re-lock the mutex. We use an auto lock/unlock
-  // class (PThreadMutex::Locker) to allow us to return at any point in this
-  // function and not have to worry about unlocking the mutex.
-  PTHREAD_MUTEX_LOCKER(locker, m_mutex);
-  do {
-// Check our predicate (event bits) each time through this do loop
-if ((mask & m_bits) == 0)

[Lldb-commits] [lldb] [lldb] Unify WaitForSetEvents and WaitForEventsToReset (PR #99997)

2024-07-22 Thread via lldb-commits


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

LGTM

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

[Lldb-commits] [clang] [lldb] [llvm] [BOLT][DWARF][NFC] Split processUnitDIE into two lambdas (PR #99957)

2024-07-22 Thread Sayhaan Siddiqui via lldb-commits


https://github.com/sayhaan updated 
https://github.com/llvm/llvm-project/pull/99957

>From 11fff0b2d1868f1e8fce988b2b41a38de42dff61 Mon Sep 17 00:00:00 2001
From: Amir Ayupov 
Date: Tue, 1 Jun 2021 11:37:41 -0700
Subject: [PATCH 1/4] Rebase: [Facebook] Add clang driver options to test debug
 info and BOLT

Summary:
This is an essential piece of infrastructure for us to be
continuously testing debug info with BOLT. We can't only make changes
to a test repo because we need to change debuginfo tests to call BOLT,
hence, this diff needs to sit in our opensource repo. But when upstreaming
to LLVM, this should be kept BOLT-only outside of LLVM. When upstreaming,
we need to git diff and check all folders that are being modified by our
commits and discard this one (and leave as an internal diff).

To test BOLT in debuginfo tests, configure it with -DLLVM_TEST_BOLT=ON.
Then run check-lldb and check-debuginfo.

Manual rebase conflict history:
https://phabricator.intern.facebook.com/D29205224
https://phabricator.intern.facebook.com/D29564078
https://phabricator.intern.facebook.com/D33289118
https://phabricator.intern.facebook.com/D34957174
https://phabricator.intern.facebook.com/D35317341

Test Plan:
tested locally
Configured with:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;compiler-rt;bolt;debuginfo-tests"
-DLLVM_TEST_BOLT=ON
Ran test suite with:
ninja check-debuginfo
ninja check-lldb

Reviewers: maks, #llvm-bolt

Reviewed By: maks

Subscribers: ayermolo, phabricatorlinter

Differential Revision: https://phabricator.intern.facebook.com/D46256657

Tasks: T92898286
---
 clang/include/clang/Driver/Options.td  |  4 
 clang/lib/Driver/ToolChains/Gnu.cpp| 29 ++
 cross-project-tests/lit.cfg.py | 14 -
 cross-project-tests/lit.site.cfg.py.in |  4 
 lldb/test/API/lit.cfg.py   |  5 +
 lldb/test/API/lit.site.cfg.py.in   |  8 +++
 lldb/test/Shell/helper/toolchain.py|  5 +
 lldb/test/Shell/lit.site.cfg.py.in |  9 
 llvm/CMakeLists.txt|  4 
 9 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 9c6cebd77ff0a..8ccbc4b372ba3 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5553,6 +5553,10 @@ def pg : Flag<["-"], "pg">, HelpText<"Enable mcount 
instrumentation">,
   MarshallingInfoFlag>;
 def pipe : Flag<["-", "--"], "pipe">,
   HelpText<"Use pipes between commands, when possible">;
+// Facebook T92898286
+def post_link_optimize : Flag<["--"], "post-link-optimize">,
+  HelpText<"Apply post-link optimizations using BOLT">;
+// End Facebook T92898286
 def prebind__all__twolevel__modules : Flag<["-"], 
"prebind_all_twolevel_modules">;
 def prebind : Flag<["-"], "prebind">;
 def preload : Flag<["-"], "preload">;
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 52c2ee90b1b28..ff20deb9c4f86 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -672,12 +672,41 @@ void tools::gnutools::Linker::ConstructJob(Compilation 
&C, const JobAction &JA,
 }
   }
 
+  // Facebook T92898286
+  if (Args.hasArg(options::OPT_post_link_optimize))
+CmdArgs.push_back("-q");
+  // End Facebook T92898286
+
   Args.AddAllArgs(CmdArgs, options::OPT_T);
 
   const char *Exec = Args.MakeArgString(ToolChain.GetLinkerPath());
   C.addCommand(std::make_unique(JA, *this,
  ResponseFileSupport::AtFileCurCP(),
  Exec, CmdArgs, Inputs, Output));
+  // Facebook T92898286
+  if (!Args.hasArg(options::OPT_post_link_optimize) || !Output.isFilename())
+return;
+
+  const char *MvExec = Args.MakeArgString(ToolChain.GetProgramPath("mv"));
+  ArgStringList MoveCmdArgs;
+  MoveCmdArgs.push_back(Output.getFilename());
+  const char *PreBoltBin =
+  Args.MakeArgString(Twine(Output.getFilename()) + ".pre-bolt");
+  MoveCmdArgs.push_back(PreBoltBin);
+  C.addCommand(std::make_unique(JA, *this, 
ResponseFileSupport::None(),
+ MvExec, MoveCmdArgs, std::nullopt));
+
+  ArgStringList BoltCmdArgs;
+  const char *BoltExec =
+  Args.MakeArgString(ToolChain.GetProgramPath("llvm-bolt"));
+  BoltCmdArgs.push_back(PreBoltBin);
+  BoltCmdArgs.push_back("-reorder-blocks=reverse");
+  BoltCmdArgs.push_back("-update-debug-sections");
+  BoltCmdArgs.push_back("-o");
+  BoltCmdArgs.push_back(Output.getFilename());
+  C.addCommand(std::make_unique(JA, *this, 
ResponseFileSupport::None(),
+ BoltExec, BoltCmdArgs, std::nullopt));
+  // End Facebook T92898286
 }
 
 void tools::gnutools::Assembler::ConstructJob(Compilation &C,
diff --git a/cross-project-tests/lit.cfg.py b/cross-project-tests/lit.cfg.py
index 774c4eaf4d976..619634578dfe6 100644
--- a/cross-project-tests/lit.cfg.py
+++ b/c

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits



@@ -299,6 +301,35 @@ SBPlatform::SBPlatform(const char *platform_name) {
   m_opaque_sp = Platform::Create(platform_name);
 }
 
+SBPlatform::SBPlatform(const char *platform_name, const SBDebugger &debugger,
+   const char *script_name, const SBStructuredData &dict)
+: SBPlatform(platform_name) {
+  LLDB_INSTRUMENT_VA(this, platform_name, debugger, script_name, dict);
+
+  if (!m_opaque_sp)
+return;
+
+  if (!script_name || !dict.IsValid() || !dict.m_impl_up)

medismailben wrote:

Actually, `SBStructuredData::IsValid` just calls `IsValid` on the `unique_ptr` 
without checking it before, which could lead to a crash. I'll fix that in a 
separate patch.

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

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {
+  if (!m_metadata)
+return false;
+
+  Status error;
+  return SetupScriptedObject(error);
+}
+
+void ScriptedPlatform::Initialize() {
+  if (g_initialize_count++ == 0) {

medismailben wrote:

I might be wrong but IIUC, we make a new platform plugin for every new instance 
of a platform. Like you could have 2 different `platform remote-ios` talking 
with 2 different devices. That's why most platform plugins have this 
`g_initialize_count` checks in `Initialize & Uninitialize, to be able to make 
new instances of the plugins every time we connect to a new platform, but 
without having to register it over and over.

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

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits



@@ -0,0 +1,288 @@
+//===-- ScriptedPlatform.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 "ScriptedPlatform.h"
+
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Interpreter/ScriptInterpreter.h"
+#include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/LLDBLog.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ScriptedPlatform)
+
+static uint32_t g_initialize_count = 0;
+
+static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
+ScriptLanguage::eScriptLanguagePython,
+};
+
+bool ScriptedPlatform::IsScriptLanguageSupported(
+lldb::ScriptLanguage language) {
+  llvm::ArrayRef supported_languages(
+  g_supported_script_languages);
+
+  return llvm::is_contained(supported_languages, language);
+}
+
+ScriptedPlatformInterface &ScriptedPlatform::GetInterface() const {
+  return *m_interface_up;
+}
+
+lldb::PlatformSP ScriptedPlatform::CreateInstance(bool force,
+  const ArchSpec *arch) {
+  Log *log = GetLog(LLDBLog::Platform);
+  if (log) {
+const char *arch_name;
+if (arch && arch->GetArchitectureName())
+  arch_name = arch->GetArchitectureName();
+else
+  arch_name = "";
+
+const char *triple_cstr =
+arch ? arch->GetTriple().getTriple().c_str() : "";
+
+LLDB_LOGF(log, "ScriptedPlatform::%s(force=%s, arch={%s,%s})",
+  __PRETTY_FUNCTION__, force ? "true" : "false", arch_name,
+  triple_cstr);
+  }
+
+  return std::make_shared();
+}
+
+ScriptedPlatform::ScriptedPlatform() : Platform(false) {}
+
+bool ScriptedPlatform::SetupScriptedObject(Status &error) {
+
+  auto error_with_message = [&error](llvm::StringRef message) {
+return ScriptedInterface::ErrorWithMessage(
+LLVM_PRETTY_FUNCTION, message, error, LLDBLog::Platform);
+  };
+
+  Debugger &debugger = m_metadata->GetDebugger();
+
+  if (!IsScriptLanguageSupported(debugger.GetScriptLanguage()))
+return error_with_message("Debugger language not supported");
+
+  ScriptInterpreter *interpreter = debugger.GetScriptInterpreter();
+  if (!interpreter)
+return error_with_message("Debugger has no Script Interpreter");
+
+  // Create platform instance interface
+  m_interface_up = interpreter->CreateScriptedPlatformInterface();
+  if (!m_interface_up)
+return error_with_message(
+"Script interpreter couldn't create Scripted Process Interface");
+
+  const ScriptedMetadata scripted_metadata = m_metadata->GetScriptedMetadata();
+
+  ExecutionContext e;
+  auto obj_or_err = GetInterface().CreatePluginObject(
+  scripted_metadata.GetClassName(), e, scripted_metadata.GetArgsSP());
+
+  if (!obj_or_err) {
+llvm::consumeError(obj_or_err.takeError());
+return error_with_message("Failed to create script object.");
+  }
+
+  StructuredData::GenericSP object_sp = *obj_or_err;
+  if (!object_sp || !object_sp->IsValid())
+return error_with_message("Failed to create valid script object");
+
+  m_hostname = GetHostPlatform()->GetHostname();
+  return true;
+}
+
+ScriptedPlatform::~ScriptedPlatform() {}
+
+bool ScriptedPlatform::ReloadMetadata() {
+  if (!m_metadata)
+return false;
+
+  Status error;
+  return SetupScriptedObject(error);
+}
+
+void ScriptedPlatform::Initialize() {
+  if (g_initialize_count++ == 0) {
+// NOTE: This should probably be using the driving process platform
+PluginManager::RegisterPlugin(ScriptedPlatform::GetPluginNameStatic(),
+  ScriptedPlatform::GetDescriptionStatic(),
+  ScriptedPlatform::CreateInstance);
+  }
+}
+
+void ScriptedPlatform::Terminate() {
+  if (g_initialize_count > 0) {
+if (--g_initialize_count == 0) {
+  PluginManager::UnregisterPlugin(ScriptedPlatform::CreateInstance);
+}
+  }
+}
+
+std::vector
+ScriptedPlatform::GetSupportedArchitectures(const ArchSpec &process_host_arch) 
{
+  std::vector result;
+  result.push_back(process_host_arch);
+  return result;
+}
+
+lldb::ProcessSP
+ScriptedPlatform::Attach(lldb_private::ProcessAttachInfo &attach_info,
+ lldb_private::Debugger &debugger,
+ lldb_private::Target *target, // Can be nullptr, if
+   // nullptr create a new
+   // target, else use
+   // existing one
+ lldb_private::Status &error) {
+  lldb::ProcessAttachInfoSP attach

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

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

2024-07-22 Thread Med Ismail Bennani via lldb-commits


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

>From 9b7d9a26eabce5f76a99876c14aab619aab934ac Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 22 Jul 2024 21:11:48 -0700
Subject: [PATCH] [lldb/Plugins] Introduce Scripted Platform Plugin

This patch introduces Scripted Platform, a new platform plugin that can
be customized with a python script.

For now this can list processes described in the python script file but
eventually, it will be used to spawn scripted processes and act as an
interface between them.

This patch is also a less intrusive implementation of 2d53527.

It introduces a new PlatformMetadata held by every platform that
contains various objects that might be used by a platform instance.

In its current form, the PlatformMetadata holds a reference to the
Debugger and a ScriptedMetadata pointer. These are necessary in other to
instanciate the scripted object that the ScriptedPlatform interacts with.

In order to make it less introsive with the rest of lldb's platform
creation code, platform metadata are set after the platform creation,
and requires to platform to reload them (using `Platform::ReloadMetadata`).

This approach has the tradeoff that the ScriptedPlaform instance is
technically invalid and useless right after its creation. However, the user
should never be in that situation, since we reload the platform metadata
everytime with create or select the platform.

This work was previously reviewed in:
- https://reviews.llvm.org/D139252
- https://reviews.llvm.org/D142266

Signed-off-by: Med Ismail Bennani 
---
 .../bindings/interface/SBPlatformDocstrings.i |  12 +
 lldb/bindings/python/python-swigsafecast.swig |  10 +
 lldb/bindings/python/python-wrapper.swig  |  36 +++
 .../python/templates/scripted_platform.py |   9 +-
 lldb/include/lldb/API/SBDebugger.h|   2 +
 lldb/include/lldb/API/SBPlatform.h|   4 +-
 lldb/include/lldb/API/SBProcess.h |   2 +
 lldb/include/lldb/API/SBStructuredData.h  |   1 +
 lldb/include/lldb/API/SBTarget.h  |   2 +
 .../Interfaces/ScriptedPlatformInterface.h|   7 +-
 .../lldb/Interpreter/OptionGroupPlatform.h|  10 +-
 .../lldb/Interpreter/ScriptInterpreter.h  |  19 +-
 lldb/include/lldb/Target/Platform.h   |  22 ++
 lldb/include/lldb/Utility/ScriptedMetadata.h  |   4 +-
 lldb/source/API/SBPlatform.cpp|  42 +++
 lldb/source/API/SBStructuredData.cpp  |   8 +-
 .../source/Commands/CommandObjectPlatform.cpp |  17 +-
 lldb/source/Interpreter/ScriptInterpreter.cpp |  15 +
 lldb/source/Plugins/Platform/CMakeLists.txt   |   1 +
 .../Plugins/Platform/scripted/CMakeLists.txt  |   8 +
 .../Platform/scripted/ScriptedPlatform.cpp| 279 ++
 .../Platform/scripted/ScriptedPlatform.h  |  84 ++
 .../Process/scripted/ScriptedProcess.h|   2 +-
 .../Process/scripted/ScriptedThread.cpp   |   5 -
 .../Plugins/Process/scripted/ScriptedThread.h |   6 +-
 .../ScriptedPlatformPythonInterface.cpp   |  42 +--
 .../ScriptedPlatformPythonInterface.h |   5 +-
 .../Interfaces/ScriptedPythonInterface.cpp|  45 +++
 .../Interfaces/ScriptedPythonInterface.h  |  25 +-
 .../Python/SWIGPythonBridge.h |   3 +
 .../Python/ScriptInterpreterPython.cpp|   5 +
 .../Python/ScriptInterpreterPythonImpl.h  |   2 +
 lldb/source/Target/Platform.cpp   |  10 +-
 .../scripted_platform/TestScriptedPlatform.py | 108 +++
 .../scripted_platform/my_scripted_platform.py |  27 +-
 .../Python/PythonTestSuite.cpp|  15 +
 36 files changed, 839 insertions(+), 55 deletions(-)
 create mode 100644 lldb/source/Plugins/Platform/scripted/CMakeLists.txt
 create mode 100644 lldb/source/Plugins/Platform/scripted/ScriptedPlatform.cpp
 create mode 100644 lldb/source/Plugins/Platform/scripted/ScriptedPlatform.h
 create mode 100644 
lldb/test/API/functionalities/scripted_platform/TestScriptedPlatform.py

diff --git a/lldb/bindings/interface/SBPlatformDocstrings.i 
b/lldb/bindings/interface/SBPlatformDocstrings.i
index ef09d5bce13fd..b8cdf21e90f82 100644
--- a/lldb/bindings/interface/SBPlatformDocstrings.i
+++ b/lldb/bindings/interface/SBPlatformDocstrings.i
@@ -29,3 +29,15 @@ and executable type. If the architecture or executable type 
do not match,
 a suitable platform will be found automatically."
 
 ) lldb::SBPlatform;
+
+%feature("docstring", "
+Create a platform instance using a specific platform plugin name, debugger,
+script name and user-provided dictionary.
+
+:param platform_name: name of the platform plugin to use to create the platform
+:param debugger: debugger instance owning the platform
+:param script_name: name of the script class and module to use to create the 
platform
+:param dict: user-provided dictionary that can be used when instanciating a 
platform
+") lldb::SBPlatform (const char *, const lldb::SBDebugger&,
+const char

77 matches

Mail list logo