[llvm-dev] Exception handling support for a target

[Tim Northover via llvm-dev]

On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>   - CFI directives:
>
>     This is for .eh_frame section. Basically all the targets insert CFI
> directives in FrameLowering, but I am not sure exactly when/where I should
> do so.

The directives are there to describe where the unwinder should look to
find out what each register's value was when this function was called
(well, each register that the caller expected to be preserved). So the
directives have to have been emitted by the time any instruction is
executed that could cause an exception to be thrown (typically either
a call to another function or a compiler-generated call to __cxa_throw
or similar when the source code itself contains "throw X").

So normally the directives are emitted in the prologue when the
registers actually get saved. Sometimes all in a bunch, sometimes
interspersed with the saves, but it usually doesn't matter which. As
you've discovered that happens in XYZFrameLowering

>   - getExceptionPointerRegister and getExceptionSelectorRegister:
>
>     TargetLowering subclass should implement both functions. The former
> specifies the register used to pass the exception object to the landing pad
> (or catch clause), and the latter specifies the register used to pass the
> typeid object to the landing pad. Where can I know what registers should be
> used? Or it's just the same as those specified in calling convention?

This is an ABI decision that your unwinder needs to know about, but
the ones used in a normal function call are fairly typical. I believe
the information is transmitted to the __gxx_personality_v0 function
via Clang's __builtin_eh_return_data_regno intrinsic, which should be
consistent.

>   - EH_RETURN:
>
>     I see some targets define their own EH_RETURN SDNode, others don't. What
> is EH_RETURN, and under what circumstances I should define my own EH_RETURN
> SDNode?

Not sure about this, I'm afraid. My suggestion would be to try without
if you've got a reasonably normal target.

>   Is the above list complete? Do I understand their purpose correctly (sort
> of)?

There are components in libunwind (especially) and compiler-rt you'll
also need to look at if you're not on top of an existing runtime.

Cheers.

Tim.