Subject: Re: The ELF ABI issue
To: None <>
From: Reinoud Zandijk <>
List: port-arm
Date: 03/27/2002 12:47:30
Hiya Richard,

On Wed, Mar 27, 2002 at 11:31:10AM +0000, Richard Earnshaw wrote:
> > 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.

:-/ i see... well i am not that big a fan of gcc too but its one of the few
that are free yes... i liked the ARM/Norcroft ones more ... faster in
compilation and faster running code.... guess its impossible to use them 
for NetBSD ? Hehe... I can imagine Jason's looks now ;)

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

Tue... sounds good yes.... where is r11 used now for anyway? as the 
framepointer? or can it later be used for generic code as well ?

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

Ieekk... i didnt even know alloca existed... and looking at the man page it 
on one hand sounds reasonable but yes it does have its problems too yes... 
_unless_ you manage to allocate stuff _below_ the framepointer :)

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

This is really .... disturbing IMHO ... you mean that if you use threads 
you can't just use a recursive function with a reasonable depth ? say a 
1000 or 15000 ? and you can without threads ?