target: add SBPF call stack extension

[djolertrk]

Add qSBPFCallStack as a typed target extension for runtimes whose call frames are kept outside guest memory.

Return PC and frame-pointer pairs in a fixed little-endian binary format that LLDB can consume without parsing monitor output.

Basically this follows how wasm handles call stack https://lldb.llvm.org/resources/lldbgdbremote.html#wasm-packets.

[djolertrk]

cc @daniel5151

[daniel5151]

Is this something that has landed upstream in LLDB?
A quick google search isn't turning anything up here.

[djolertrk]

Solana community uses fork of LLVM and I opened PR for their version of LLVM/LLDB at: anza-xyz/llvm-project#221

Also, the hook is being used in their SBPF vm at: anza-xyz/sbpf#239

[daniel5151]

Yeah, I suspected that might be the case...

Unfortunately, my gut feeling is that I would not like to accept this PR. Given that Solana already has a fork of LLDB, it seems reasonable reasonable that Solana also maintain a fork of gdbstub that supports fork-specific extensions.

FWIW, the actual code in this PR looks totally fine - it's just that it's semantically out-of-scope for gdbstub.

---

For context: this is the first time in gdbstub's development that someone has expressed interest in landing this sort of "non-standard" GDB RSP extensions, so this PR will set a sort of "precedent" in the project.

As a maintainer, nudging people towards maintaining long-lived forks isn't something I take lightly, and there might be a point in the future where I re-evaluate this policy... but for the time being, I would prefer keeping mainline gdbstub closely aligned with upstream GDB and LLDB.

[djolertrk]

Yeah, I suspected that might be the case...

Unfortunately, my gut feeling is that I would not like to accept this PR. Given that Solana already has a fork of LLDB, it seems reasonable reasonable that Solana also maintain a fork of gdbstub that supports fork-specific extensions.

FWIW, the actual code in this PR looks totally fine - it's just that it's semantically out-of-scope for gdbstub.

For context: this is the first time in gdbstub's development that someone has expressed interest in landing this sort of "non-standard" GDB RSP extensions, so this PR will set a sort of "precedent" in the project.

As a maintainer, nudging people towards maintaining long-lived forks isn't something I take lightly, and there might be a point in the future where I re-evaluate this policy... but for the time being, I would prefer keeping mainline gdbstub closely aligned with upstream GDB and LLDB.

I totally understand, thank you!