[Linuxppc-users] reasigning fp breaks the call chain

[Buse Yilmaz]

The ABI is PPC64LE and I have been following 64-bit ELF V2 ABI
specification rev. 1.4 as documentation. The system runs ubuntu 16.04.3
xenial with kernel Linux power 4.4.0-75-generic.

Hmm, yes I didnt think about the red zone. I will check if somehow I point
there with FP.
Thank you

On Tue, Sep 19, 2017 at 6:24 PM, Steve Munroe <sjmunroe at us.ibm.com> wrote:

> Which ABI are you on PPC32BE, PPC64BE or PPC64LE?
>
> The current systems are PowerPC 64-bit Little Endian: which has it own ELF
> V2 ABI: http://openpowerfoundation.org/wp-content/uploads/
> resources/leabi/content/ch_preface.html
>
> As such the PowerABIs do not necessarily have a frame-pointer unless the
> function has used alloca.
>
> There is will always a SP but there are special rules for leaf routines
> where the up to 224 bytes below the SP may used without allocating a frame.
>
> Also the ELF V2 ABI has some optimization not in ELV V1 that change the
> minimum stack frame size, rules for parameter passing, and optimization for
> dynamic calls and TOC save/restore.
>
> Steven J. Munroe
> Linux on Power Toolchain Architect
> IBM Corporation, Linux Technology Center
>
>
> [image: Inactive hide details for Buse Yilmaz ---09/19/2017 12:08:33
> PM---Hello, I'm working on a project that does migration between m]Buse
> Yilmaz ---09/19/2017 12:08:33 PM---Hello, I'm working on a project that
> does migration between machines with
>
> From: Buse Yilmaz <busey at vt.edu>
> To: linuxppc-users at lists.ozlabs.org
> Date: 09/19/2017 12:08 PM
> Subject: [Linuxppc-users] reasigning fp breaks the call chain
> Sent by: "Linuxppc-users" <linuxppc-users-bounces+sjmunroe=
> us.ibm.com at lists.ozlabs.org>
> ------------------------------
>
>
>
> Hello,
> I'm working on a project that does migration between machines with
> different ISAs (currently x86_64, Aarch64 and PowerPC64). The migration is
> done with a compiler and runtime support based LLVM (3.7) that does stack
> transformation. It generates binaries for all ISAs and resumes the
> execution on the migrated architecture. For this purpose we record the
> registers and walk the call chain to record any other information needed
> such as callee-saved registers, live values and addresses that FP and SP
> point to, CFA, TOC...etc. We enforce the usage of an FP. Then create the
> same call chain on the destination architecture.
>
> To test our stack transformation first we try it on the same architecture
> assuming we do a migration from an architecture with ISA x to the machine
> with the same ISA.. We get an architecture say PowerPC, divide its stack
> into 2 and walk the call chain on the upper partuntil the leaf fuction is
> hit, then switch to the lower part assuming this is the destination
> architecture and rewrite the frames here.
>
> To resume the execution when we switch to the lower part of the stack, we
> jump to the beginning of the leaf function and attach FP and SP accordingly
> (we already know the whole register values of this function as well as its
> frame size) and load the register set with correct values.
>
> We're able to walk the chain up on the destination and create all the call
> frames, however the call chain itself is broken as soon as I switch to the
> destination. To be more precise it's broken when I move the FP to point to
> SP on the destination stack (this is how LLVM does it, FP points to the top
> of the stack ust as SP does). So I'm left with some frames missing, no
> crashes but the execution is not correctly performed.
>
> I assume that the backchain is broken on destination since we resume
> starting from the leaf function, at this point the callers don't have their
> frames on the stack yet.
>
> I wonder if creating frames on the destination in the reverse order (a.k.a
> like a normal execution would do, filling the stack with frames starting
> from the caller not the callee.
>
> I'm looking forward your help. apologies for what I have described being
> very abstract and long.
>
> P.S. We observe this behavior on neither x86 nor ARM.
>
> Thank you!
>
>
>
> --
> Buse_______________________________________________
> Linuxppc-users mailing list
> Linuxppc-users at lists.ozlabs.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> ozlabs.org_listinfo_linuxppc-2Dusers&d=DwIGaQ&c=jf_
> iaSHvJObTbx-siA1ZOg&r=T7r-LXDLinWJNLr1nUUPaUUYEahDQNyKidvdz_Y3ljY&m=
> toXY1jZlNzqaIc6qK8_eLjx12Rcr9XLDvFShZrKB3VE&s=DU5CeEsHnrzGt3v8y0hRbmo1baM-
> vrqtv-33nkhKzlo&e=
>
>
>
>


-- 
Buse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-users/attachments/20170919/204fe677/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-users/attachments/20170919/204fe677/attachment.gif>