Linux on PowerPC ABI questions

Linux on PowerPC ABI questions

Post by Mikael Petterss » Mon, 07 Jul 2003 01:38:20



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 de*s 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
--

Computing Science Department, Uppsala University

 
 
 

Linux on PowerPC ABI questions

Post by Jean Tabe » Mon, 07 Jul 2003 09:06:32


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://www.veryComputer.com/
building
the toolchain).

You may also find the two following references of interest:

Developing PowerPC Embedded Application Binary Interface (EABI)
Compliant
Programs
http://www.veryComputer.com/

The PowerPC Compiler Writer's Guide
http://www.veryComputer.com/

Jean Tabel


> 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 de*s 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
> --

> Computing Science Department, Uppsala University


 
 
 

Linux on PowerPC ABI questions

Post by Mikael Petterss » Tue, 08 Jul 2003 08:37:59




>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/techlib.nsf/techdocs/852569B20050F...

>The PowerPC Compiler Writer's Guide
>http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050F...

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

Computing Science Department, Uppsala University

 
 
 

1. powerpc-linux, powerpc-eabi, powerpc-eabisim

Can someone explain me what is the difference between
PowerPC specific GNU packages (binutils, gcc, gdb etc.)
configuration options: powerpc-linux, powerpc-eabi,
powerpc-eabisim ?
ps. I'm going to port linux to a powerpc based embedded
system
Krzysztof

2. GCC Problem

3. question; PowerPC Linux

4. The MEDIA this year!

5. fopen ABI n32, o32 question

6. LARRY ELLISON

7. Power Mac/Linux PowerPC & Sony 15 inch Question

8. PA-Pick,Universe,Unidata Programmer/Analyst

9. Linux ABI?

10. Is Linux Intel-ABI compatible?

11. How do I reinstall linux-abi sources

12. Linux ABI and Disk Thrashing

13. Any Linux Distribution with ABI already installed?