From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <47EB760E.30804@wmipf.in-berlin.de>
Date: Thu, 27 Mar 2008 11:25:18 +0100
From: =?UTF-8?B?TWljaGFlbCBUZWljaGdyw6RiZXI=?= <mt@wmipf.in-berlin.de>
User-Agent: Icedove 1.5.0.14pre (X11/20080208)
MIME-Version: 1.0
To: 9fans@9fans.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [9fans] getcallerpc on arm7
Topicbox-Message-UUID: 837c3f08-ead3-11e9-9d60-3106f5b1d025

Hi,

trying to adapt the getcallerpc function - that
exists on Plan9 and p9p - to the arm7 using the arm-elf-gcc
compiler, I realized that this would not be easy, as
most function arguments are put into registers
(the return value into lr), and only pushed on the
stack on demand - so it seems one can not expect to find
the return address at a fixed position starting with
the first argument's address.

(Looking at runtime some ulongs around &firstarg I
actually can see the return address, but it is a varying
number of longs upwards (not downwards) of &firstarg)

I wonder under what conditions plan9port's
"return ((ulong*)x)[-2]" for arm-linux/gcc actually works.

So far I found out that I could implement getcallerpc as
a macro using gcc's __builtin_return_address(0), but this would
not fit getcallerpc's normal behaviour (which I suppose
only depends on &firstarg, not the current function
context).

Although I know that the Plan9 compilers and gcc organize
function calls differently, I thought it would be helpful to
understand what /sys/src/libc/arm/getcallerpc.s does -
after having a look at A Manual for the Plan 9 assembler:

	MOVW	0(R13), R0
	RET

Does this mean that it is just returning the contents of the
first word on the Stack (R13) - and not interpreting &firstarg
at all?

Thanks for any hint,

Michael