llvm dev - Jan 2018 - Exception handling support for a target

Hi All,

  I would like to know in order to support exception handling for
particular target, what need to be done. After doing some investigation, I
can think of the following items with questions:

  - 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.

  - 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?

  - 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?

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

  Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/09b69a35/attachment.html>

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.

On 16 Jan 2018, at 10:18, Tim Northover via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>>  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.
The libUnwind parts are relatively small.  You need to write two assembly
functions, one which dumps all registers to memory and one which restores them. 
Next you need to add enum values for all of your registers that correspond to
their DWARF register numbres.  You then need to implement a C++ class that sets
and gets register values from the in-memory structure based on the DWARF number.
This is usually quite small because the easiest way of dumping the registers is
to store each register set contiguously in memory in the same order that as
their DWARF numbers, so you end up with a struct something like this:

struct MyArch_Regs
{
	int64_t GPRs[32];
};

And the get function is just doing GPRs[RegNo - MyArch_GPR0].

LLVM’s libUnwind has a very clean structure.  Adding MIPS support took a couple
of hours.  All of the unwinder support is generic other than the mapping from
DWARF register numbers to some concrete mechanism for getting and setting them.

David

2018-01-16 18:18 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:
> 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

​Do we have to emit directives in the epilogue, too?​ One of my test case
fail due to the directives in the epilogue have been executed. After remov
​ing
 them from epilogue, the exception is caught as expected. Also, the
directives are also for debug purpose (.debug_frame), right? I guess I only
have to make sure directives work for exception handling, then debug works
as well?

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180116/fedda1a7/attachment.html>

On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote:
> - 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?
This corresponds to a GCC intrinsic used in their unwind routines. It's 
not really known for its exemplary documentation, so you may need to 
read GCC's sources to see what they are doing with it.
Unless you plan to compile GCC's unwind library, you don't really need 
to worry about it.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

2018-01-19 23:00 GMT+08:00 Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org>:
> On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote:
>
>> - 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?
>>
>
> This corresponds to a GCC intrinsic used in their unwind routines. It's
> not really known for its exemplary documentation, so you may need to read
> GCC's sources to see what they are doing with it.
> Unless you plan to compile GCC's unwind library, you don't really
need to
> worry about it.

I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to
it, but others don't. May I know why it's so on Hexagon?
​​


-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180120/a8f91326/attachment.html>