Fix last except handler running if no others match on Kasli-SoC

[SquidDev]

ARTIQ Pull Request

Description of Changes

This changes the compiler to generate a call to @__artiq_resume in the try/except fallthrough block, rather than LLVM's resume instruction.

This fixes a block on Kasli-SoC, where the last except block is run, if none of the preceding blocks match - see #2108 for further details.

Related Issue

Closes #2108.

Type of Changes

	Type
✓	🐛 Bug fix

Steps (Choose relevant, delete irrelevant before submitting)

All Pull Requests

• Use correct spelling and grammar.
• Close/update issues.
• Check the copyright situation of your changes and sign off your patches (git commit --signoff, see copyright).

Code Changes

• Run flake8 to check code style (follow PEP-8 style). flake8 has issues with parsing Migen/gateware code, ignore as necessary.
• Test your changes or have someone test them. Mention what was tested and how:
  • With this patch, the experiment in Kasli-SoC runs last except handler if no others match #2108 behaves as expected on both Kasli 1.1 and Kasli-SoC.
  • We've been running this for a little over a month now (with both Kasli-SoC and Kasli 1.1 masters), and not encountered any issues.

Licensing

See copyright & licensing for more info.
ARTIQ files that do not contain a license header are copyrighted by M-Labs Limited and are licensed under LGPLv3+.

[sbourdeauducq]

rather than LLVM's resume instruction

Shouldn't that instruction call __artiq_resume anyway?

[dnadlinger]

This doesn't seem like the correct fix. The unwinder should not even jump to the landing pad if there are no matching exception types, as there is no cleanup, so surely this just papers over the issue?

[dnadlinger]

_Unwind_Resume should indeed handle the ForcedUnwind use case correctly; the issue here seems to be that the LLVM backend – correctly – assumes that the landing pad should only be executed if at least one of the clauses matches.

[SquidDev]

This doesn't seem like the correct fix. The unwinder should not even jump to the landing pad if there are no matching exception types, as there is no cleanup, so surely this just papers over the issue?

Yeah, looking at the compiled assembly this is the case. Normally LLVM optimises out the type guard that ARTIQ generates. Using @__artiq_resume causes this optimisation to not apply, and so the guard is still run (despite, as you say, not being needed).

This suggests that there is a bug somewhere else in the Kasli-Soc unwinding code. I will try to do some debugging there and see what's going on.