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

    From John Paul Adrian Glaubitz@21:1/5 to Nathan Sidwell on Thu Oct 1 11:50:01 2020
    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 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?

    Thanks for the help!
    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Nathan Sidwell on Thu Oct 1 14:40:02 2020
    Hi Nathan!

    Thanks for the explanations!

    On 10/1/20 2:27 PM, Nathan Sidwell wrote:
    do you know what those 2 functions you mention provide on say x86?  Then it might be easier to map onto 68k.

    From [1]:

    Register X86TargetLowering::getExceptionPointerRegister(
    const Constant *PersonalityFn) const {
    if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
    return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;

    return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
    }

    Register X86TargetLowering::getExceptionSelectorRegister(
    const Constant *PersonalityFn) const {
    // Funclet personalities don't use selectors (the runtime does the selection).
    assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
    return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
    }

    Adrian

    [1] https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nathan Sidwell@21:1/5 to John Paul Adrian Glaubitz on Thu Oct 1 14:50:01 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Nathan Sidwell on Thu Oct 1 15:00:02 2020
    On 10/1/20 2:46 PM, Nathan Sidwell wrote:
    Aha!  it is EH_RETURN :) and it appears stack adjustment is something different.

    for x86, gcc has:
    #define EH_RETURN_DATA_REGNO(N)    ((N) <= DX_REG ? (N) : INVALID_REGNUM)

    thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx depending on compilation mode)

    for m68k gcc has:
    #define EH_RETURN_DATA_REGNO(N) \
      ((N) < 2 ? (N) : INVALID_REGNUM)

    so that's registers d0 and d1

    I'm guessing EHPersonality:CoreCLR is a different ABI that you're not concerned with.

    Yeah, it also seems to be present in the X86 backend only (at least not in the Sparc backend).

    Thus I think you want:

    getExceptionPointerRegister to return d0 and getExceptionSelectorRegister to return d1.

    give that a go, and see if you can throw/catch exceptions between code compiled by your llvm port and a gcc

    Perfect, thanks.

    hope that helps.
    I'll give it a try.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nathan Sidwell@21:1/5 to John Paul Adrian Glaubitz on Thu Oct 1 15:10:01 2020
    On 10/1/20 8:32 AM, John Paul Adrian Glaubitz wrote:
    Hi Nathan!

    Thanks for the explanations!

    On 10/1/20 2:27 PM, Nathan Sidwell wrote:
    do you know what those 2 functions you mention provide on say x86?  Then it might be easier to map onto 68k.

    From [1]:

    Register X86TargetLowering::getExceptionPointerRegister(
    const Constant *PersonalityFn) const {
    if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
    return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;

    return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
    }

    Register X86TargetLowering::getExceptionSelectorRegister(
    const Constant *PersonalityFn) const {
    // Funclet personalities don't use selectors (the runtime does the selection).
    assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
    return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
    }

    Aha! it is EH_RETURN :) and it appears stack adjustment is something different.

    for x86, gcc has:
    #define EH_RETURN_DATA_REGNO(N) ((N) <= DX_REG ? (N) : INVALID_REGNUM)

    thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx
    depending on compilation mode)

    for m68k gcc has:
    #define EH_RETURN_DATA_REGNO(N) \
    ((N) < 2 ? (N) : INVALID_REGNUM)

    so that's registers d0 and d1

    I'm guessing EHPersonality:CoreCLR is a different ABI that you're not
    concerned with. Thus I think you want:

    getExceptionPointerRegister to return d0 and
    getExceptionSelectorRegister to return d1.

    give that a go, and see if you can throw/catch exceptions between code
    compiled by your llvm port and a gcc

    hope that helps.


    Adrian

    [1] https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp



    --
    Nathan Sidwell

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)