I split the syncronous exception out into a new handler in my compat32 patch as it allows further sanity checks, e.g. that the kernel thinks the current process should be in 32-bit mode.

In D13146#273882, @andrew wrote:

I split the syncronous exception out into a new handler in my compat32 patch as it allows further sanity checks, e.g. that the kernel thinks the current process should be in 32-bit mode.

At the cost of duplicating code, right? If we keep the 32-bit compatibility mode as simple as possible, there wouldn't be any strong need for further sanity checks.

Andrew,

Considering that there is no need to split up this into two code paths for 32-bit/64-bit at least for what I'm trying to achieve, would you mind if I went ahead, committing this change as is? Once this change and D13148 land, I can work towards getting the sysent for cloudabi32 committed.

I looked at some of the other operating systems (e.g., Linux) and they seem to take the same approach as what I'm proposing here, making me assume it's not all that bad. If you want, I can add a comment somewhere to state that splitting up into two separate handlers could be considered.

Ed