This is the mail archive of the
mailing list for the GCC project.
Re: ARM: Imply frame pointer for arm-linux profiling
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 May 2005 13:57:40 +0100
- Subject: Re: ARM: Imply frame pointer for arm-linux profiling
- References: <20050511124437.GA2763@nevyn.them.org>
On Wed, 2005-05-11 at 13:44, Daniel Jacobowitz wrote:
> The arm-linux invocation of mcount does not pass the old value of lr in ip,
> the way the arm-elf or arm-netbsd implementations do. Instead the profiler
> grubs around in its caller's stack frame to find the saved lr. Gross, but
> nothing we can do about it now. This patch makes sure to create a frame
> if emitting the call to mcount. It fixes nest.c and 20021014-1.c in gcc.dg
> for arm-linux. OK for HEAD?
The arm/linux compiler hasn't used a frame pointer for approximately
forever. That was a decision taken by the linux developers long ago.
IMO if their mcount can't cope with that, then it's their mcount
implementation that's broken not the compiler. However, for the old
ABI, I really don't care very much (but see below).
> On a related question: The ARM EABI does not appear to say anything about
> mcount. Right now our arm-linux-gnueabi port of glibc uses the same mcount
> implementation as arm-linux, complete with this hack. Should the EABI
> specify something? Does it, that I missed?
No, it should not be done that way for the EABI. The EABI does not
sanction a frame pointer as a public entity and it's impractical to even
think of using one for Thumb. So mcount needs to use another way (like
the arm-elf or netbsd methods).
I would really like to kill *all* the apcs frame support code and then
use a simplified frame pointer scheme for those few cases where gcc
really needs one (alloca, variably-sized arrays etc). It's pointless
trying to use the existing code on Thumb, and it's wasteful on ARM when
it can't be relied upon.