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.gup...@synopsys.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
