| Message ID | 20091203233154.GB3416@oksana.dev.rtsoft.ru (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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)
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 <avorontsov@ru.mvista.com> --- tapset/powerpc/registers.stp | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)