On 15/10/2019 19:33, Edward Cree wrote: > But I think we'll > need to prototype things with static linking first so that we can be > sure of the linker semantics we want, before we try to put a new dynamic > linker in the kernel. For anyone wanting to follow my progress on this, the first-draft eBPF linker 'ebld.py' can now be found at https://github.com/solarflarecom/ebpf_asm/tree/linker It's able to resolve inter-object calls (at least in a _really simple_ test I did, where prog A was "call pass_fn; exit" and prog B was "pass_fn: ld r0, XDP_PASS; exit"), but I haven't got as far as feeding the resulting object file to the kernel (no obvious reason that shouldn't work, I just haven't tried it yet). What it _doesn't_ do yet is deal with BTF — it just silently discards any BTF or BTF.ext sections in the input object files. I'll need to re-read the BTF spec to see what's changed there since last I was involved (I hope the spec has been kept up to date as BTF has evolved...!) But with the basic linker there, I think a prototype daemon is probably a higher priority than getting fully-featured with BTF, so that's what I plan to do next. -Ed PS: Yes, it's in Python. I started out in C, and quickly backed myself into a corner trying to keep the data structures simple. Having first- class dictionaries Really Helps.
