[Linuxppc-users] reasigning fp breaks the call chain

[Buse Yilmaz]

The machine we have is a power8

On Tue, Sep 19, 2017 at 7:44 PM, Buse Yilmaz <busey at vt.edu> wrote:

> 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.o
>> zlabs.org_listinfo_linuxppc-2Dusers&d=DwIGaQ&c=jf_iaSHvJObTb
>> x-siA1ZOg&r=T7r-LXDLinWJNLr1nUUPaUUYEahDQNyKidvdz_Y3ljY&m=to
>> XY1jZlNzqaIc6qK8_eLjx12Rcr9XLDvFShZrKB3VE&s=DU5CeEsHnrzGt3v8
>> y0hRbmo1baM-vrqtv-33nkhKzlo&e=
>>
>>
>>
>>
>
>
> --
> Buse
>



-- 
Buse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-users/attachments/20170919/ea842463/attachment-0001.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/ea842463/attachment-0001.gif>