On Sat, Aug 26, 2023 at 3:42 PM Kumar Kartikeya Dwivedi
<memxor@xxxxxxxxx> wrote:
>
> >
> > 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.
I suspect even "just try {}" will not work without compiler support.
{} is a semantic structure from compiler pov. It doesn't have
any delineation in LLVM IR. They don't exist to optimization passes.
