On Sat, 26 Aug 2023 at 00:13, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Wed, Aug 9, 2023 at 4:44 AM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:
> >
> > Add support to libbpf to append exception callbacks when loading a
> > program. The exception callback is found by discovering the declaration
> > tag 'exception_callback:<value>' and finding the callback in the value
> > of the tag.
> >
> > The process is done in two steps. First, for each main program, the
> > bpf_object__sanitize_and_load_btf function finds and marks its
> > corresponding exception callback as defined by the declaration tag on
> > it. Second, bpf_object__reloc_code is modified to append the indicated
> > exception callback at the end of the instruction iteration (since
> > exception callback will never be appended in that loop, as it is not
> > directly referenced).
> >
> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> > ---
>
> Just two point before you send next version:
>
> a) it seems like this appending of exception callback logically fits
> bpf_object__relocate() step, where other subprogs are appended. Any
> reason we can't do it there?
>
We should be able to do it there as well. But I felt it is better to
do it in bpf_object__reloc_code as the logic is similar to the
handling of bpf_pseudo_func/bpf_pseudo_call insns. And then we need to
recurse using bpf_object__reloc_code for exception cb again.
> b) all the callbacks are static functions, right? Which means in the
> case of static linking, we can have multiple subprogs with the same
> name. So this whole look up by name thing doesn't guarantee unique
> match. At the very least libbpf should check that the match is unique
> and error out otherwise.
Ack, will fix this in v3.
>
> Ideally though, would be great if something like this would be
> supported instead (but I know it's way more complex, Alexei already
> mentioned that in person and on the list):
>
> try (my_callback) {
> ... code that throws ...
> }
>
> try (my_other_callback) {
> ... some other code that throws ...
> }
>
>
> This try() macro can be implemented in a form similar to bpf_for() by
> using fancy for() loop. It would look and feel way more like
> try/catch.
>
These try blocks are easier than having a try/catch block which the
execution jumps to when the exception is thrown. I think the latter
will involve some form of compiler support, because otherwise there is
no control flow that is seen by the compiler into the catch block,
which will mess up things, and I plan to atleast explore that approach
(already looking at LLVM) once I am done with the second part of this
feature.
Having just these try (callback) {} blocks is easier as we can record
which subprog corresponds to [begin_ip, end_ip] (per frame) and stop
unwinding when we find a suitable handler for the ip of a parent
frame. The callback will be invoked and will return to the parent
frame (or kernel if it's the main frame). So if this seems like a more
useful thing, I can make this work and send it out as a follow up to
this set.
> [...]
