Subject: Re: The ELF ABI issue
To: Reinoud Zandijk <reinoud@netbsd.org>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm
Date: 03/27/2002 11:31:10
> > *If* I had complete freedom to implement the ABI from scratch, then r11
> > would probably be my choice too. However, there is too much legacy use of
> > r11 as a frame pointer to even consider that one now.
>
> In legacy code ok... but still NetBSD could use it as a temp. storage of
> the TLS ;) ... and why not use that r11 now in the ABI? ppl. are either
> conforming with it or now ... so i don't think its gonna bite anyway ...
Not quite that simple. Although the new ABI is a major change for gcc,
it's not much more than a tidying up of a few corners for ADS users
(except for C++ code). GCC has languished well behind the curve on ABI
"conformance"; it could justify doing that when it was changing, but now
that it is being stabilized the excuses become more feeble.
> > Note that the new ABI won't require a frame pointer, and I intend turning
> > it's use in the compiler off, just as soon as we can make other tools
> > (such as gdb) manage without it.
>
> Hope so ... allthough a frame pointer is handy at times.... but if it gets
> loaded again and again anyway then its silly to waste a register on it
> yes...
A frame pointer is only of any use if you use silly (generally
non-portable) things like alloca[1], or other hacks that mean that the
stack pointer has to move more than once in each function. In all
"normal" code, the frame pointer and stack pointer have a known
relationship (fp = sp + const), so one of them is redundant.
R.
[1] Consider the situation of finite, non-extensible, stacks such as can
happen when you have threads, or on small embedded systems and you'll soon
agree that alloca is a nightmare.