|
From: Dave N. <dc...@us...> - 2006-03-01 23:43:53
|
I was testing out some of the new instrs in Appendix F of the PowerPC
Instr Set Manual and found that the following instrs cause a Valgrind
Sanity check failure:
rldcl
rldcr
rldic
rldicl
rldicr
rldimi
srdi
Bugzilla report # 122944 identifies the subset of new instrs that aren't
recognized by V 3.1.0. A testcase for those instrs is included in that
report. The above instrs are now recognized by the SVN version (Feb 28)
but get an internal error. Details below.
I ran this on a Power5 running SuSe 9.0, uname -a info:
Linux elm3b149 2.6.5-7.97-pseries64.nm #1 SMP Thu Mar 31 10:55:11 PST
2005 ppc64 ppc64 ppc64 GNU/Linux
==9925== Memcheck, a memory error detector.
==9925== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==9925== Using LibVEX rev 1578, a library for dynamic binary translation.
==9925== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks
LLP.==9925== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation
framework.
==9925== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==9925==
--9925-- Command line
--9925-- a.out
--9925-- Startup, with flags:
--9925-- -v
--9925-- Contents of /proc/version:
--9925-- Linux version 2.6.5-7.97-pseries64.nm (geeko@buildhost) (gcc
version 3.3.3 (SuSE Linux)) #1 SMP Thu Mar 31 10:55:11 PST 2005
--9925-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX
--9925-- Valgrind library directory:
/home/dcn/svn/nightly/valgrind/.in_place
--9925-- Reading syms from /lib/ld-2.3.3.so (0x4100000)
--9925-- Reading syms from /home/dcn/work/bugs/unimpl/a.out (0x10000000)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/memcheck/memcheck-ppc32-linux (0x70000000)
--9925-- object doesn't have a dynamic symbol table
--9925-- Reading suppressions file:
/home/dcn/svn/nightly/valgrind/.in_place/default.supp
--9925-- REDIR: 0x4113040 (strlen) redirected to 0x7002CD00
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--9925-- REDIR: 0x4112F50 (strcmp) redirected to 0x7002CD28
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/coregrind/vgpreload_core-ppc32-linux.so
(0xFFDF000)
--9925-- Reading syms from
/home/dcn/svn/nightly/valgrind/memcheck/vgpreload_memcheck-ppc32-linux.so
(0xFFBA000)
--9925-- Reading syms from /lib/tls/libc.so.6 (0xFE73000)
--9925-- REDIR: 0xFEE7300 (rindex) redirected to 0xFFBD194 (rindex)
IR SANITY CHECK FAILURE
IRBB {
t0:I32 t1:I32 t2:I32 t3:I32 t4:I32 t5:I32 t6:I32 t7:I32
t8:I32 t9:I32 t10:I32 t11:I32 t12:I32 t13:I32 t14:I32
t15:I32
t16:I32 t17:I32 t18:I32 t19:I32 t20:I32 t21:I32 t22:I32
t23:I32
t24:I32 t25:I32 t26:I32 t27:I32 t28:I32 t29:I32 t30:F64
t31:I32
t32:I32 t33:I32 t34:F64 t35:I32 t36:I32 t37:I32 t38:I32
t39:I32
t40:I32 t41:I32 t42:I32 t43:I32 t44:I32 t45:I32 t46:I32
t47:I32
t48:I32 t49:I32 t50:I32 t51:I32 t52:I32 t53:I32 t54:I32
t55:I32
t56:I32 t57:I32 t58:I32 t59:I32 t60:I32 t61:I32 t62:I32
t63:I32
t64:I32 t65:I32 t66:I32 t67:I32 t68:I32 t69:I32 t70:I32
t71:I32
t72:I32 t73:I32 t74:I32 t75:I32 t76:I32 t77:I32 t78:I32
t79:I32
------ IMark(0x10000408, 4) ------
t1 = GET:I32(124)
t0 = GET:I32(4)
t2 = Add32(GET:I32(4),0xFFFFFE10:I32)
PUT(4) = t2
STbe(t2) = t0
------ IMark(0x1000040C, 4) ------
PUT(896) = 0x1000040C:I32
t4 = GET:I32(0)
t3 = GET:I32(124)
t5 = Add32(GET:I32(4),0x1EC:I32)
STbe(t5) = t3
------ IMark(0x10000410, 4) ------
PUT(896) = 0x10000410:I32
t6 = GET:I32(4)
t8 = GET:I32(4)
------ IMark(0x10000414, 4) ------
PUT(896) = 0x10000414:I32
t9 = GET:I32(0) t10 = GET:I32(28)
t11 = 0x3FF00000:I32 PUT(36) = t11
------ IMark(0x10000418, 4) ------ PUT(896) = 0x10000418:I32
t12 = GET:I32(0) t13 = GET:I32(0)
t14 = 0x0:I32 PUT(40) = t14
------ IMark(0x1000041C, 4) ------
PUT(896) = 0x1000041C:I32 t16 = GET:I32(0)
t15 = GET:I32(36)
t17 = Add32(GET:I32(124),0x20:I32)
STbe(t17) = t15
------ IMark(0x10000420, 4) ------
PUT(896) = 0x10000420:I32
t19 = GET:I32(0)
t18 = GET:I32(40)
t20 = Add32(GET:I32(124),0x24:I32)
STbe(t20) = t18
------ IMark(0x10000424, 4) ------
PUT(896) = 0x10000424:I32
t22 = GET:I32(0)
t21 = GET:I32(36)
t23 = Add32(GET:I32(124),0x1D0:I32)
STbe(t23) = t21
------ IMark(0x10000428, 4) ------
PUT(896) = 0x10000428:I32
t25 = GET:I32(0)
t24 = GET:I32(40)
t26 = Add32(GET:I32(124),0x1D4:I32)
STbe(t26) = t24------ IMark(0x1000042C, 4) ------
PUT(896) = 0x1000042C:I32
t28 = GET:I32(124)
t29 = GET:I32(0)
t27 = Add32(GET:I32(124),0x1D0:I32)
PUT(128) = LDbe:F64(t27)
------ IMark(0x10000430, 4) ------
PUT(896) = 0x10000430:I32
t30 = GET:F64(128)
t32 = GET:I32(124)
t33 = GET:I32(0)
t31 = Add32(GET:I32(124),0x18:I32)
STbe(t31) = t30
------ IMark(0x10000434, 4) ------
PUT(896) = 0x10000434:I32
t34 = GET:F64(128)
t36 = GET:I32(124)
t37 = GET:I32(0)
t35 = Add32(GET:I32(124),0x10:I32)
STbe(t35) = t34
------ IMark(0x10000438, 4) ------
PUT(896) = 0x10000438:I32
t38 = GET:I32(124)
t39 = GET:I32(0)
t40 = Add32(t38,0x40:I32)
PUT(0) = t40
------ IMark(0x1000043C, 4) ------
PUT(896) = 0x1000043C:I32
t42 = GET:I32(0)
t41 = GET:I32(0)
t43 = Add32(GET:I32(124),0x2C:I32)
STbe(t43) = t41
------ IMark(0x10000440, 4) ------
PUT(896) = 0x10000440:I32
t44 = GET:I32(0)
t45 = GET:I32(0)
t46 = 0x8:I32------ IMark(0x10000444, 4) ------
PUT(896) = 0x10000444:I32
t48 = GET:I32(0)
t47 = GET:I32(0)
t49 = Add32(GET:I32(124),0x30:I32)
STbe(t49) = t47
------ IMark(0x10000448, 4) ------
PUT(896) = 0x10000448:I32
t50 = GET:I32(0)
t51 = GET:I32(0)
t52 = 0x4:I32
PUT(0) = t52
------ IMark(0x1000044C, 4) ------
PUT(896) = 0x1000044C:I32
t54 = GET:I32(0)
t53 = GET:I32(0)
t55 = Add32(GET:I32(124),0x34:I32)
STbe(t55) = t53
------ IMark(0x10000450, 4) ------
PUT(896) = 0x10000450:I32
t56 = Add32(GET:I32(124),0x2C:I32)
PUT(36) = LDbe:I32(t56)
------ IMark(0x10000454, 4) ------
PUT(896) = 0x10000454:I32
t57 = Add32(GET:I32(124),0x30:I32)
PUT(0) = LDbe:I32(t57)
------ IMark(0x10000458, 4) ------
PUT(896) = 0x10000458:I32
t58 = GET:I32(36)
t60 = GET:I32(0)
t59 =
And64(Mux0X(And8(64to8(t60),0x1F:I8),t58,Or32(Shl32(t58,And8(64to8(t60),0x1F:I8)),Shr32(t58,Sub8(0x20:I8,And8(64to8(t60),0x1F:I8))))),0xFFFFFFFFFFFFFF:I64)
PUT(0) = t59
------ IMark(0x1000045C, 4) ------
PUT(896) = 0x1000045C:I32
t63 = GET:I32(0)
t62 = GET:I32(0)
t64 = Add32(GET:I32(124),0x28:I32)
STbe(t64) = t62
------ IMark(0x10000460, 4) ------
PUT(896) = 0x10000460:I32
t65 = GET:I32(0)
t67 = GET:I32(0)
t66 = t65
PUT(12) = t66
------ IMark(0x10000464, 4) ------
PUT(896) = 0x10000464:I32
t68 = Add32(GET:I32(4),0x0:I32)
PUT(44) = LDbe:I32(t68)
------ IMark(0x10000468, 4) ------
PUT(896) = 0x10000468:I32
t69 = Add32(GET:I32(44),0xFFFFFFFC:I32)
PUT(124) = LDbe:I32(t69)
------ IMark(0x1000046C, 4) ------
PUT(896) = 0x1000046C:I32
t70 = GET:I32(44)
t72 = GET:I32(44)
t71 = t70
PUT(4) = t71
------ IMark(0x10000470, 4) ------
PUT(896) = 0x10000470:I32
t77 = 0xFFFFFFFF:I32
t74 = t77
t78 = 0x1:I32
t75 = t78
t73 = And32(t75,t74)
t76 = And32(GET:I32(900),0xFFFFFFFC:I32)
if (CmpEQ32(t73,0x0:I32)) goto {Boring} 0x10000474:I32
goto {Return} t76
}
IN STATEMENT:
t59 =
And64(Mux0X(And8(64to8(t60),0x1F:I8),t58,Or32(Shl32(t58,And8(64to8(t60),0x1F:I8)),Shr32(t58,Sub8(0x20:I8,And8(64to8(t60),0x1F:I8))))),0xFFFFFFFFFFFFFF:I64)
ERROR = Iex.Unop: arg ty doesn't match op ty
vex: the `impossible' happened:
sanityCheckFail: exiting due to bad IR
vex storage: T total 49760992 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==9925== at 0x7001A614: report_and_quit (m_libcassert.c:136)
==9925== by 0x7001A900: panic (m_libcassert.c:210)
==9925== by 0x7001A940: vgPlain_core_panic_at (m_libcassert.c:215)
==9925== by 0x7001A960: vgPlain_core_panic
(m_libcassert.c:220)==9925== by 0x7002ED88: failure_exit
(m_translate.c:487)
==9925== by 0x7008716C: vpanic (vex_util.c:225)
==9925== by 0x70081DB8: sanityCheckFail (irdefs.c:2023)
==9925== by 0x70082294: tcExpr (irdefs.c:2322)
==9925== by 0x7008229C: tcExpr (irdefs.c:2280)
==9925== by 0x7008212C: tcExpr (irdefs.c:2354)
==9925== by 0x7008229C: tcExpr (irdefs.c:2280)
==9925== by 0x70082F4C: sanityCheckIRBB (irdefs.c:2406)
==9925== by 0x70085D28: LibVEX_Translate (vex_main.c:471)
==9925== by 0x7002F50C: vgPlain_translate (m_translate.c:1097)
==9925== by 0x70044D20: handle_tt_miss (scheduler.c:692)
==9925== by 0x70045458: vgPlain_scheduler (scheduler.c:864)
==9925== by 0x7005B450: thread_wrapper (syswrap-linux.c:86)
==9925== by 0x7005B584: run_a_thread_NORETURN (syswrap-linux.c:119)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==9925== at 0x10000408: main (newinstr.c:2)
PUT(0) = t46
|
|
From: Julian S. <js...@ac...> - 2006-03-02 12:26:53
|
> rldcl > rldcr > rldic > rldicl > rldicr > rldimi > srdi > --9925-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX Surely these are all 64-bit insns, so I'm not sure it's legit to run them in 32-bit mode? If these *really* didn't work we wouldn't have a working 64-bit port, since you can't get far in ppc64 land without encountering rld* of some form. J |
|
From: Paul M. <pa...@sa...> - 2006-03-02 22:39:23
|
Julian Seward writes: > Surely these are all 64-bit insns, so I'm not sure it's legit to run > them in 32-bit mode? If these *really* didn't work we wouldn't have a > working 64-bit port, since you can't get far in ppc64 land without > encountering rld* of some form. There's a wrinkle here. You are correct that they are 64-bit instructions, but 64-bit PPC processors allow you to execute 64-bit instructions in 32-bit mode. The 32-bit mode bit has only two effects: addresses are truncated to 32 bits, and the setting of CR0 by the record form of various instructions (i.e. the form with a "." on the end) is done based on the 32-bit result rather than the 64-bit result. A further wrinkle is that when a signal handler is invoked in a 32-bit process, only the bottom 32 bits of each register are saved in the stack frame by the Linux kernel and restored when the signal handler returns. Thus it *is* possible to use 64-bit instructions in a 32-bit program if you really know what you're doing - if you know that the program will only be run on a 64-bit processor and you have masked all signals that have handlers. (I have considered making the stack frame a bit bigger and saving the top 32 bits of each register in the extra space, but I haven't implemented that yet.) Whether it's worth adding the ability for Valgrind to handle 64-bit instructions in a ppc32 program is another question, of course. I think it would be perfectly reasonable and consistent for Valgrind to take the position that in 32-bit mode it is emulating a 32-bit processor, and 64-bit instructions are illegal. Regards, Paul. |
|
From: Julian S. <js...@ac...> - 2006-03-02 22:48:25
|
> There's a wrinkle here. [..] Ah. (Urk!) Thanks for the clarification. So the obvious question is, do this ever really happen in Linux-land? By now the ppc32 front end must have chewed through hundreds of megabytes of object code without ever encountering any 64-bit insns. J |
|
From: Paul M. <pa...@sa...> - 2006-03-02 22:54:52
|
Julian Seward writes: > Ah. (Urk!) Thanks for the clarification. So the obvious question > is, do this ever really happen in Linux-land? By now the ppc32 > front end must have chewed through hundreds of megabytes of object > code without ever encountering any 64-bit insns. Sure. At present it would only happen if someone deliberately wrote assembler code to do it. Gcc compiling for a ppc32 target will never generate 64-bit instructions AFAIK. So no, it doesn't ever actually happen that I know of. (Of course, Murphy's law dictates that someone will pop up now and say "yes I do that in my HPC app and I really need to be able to Valgrind it". :) Paul. |