[Linuxppc-users] reasigning fp breaks the call chain

Thu Sep 21 02:50:07 AEST 2017

This may seem pretty basic, but have you considered sigsetjmp() and
siglongjmp()?

gerrit

--
"Only those who will risk going too far can possibly find out how far one
can go." ~ T. S. Eliot

Gerrit Huizenga, STSM
Power Open Source Ecosystem Lead
gerrit at us.ibm.com

From:	"Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
To:	Buse Yilmaz <busey at vt.edu>
Cc:	linuxppc-users at lists.ozlabs.org
Date:	09/20/2017 07:07 AM
Subject:	Re: [Linuxppc-users] reasigning fp breaks the call chain
Sent by:	"Linuxppc-users" <linuxppc-users-bounces
            +gerrit=us.ibm.com at lists.ozlabs.org>

Hi Buse,

I'm not sure I complete follow what exactly you're doing. In particular,
when you write "the call chain itself is broken as soon as I switch to the
destination", what exactly does that mean? What specifically is "broken"
and what are the symptoms of that breakage? Is it that the "backtrace"
command in GDB doesn't show what you expect, is it that when you start
executing code the function return crashes or doesn't return to the caller
you expect, or what?

Not knowing in more detail what you're doing, just some observations that
make me suspicious:

- "the callers don't have their frames on the stack yet" -- note that in
the ELFv2 ABI, there is an area of 32 bytes at the very bottom of each
frame including the back chain pointer, the LR save area, and the TOC save
area. This area formally belongs to the *caller* but is not actually used
by the caller -- the caller just allocates it on behalf of functions it
calls, which are free to use that space; all contents of that area are
maintained and used by the called function. So if you set up only the frame
of the callee, but do not properly initialize this area which is formally
part of the caller's frame, then the callee may not function correctly (in
particular when it attempts to return).

- Talking about the back chain field, this is something that other ABIs
don't have in this form. This field links each frame to its caller's frame,
so everything that copies or recreates stack frames must of course also
recompute new values for the back chain fields (just like you apparently do
for SP and FP). Do you do that? I'm wondering because you point out that
you force usage of an FP, but on Power this is usually not necessary since
we already have the back chain that can be used for those purposes you
usually use the FP for on other ABIs.

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU/Linux compilers and toolchain
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart,
HRB 243294

Inactive hide details for Buse Yilmaz ---19.09.2017 19:08:06---Hello, I'm
working on a project that does migration between machBuse Yilmaz
---19.09.2017 19:08:06---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: 19.09.2017 19:08
Subject: [Linuxppc-users] reasigning fp breaks the call chain
Sent by: "Linuxppc-users" <linuxppc-users-bounces
+uweigand=de.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://lists.ozlabs.org/listinfo/linuxppc-users

_______________________________________________
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=ZzfGBIaWDnwaVH6wsZg3mjvpGLeR7_C0DMvJty2qEhU&m=k-iJ7S-MAA0HA2vH-rPfBU_MmoRmlQMGxIV34mTAbBE&s=V7qn-4LRlgxQZ439jMNn7KAdjnHOCFGndfzMgPJgtZY&e=

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