[Linuxppc-users] reasigning fp breaks the call chain

[Buse Yilmaz]

It looks like I'm not touching that 224 bytes.


Thanks for the help


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

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



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