Hi,

I've tried to run your plugin on ghidra 9.1.2 and I only see helper names and no other helper syscall attributes. (ret type etc.)
I see these warnings in eclipse logs when linking and running with ghidra and analysing an eBPF program.
WARN Decompiling syscall:0033, pcode error at syscall:0033: Unable to resolve constructor at syscall:0033 (DecompileCallback)
WARN Decompiling syscall:0001, pcode error at syscall:0001: Unable to resolve constructor at syscall:0001 (DecompileCallback)

Greetings!

In the near future I plan to implement interaction with eBPF maps through some helpers (https://prototype-kernel.readthedocs.io/en/latest/bpf/ebpf_maps.html#interacting-with-maps).
«eBPF maps are a generic data structure for storage of different data types. It’s a method to keep state between invocations of the eBPF program, and allows sharing data between eBPF kernel programs, and also between kernel and user-space applications. So, map handles are file descriptors, and multiple maps can be created and accessed by multiple programs».

We know (based on the relocation table) that the eBPF loader patches LDDW instruction, which forms Rn for the helper-call (for example, bpf_map_lookup_elem(…)).Therefore, relying on relocation table, it’s theoretically possible to implement string information of map’s name in disassembler and decompiler.

Greetings!
eBPF has a number of nasty moments with the stack:
https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-can-bpf-programs-access-instruction-pointer-or-return-address
And small citation:
«Q: Can BPF programs access instruction pointer or return address?
A: NO.
Q: Can BPF programs access stack pointer ?
A: NO. Only frame pointer (register R10) is accessible. From compiler point of view it's necessary to have stack pointer. For example, LLVM defines register R11 as stack pointer in its BPF backend, but it makes sure that generated code never uses it.»
Pretty sad, isn't it?

Register R10 is the last hope for us and Ghidra to implement access to stack of eBPF programm. I put «stackpointer» attribute on it in specification files for extension. R10 is a frameponter register, it’s unchangeable, and we use this register and offset to access the stack (such as index in array). Accordingly, the "original" SP (stack pointer register) is missing and no substitute in eBPF. This implies several problems:

=> Stack Depth field in Ghidra will be guaranteed zero, beacuse we have to appoint R10 as a stackponter in these architectural conditions.

=> Instructions which operate with R10 (Load/Store instructions) often doesn't decompile. Any ideas about this thing? Ghidra usually doesn't decompile dead code (snippets that won't execute), but it generally does not apply to the subject of Issue.

Thanks to support!

Extension version for [eBPF-for-Ghidra] is incompatible with Ghidra.

Build Date: 2022-Jan-25 1526 EST
Ghidra Version: 10.1.2
Java Home: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
JVM Version: Eclipse Adoptium 11.0.14.1
OS: Mac OS X 12.0.1 x86_64