When probing 32-bits apps on ppc64 or running native ppc32, int64
parts are stored in the big endian order, e.g. foo(1LL, 2LL, 3LL)'s
args turn into:
arg1: r3 = 0; r4 = 1
arg2: r5 = 0; r6 = 2
arg3: r7 = 0; r8 = 3
For example, to restore arg1 the current longlong_arg() will perform
(r4 << 32) | r3, which is obviously incorrect. And to restore arg2 it
will do (r5 << 32) | r4, which doesn't look right as well.
This patch fixes the issue.
Signed-off-by: Anton Vorontsov <avoront...@ru.mvista.com>
---
tapset/powerpc/registers.stp | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tapset/powerpc/registers.stp b/tapset/powerpc/registers.stp
index 7f66d36..2403272 100644
--- a/tapset/powerpc/registers.stp
+++ b/tapset/powerpc/registers.stp
@@ -179,8 +179,8 @@ function ulong_arg:long (argnum:long) {
function longlong_arg:long (argnum:long) {
if (probing_32bit_app()) {
- lowbits = _stp_arg(argnum, 0, 1)
- highbits = _stp_arg(argnum+1, 0, 1)
+ lowbits = _stp_arg(argnum * 2, 0, 1)
+ highbits = _stp_arg(argnum * 2 - 1, 0, 1)
return ((highbits << 32) | lowbits)
} else
return _stp_arg(argnum, 0, 0)
--
1.6.3.3
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
