<div dir="ltr">The machine we have is a power8<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 7:44 PM, Buse Yilmaz <span dir="ltr"><<a href="mailto:busey@vt.edu" target="_blank">busey@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>Hmm, yes I didnt think about the red zone. I will check if somehow I point there with FP.<br></div>Thank you<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Sep 19, 2017 at 6:24 PM, Steve Munroe <span dir="ltr"><<a href="mailto:sjmunroe@us.ibm.com" target="_blank">sjmunroe@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><font size="2">Which ABI are you on PPC32BE, PPC64BE or PPC64LE?</font><br><br><font size="2">The current systems are PowerPC 64-bit Little Endian: which has it own ELF V2 ABI: </font><a href="http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/ch_preface.html" target="_blank"><font size="2">http://openpowerfoundation.org<wbr>/wp-content/uploads/resources/<wbr>leabi/content/ch_preface.html</font></a><br><br><font size="2">As such the PowerABIs do not necessarily have a frame-pointer unless the function has used alloca. </font><br><br><font size="2">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.</font><br><br><font size="2">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.</font><br><br><font size="2">Steven J. Munroe<br>Linux on Power Toolchain Architect<br>IBM Corporation, Linux Technology Center<br></font><br><br><img src="cid:1__=8FBB0B33DFF057308f9e8a93df938690918c8FB@" alt="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" width="16" border="0" height="16"><font size="2" color="#424282">Buse Yilmaz ---09/19/2017 12:08:33 PM---Hello, I'm working on a project that does migration between machines with</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Buse Yilmaz <<a href="mailto:busey@vt.edu" target="_blank">busey@vt.edu</a>></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2"><a href="mailto:linuxppc-users@lists.ozlabs.org" target="_blank">linuxppc-users@lists.ozlabs.or<wbr>g</a></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">09/19/2017 12:08 PM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[Linuxppc-users] reasigning fp breaks the call chain</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">"Linuxppc-users" <linuxppc-users-bounces+sjmunr<wbr>oe=<a href="mailto:us.ibm.com@lists.ozlabs.org" target="_blank">us.ibm.com@lists.ozlabs.org</a><wbr>></font><br></p><hr style="color:#8091a5" width="100%" size="2" noshade align="left"><div><div class="m_-161193911470368722h5"><br><br><br>Hello,<br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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. <br><br>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.<br><br>I'm looking forward your help. apologies for what I have described being very abstract and long. <br><br>P.S. We observe this behavior on neither x86 nor ARM.<br><br>Thank you!<br><br><br><br>-- <br></div></div>Buse<tt><font size="2">__________________________<wbr>_____________________<br>Linuxppc-users mailing list<br><a href="mailto:Linuxppc-users@lists.ozlabs.org" target="_blank">Linuxppc-users@lists.ozlabs.or<wbr>g</a><br></font></tt><tt><font size="2"><a href="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=" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.o<wbr>zlabs.org_listinfo_linuxppc-2D<wbr>users&d=DwIGaQ&c=jf_iaSHvJObTb<wbr>x-siA1ZOg&r=T7r-LXDLinWJNLr1nU<wbr>UPaUUYEahDQNyKidvdz_Y3ljY&m=to<wbr>XY1jZlNzqaIc6qK8_eLjx12Rcr9XLD<wbr>vFShZrKB3VE&s=DU5CeEsHnrzGt3v8<wbr>y0hRbmo1baM-vrqtv-33nkhKzlo&e=</a></font></tt><tt><font size="2"><wbr> <br></font></tt><br><br><br>
<p></p></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-161193911470368722gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Buse</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Buse</div></div>
</div>