[Bug bpf/24758] New: stapbpf-next: more robust and generous userspace interpreter

[Bug bpf/24758] New: stapbpf-next: more robust and generous userspace interpreter

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=24758

            Bug ID: 24758
           Summary: stapbpf-next: more robust and generous userspace
                    interpreter
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: bpf
          Assignee: systemtap at sourceware dot org
          Reporter: me at serhei dot io
  Target Milestone: ---

The BPF interpreter (in stapbpf/bpfinterp.cxx) is still a cobbled-together
thing with some holes and probable bugs lurking. It needs a pass over the code
to be brought up to standard bytecode-interpreter 'best practice'. No need for
fancy performance tricks, but:
- It could be more robust (runtime errors handled properly, memory management
with fewer pitfalls).
- It could be more generous (some of the kernel bpf restrictions are still
duplicated in userspace where there's no need for them -- pr24528 allows us to
generate different code for userspace probes).
- It could maybe use fewer hacky C++ interfaces.
- It could maybe do with refactoring to include some code from the lkm runtime
where functionality is being duplicated. (We already use lkm code in-userspace
for the dyninst backend, so reusing it here is not totally shocking.)

The only thing that's needed for certain is 'more robust' so I am filing just
one PR for now to track this work.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug bpf/24758] stapbpf-next: more robust and generous userspace interpreter

[me at serhei dot io]

https://sourceware.org/bugzilla/show_bug.cgi?id=24758

--- Comment #1 from Serhei Makarov <me at serhei dot io> ---
Took an initial step in this direction by bumping stack size (commit
9a2cd427a6a4) to 64k (iirc first suggested for xbpf by Jose Marchesi; if GCC
can compile to this, so can we).

fche suggesting using realloc() to resize the stack dynamically if this
solution turns out to be insufficient.

-- 
You are receiving this mail because:
You are the assignee for the bug.