llvm dev - Nov 2018 - Using BPF outside the Linux kernel

Hello llvm-dev,

I'm working on a project that is looking at using BPF as the underlying
instruction set for running programs in a protected environment.  We have a
working prototype but have run into a few issues and missing
functionality.  It appears these might be due to BPF development being
focused on usage in the Linux kernel.  Our requirements are broader
(rodata, shared objects with dynamic linking) and we hope to compile
multiple languages down to BPF (C/C++, Rust, ...).  Here is an example of
the issues or missing functionality we've run into so far:

- 512 byte stack size limitation
- No support for returning structures from functions
- No support in lld for BPF shared objects (though we have made local
changes that adds this support that we'd be happy to upstream)
- llc reporting unsupported relocations when C using rodata in a typical way

Are there any efforts underway to broaden the scope of BPF beyond the Linux
kernel requirements and what kind of other issues or known lack of support
may we encounter?

Thanks,
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181114/9600a7b6/attachment.html>

On 11/14/18 8:11 AM, Jack May via llvm-dev wrote:
> I'm working on a project that is looking at using BPF as the underlying
> instruction set for running programs in a protected environment.  We
> have a working prototype but have run into a few issues and missing
> functionality.  It appears these might be due to BPF development being
> focused on usage in the Linux kernel.  Our requirements are broader
> (rodata, shared objects with dynamic linking) and we hope to compile
> multiple languages down to BPF (C/C++, Rust, ...).
Have you considered WASM for this project?  It seems already closer to
what you want, versus trying to force BPF in that direction.

Hi Josh, thanks for the response.

Yes WASM is an alternative path we are considering.  We have similar
concerns as we do with BPF where most of the WASM focus is targeted toward
browsers and more full-featured and complex VM environments Stepping off
that path may lead to similar deficiencies or require pulling in more
complex dependencies.  Are there non-browser embedded leaning efforts going
on in the llvm community?

Thanks,
Jack

On Wed, Nov 14, 2018 at 11:42 AM Josh Stone <jistone at redhat.com> wrote:
> On 11/14/18 8:11 AM, Jack May via llvm-dev wrote:
> > I'm working on a project that is looking at using BPF as the
underlying
> > instruction set for running programs in a protected environment.  We
> > have a working prototype but have run into a few issues and missing
> > functionality.  It appears these might be due to BPF development being
> > focused on usage in the Linux kernel.  Our requirements are broader
> > (rodata, shared objects with dynamic linking) and we hope to compile
> > multiple languages down to BPF (C/C++, Rust, ...).
>
> Have you considered WASM for this project?  It seems already closer to
> what you want, versus trying to force BPF in that direction.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181114/b298e213/attachment.html>