Re: Fwd: Re: Registers used for exception handling on Linux/m68k?

[Nathan Sidwell <nathan@acm.org>]

On 10/1/20 5:49 AM, John Paul Adrian Glaubitz wrote:
> Hi Nathan!
> 
> On 9/29/20 7:58 PM, Nathan Sidwell wrote:
>> On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote:
>>>
>>> I'm looking for an information regarding exception handling on Linux/m68k, in particular
>>> I need to know what registers are used by the ABI in order to implement the functions
>>> "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 backend
>>> in LLVM [1], [2].
>>
>> I don;t know what those functions are, but from their names they seem to be related to figuring out the exception object and type?
> 
> I think so. I'm not a compiler expert hence my questions :-).
> 
>> Do you understand the itanium ABI's unwinding mechanism --
>> 1) follow stack to get to landing pad.
>> 2) invoke landing pad to see if it wants to catch
>> 3) if not, continue following stack
>> 4) once we've found one to catch it, we need to unwind properly, which involves invoking cleanups. and eventually getting to the catcher
>>
>> invoking the landing pad means passing (a) an integer telling it what's happening, and (b) a pointer to data.
> 
> This seems to be the data that I need. I just need to understand how that works.

I realized I'd got some details confused (it's been quite a while since 
I've dealt with this code).

When locating a landing pad to catch the exception the unwinder uses a 
personality routine, and passes it some data from the unwind table. 
That's a regular call in the context of the unwinder.  (It's called a 
personality routine, because it's keyed to the language trying to catch 
the exception.)  The landing pads are not called in this case.

The landing pad executes in the context of the function it's a landing 
pad for.  So the SP must be the expected one, all the (callee-save) 
registers must be as they were at the point of calling the function that 
threw, and everything below the SP is dead.  Of course the unwinder's 
frame is somewhere down the stack, and now dead.  eh_return is the thing 
that (a) adjusts the SP and (b) indirect jumps to the landing pad.  That 
is what the EH_Return macro is.  That code is in the unwinder, and is 
compiler-specific.


> 
>>> I looked into the GCC source code to find the corresponding parts but I could only find
>>> the macros prefixed with "EH_" [4] which I didn't fully understand.
>>
>> Those are the bits you want.  one of those is the selector (0?) and the other is the data pointer (1?).
> 
> OK. But aren't they passed through particular registers on m68k? Or is this something specific
> to LLVM?

Sorry, I think I confused the issue by conflating the eh_return 
(compiler-specific) with the passing of eh objects to the landing pad 
(ABI-specified).

do you know what those 2 functions you mention provide on say x86?  Then 
it might be easier to map onto 68k.

nathan

-- 
Nathan Sidwell