Asynchronous Exception Support

[please-fix-swapgs]

You might be scared or upset after reading the title but the feature I want to start some discussion on is actually rather tame.

If you've done some amount of work in the low level systems space you probably know that programs have to be able
to handle CPU generated hardware exceptions throughout their lifetime. That means that the program is going to be
interrupted by a synchronous exception event which switches control flow to a CPU exception handler routine. For many
types of CPU exceptions however this is not sufficient and you actually want to transfer control back into the interrupted
routine to execute some sort of program-specific exception handler.

For a C example please see the Linux documentation. In short however the process consists of manually delimiting faulting code sections in the program and their associated "landing pads" that will be invoked upon faults. As a quick example:
https://github.com/torvalds/linux/blob/57fbdb15ec427ca3a6f35d4b71fc90ca9af301ea/arch/x86/kvm/vmx/vmx.c#L2312-L2330

I feel like Zig could do a lot better than this. Some people might be concerned about runtime overhead but note that what I propose would not introduce any control flow or generated code at all.
The Microsoft C compiler for example implements such a mechanism on top of C through Structured Exception Handling. I don't wish to propose an exact equivalent, it's just a precedent of how this sort of issue can be tackled in a simplistic fashion.

Excuse the lame strawman syntax.

@try {
    ... faulting code ...
} @fault {
    ... handler code ...
}

All this implementation necessitates is doing just what Linux implements by hand: Generating an output section in the resulting object file that consists of a table of (relative) addresses. This obviously doesn't cover the other features supported by the likes of SEH but as Linux demonstrates things like unwinding aren't required and orthogonal to the compiler generated data table.

On top of this foundation Zig programs can then tell the CPU about their hardware exception handler(s) that can then search through the compiler generated table in the image's section to look for an appropriate place to resume execution after the fault.

[lithdew]

What about using async frames - keep a suspended user-level exception handler frame, and resume it upon a hardware exception?

I'm not too familiar with this domain, but I am curious if this is doable with a solution that is not too hacky with Zig today.

[please-fix-swapgs]

I think a frame oriented solution is very interesting but I doubt it would be feasible as the means of actually resuming the faulting code is inherently platform and context specific. On x86 for example you'd have an "iret-frame" with the appropriate location to resume at, then execute an iret to return from the hardware exception handler. I doubt resume could handle this. Having an actual "coroutine frame" that stores the state of local variables etc. also isn't really fit for this purpose as the exception handler functions at a different scope and will usually preserve the state of all registers already.

[mrakh]

I like the basis of the idea, but how would this co-exist with existing interrupt handlers? It certainly would not be wise to allow the compiler to clobber them if I use @try+@fault in conjunction.