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

[Jason Molenda 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
----------------
jasonmolenda wrote:

I don't think this is quite true.  lldb asks the remote stub to allocate memory with read+write permissions for storing the arguments, and read+execute permissions for the jitted code, e.g. 
```
(lldb) p (int)isdigit('1')
 <  13> send packet: $_M1000,rx#83
 <  13> read packet: $100008000#00
 <  13> send packet: $_M1000,rw#82
 <  13> read packet: $10000c000#00
```

It would be surprising (to me) if the stub returned memory regions on the stack, because lldb is allowed to reuse these regions throughout the debug session, and we can't have the inferior process overwriting them.

You are correct that the allocated regions may be too far from the function(s) they'll need to call, and the same problem you describe below could exist.  I don't mean to focus on the "stack memory" part of this, but I think it will confuse people when they read it.

https://github.com/llvm/llvm-project/pull/99336