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

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

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

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 [url]http://pages.infinit.net/jtabel/embedded/build-ppc.sh[/url] for
building
the toolchain).

You may also find the two following references of interest:

Developing PowerPC Embedded Application Binary Interface (EABI)
Compliant
Programs
[url]http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852569970071B0D6[/url]

The PowerPC Compiler Writer's Guide
[url]http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6[/url]

Jean Tabel

"Mikael Pettersson" <mikpe@harpo.csd.uu.se> wrote in message
news:3f06f0ec$1@puffinus.its.uu.se...[color=blue]
> 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[/color]

In article <CJJNa.106069$0B.2017968@wagner.videotron.net>,
Jean Tabel <jtabel@videotron.ca> wrote:[color=blue]
>I think Linux/PPC is using EABI, and not System V ABI.
>
>Look at cygnus/redhat ppc-docs directory for EABI
>specification: [url]ftp://sources.redhat.com/pub/binutils/ppc-docs/[/url]
>
>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 [url]http://pages.infinit.net/jtabel/embedded/build-ppc.sh[/url] for
>building
>the toolchain).
>
>You may also find the two following references of interest:
>
>Developing PowerPC Embedded Application Binary Interface (EABI)
>Compliant
>Programs
>[url]http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852569970071B0D6[/url]
>
>The PowerPC Compiler Writer's Guide
>[url]http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6[/url][/color]

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