From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
From: "Russ Cox" <rsc@swtch.com>
Date: Mon, 31 Mar 2008 09:24:44 -0700
In-Reply-To: <47EB760E.30804@wmipf.in-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080331162530.C70ED1E8C3A@holo.morphisms.net>
Subject: Re: [9fans] getcallerpc on arm7
Topicbox-Message-UUID: 85c32dbc-ead3-11e9-9d60-3106f5b1d025

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

This appears to be wrong, but I don't have time to dig in.

The pointer is intended to be used on architectures like the x86
that automatically push the return address on the stack.

On architectures that don't push the return address on the
stack during the call instruction, the caller of getcallerpc
will have saved the desired return address somewhere in
its stack frame, and getcallerpc must root it out.

vc (the MIPS compiler) saves the return PC in the very last
word of the stack frame, so that /sys/src/libc/mips/getcallerpc.s:

	TEXT	getcallerpc(SB), $0
		MOVW	0(SP), R1
		RET

is correct.

It appears that 5c (the ARM compiler) saves the return PC
as the first word of the stack frame, which may be somewhat
hard to locate.

Russ