Linux on PowerPC ABI questions - Powerpc

This is a discussion on Linux on PowerPC ABI questions - Powerpc ; I'm planning a port of a concurrent functional language to Linux/PPC, and I have a few questions regarding the ABI. I'm assuming Linux follows the "SYSTEM V APPLICATION BINARY INTERFACE PowerPC Processor Supplement" document by SunSoft/IBM, dated September '95 (psABI). ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Linux on PowerPC ABI questions

  1. Linux on PowerPC ABI questions

    I'm planning a port of a concurrent functional language
    to Linux/PPC, and I have a few questions regarding the ABI.

    I'm assuming Linux follows the "SYSTEM V APPLICATION BINARY
    INTERFACE PowerPC Processor Supplement" document by SunSoft/IBM,
    dated September '95 (psABI). If this is not the case, can
    someone please point me to the correct ABI document?

    1. It appears, from reading the psABI and gcc sources, that
    r2 contains the TOC/GOT and r13 the small data pointer,
    and both registers are reserved. Is this true?

    2. On page 3-24, section Virtual Address Assignments, there
    is a comment stating that although a program base of 64K
    is conventional, they recommend a program base of 32M,
    and refer to Chapter 5 (Program Loading and Dynamic Linking)
    for justification. I can't find anything there to back up
    their recommendation. As I understand it, a program base of
    32M makes it impossible to use "branch absolute" instructions
    for calls within the application's code (exluding shared libs).
    So why use a program base of 32M?

    3. In Chapter 4 (Object files) the psABI describes "Tags", a
    mechanism apparently used to discover register values while
    doing stack backtracing in debuggers and exception handlers.
    What, if anything, uses these tags in normal C code? longjmp()
    might, but it seems longjmp() uses the conventional approach
    of simply saving the registers at setjmp() and trowing back
    without parsing stack frames.
    If our compiler puts its stack frames on the C stack (r1),
    are we then required to add these "Tags"?

    4. The call stack frame layout (page 3-17) is overly constrained
    for our compiler, in particular we don't need 16-byte alignment,
    we don't need a fixed word for saving the LR, and we don't need
    to store a backchain in each frame's lowest word.
    What, if anything, relies on the 16-byte stack alignment?
    What, if anything, uses the backchain in normal C code?
    (Again, longjmp() might but I don't think it needs to.)
    If we put our stack frames on the C stack (r1), are we required
    to follow these layout rules? (Obviously, if we call a C
    function we have to have an LR save word for the callee's use,
    but we don't really need one in calls to our own code.)

    /Mikael
    --
    Mikael Pettersson (mikpe@csd.uu.se)
    Computing Science Department, Uppsala University

  2. Re: Linux on PowerPC ABI questions

    I think Linux/PPC is using EABI, and not System V ABI.

    Look at cygnus/redhat ppc-docs directory for EABI
    specification: ftp://sources.redhat.com/pub/binutils/ppc-docs/

    According to the specification, r13 is dedicated (non-volatile) to
    the
    read-write small data area anchor, and r2 is dedicated to the
    read-only small data area anchor.

    I am not familiar enough with EABI for answering to questions 2-3 :-(

    Note that you can create a gcc/binutils/newlib/insight toolchain,
    with eabisim as a target that, will allow you to debug EABI
    applications
    using insight or gdb under Linux/*BSD or cygwin
    (See http://pages.infinit.net/jtabel/embedded/build-ppc.sh for
    building
    the toolchain).

    You may also find the two following references of interest:

    Developing PowerPC Embedded Application Binary Interface (EABI)
    Compliant
    Programs
    http://www-3.ibm.com/chips/techlib/t...2569970071B0D6

    The PowerPC Compiler Writer's Guide
    http://www-3.ibm.com/chips/techlib/t...256996007558C6

    Jean Tabel

    "Mikael Pettersson" wrote in message
    news:3f06f0ec$1@puffinus.its.uu.se...
    > I'm planning a port of a concurrent functional language
    > to Linux/PPC, and I have a few questions regarding the ABI.
    >
    > I'm assuming Linux follows the "SYSTEM V APPLICATION BINARY
    > INTERFACE PowerPC Processor Supplement" document by SunSoft/IBM,
    > dated September '95 (psABI). If this is not the case, can
    > someone please point me to the correct ABI document?
    >
    > 1. It appears, from reading the psABI and gcc sources, that
    > r2 contains the TOC/GOT and r13 the small data pointer,
    > and both registers are reserved. Is this true?
    >
    > 2. On page 3-24, section Virtual Address Assignments, there
    > is a comment stating that although a program base of 64K
    > is conventional, they recommend a program base of 32M,
    > and refer to Chapter 5 (Program Loading and Dynamic Linking)
    > for justification. I can't find anything there to back up
    > their recommendation. As I understand it, a program base of
    > 32M makes it impossible to use "branch absolute" instructions
    > for calls within the application's code (exluding shared libs).
    > So why use a program base of 32M?
    >
    > 3. In Chapter 4 (Object files) the psABI describes "Tags", a
    > mechanism apparently used to discover register values while
    > doing stack backtracing in debuggers and exception handlers.
    > What, if anything, uses these tags in normal C code? longjmp()
    > might, but it seems longjmp() uses the conventional approach
    > of simply saving the registers at setjmp() and trowing back
    > without parsing stack frames.
    > If our compiler puts its stack frames on the C stack (r1),
    > are we then required to add these "Tags"?
    >
    > 4. The call stack frame layout (page 3-17) is overly constrained
    > for our compiler, in particular we don't need 16-byte alignment,
    > we don't need a fixed word for saving the LR, and we don't need
    > to store a backchain in each frame's lowest word.
    > What, if anything, relies on the 16-byte stack alignment?
    > What, if anything, uses the backchain in normal C code?
    > (Again, longjmp() might but I don't think it needs to.)
    > If we put our stack frames on the C stack (r1), are we required
    > to follow these layout rules? (Obviously, if we call a C
    > function we have to have an LR save word for the callee's use,
    > but we don't really need one in calls to our own code.)
    >
    > /Mikael
    > --
    > Mikael Pettersson (mikpe@csd.uu.se)
    > Computing Science Department, Uppsala University




  3. Re: Linux on PowerPC ABI questions

    In article ,
    Jean Tabel wrote:
    >I think Linux/PPC is using EABI, and not System V ABI.
    >
    >Look at cygnus/redhat ppc-docs directory for EABI
    >specification: ftp://sources.redhat.com/pub/binutils/ppc-docs/
    >
    >According to the specification, r13 is dedicated (non-volatile) to
    >the
    >read-write small data area anchor, and r2 is dedicated to the
    >read-only small data area anchor.
    >
    >I am not familiar enough with EABI for answering to questions 2-3 :-(
    >
    >Note that you can create a gcc/binutils/newlib/insight toolchain,
    >with eabisim as a target that, will allow you to debug EABI
    >applications
    >using insight or gdb under Linux/*BSD or cygwin
    >(See http://pages.infinit.net/jtabel/embedded/build-ppc.sh for
    >building
    >the toolchain).
    >
    >You may also find the two following references of interest:
    >
    >Developing PowerPC Embedded Application Binary Interface (EABI)
    >Compliant
    >Programs
    >http://www-3.ibm.com/chips/techlib/t...2569970071B0D6
    >
    >The PowerPC Compiler Writer's Guide
    >http://www-3.ibm.com/chips/techlib/t...256996007558C6


    Thanks for these documentation pointers.

    I'm not convinced Linux/PPC uses the EABI, at least not
    in normal desktop/server systems. "file" on binaries in
    YDL, for example, simply identifies the files as PPC and
    SYSV, without mentioning embedded.

    Also, glibc-linuxthreads uses r2 as the TLS (thread local
    storage) pointer, which contradicts the EABI using it for
    the small read-only data area.

    OTOH, nothing on gcc/binutils/glibc seems to mention the horrible
    "Tags" described in the SYSV psABI, which makes my compiler-
    writing life at lot easier.

    /Mikael
    --
    Mikael Pettersson (mikpe@csd.uu.se)
    Computing Science Department, Uppsala University

+ Reply to Thread