linux-kernel - Re: [PATCH] Kconfig.debug: Add FRAME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <C2D7FE5348E1B147BCA15975FBA230751414AB@IN01WEMBXA.internal.synopsys.com>
Date:	Mon, 2 Sep 2013 11:41:53 +0000
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paul.mckenney@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Michel Lespinasse <walken@...gle.com>
Subject: Re: [PATCH] Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC

Hi Gilad,

On 09/02/2013 02:33 PM, Gilad Ben-Yossef wrote:
> Hi,
>
> On Tue, Aug 27, 2013 at 11:31 AM, Vineet Gupta
> <Vineet.Gupta1@...opsys.com> wrote:
>> Frame pointer on ARC doesn't serve the conventional purpose of stack
>> unwinding due to the typical way ABI designates it's usage.
> More out of curiosity to understand the platform better than actual
> review - can you explain a little what
> you meant by this statement?
>
> Is this statement because of the use of write back mode with ld/st to
> or not related?

No - this is not related to to any LD/ST addressing/wb modes.

ARCompact ISA has 2 stack related registers, SP (top) and FP (Base)

A typical frame pointer-ish ABI would do sometime like this
1. push BLINK (return address)
2. push FP
3. FP = SP
4. push callee-regs
5. allocate stack for local vars etc
...

Note that beyond #3, FP remains constant while this function is in scope. Thus
from anywhere inside the function, [FP, 4] always has caller's PC and [FP, 0]
always has caller's FP. This makes it possible to retract back to caller and from
there to it's caller and so on.

However the ARC gcc ABI - set in stone many years ago doesn't do this. It does 1,
4, 2, 3...

With FP no longer having base address of current call, it can't be used to get
FP/BLINK of prev frame so from stack unwinding perspective, there's no point in
using FP for stack frames. More importantly, FP usage bloats function
prologue/epilogue - adds extra stack ops, .... hence it's usage in general is
discouraged. gcc though is free to summon it's usage for typical stack frames (var
sized arrays etc).

Hence the reason we don't ever build ARC with FP and need for this patch.

HTH,
-Vineet

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/