disInstr(ppc): unhandled instruction: 0x7E2902AC primary 31(0x1F), secondary 684(0x2AC) ==23276== valgrind: Unrecognised instruction at address 0xF72BE5C. ==23276== Your program just tried to execute an instruction that Valgrind ==23276== did not recognise. There are two possible reasons for this. ==23276== 1. Your program has a bug and erroneously jumped to a non-code ==23276== location. If you are running Memcheck and you just saw a ==23276== warning about a bad jump, it's probably your program's fault. ==23276== 2. The instruction is legitimate but Valgrind doesn't handle it, ==23276== i.e. it's Valgrind's fault. If you think this is the case or ==23276== you are not sure, please let us know and we'll try to fix it. ==23276== Either way, Valgrind will now raise a SIGILL signal which will ==23276== probably kill your program. ==23276== ==23276== Process terminating with default action of signal 4 (SIGILL) ==23276== Illegal opcode at address 0xF72BE5C ==23276== at 0xF72BE5C: ConvertAltivec32to32_prefetch (in /usr/lib/libSDL-1.2.so.0.7.3) ==23276== by 0xF710FAC: SDL_SoftBlit (in /usr/lib/libSDL-1.2.so.0.7.3) ==23276== by 0xF741BEC: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.7.3) ==23276== by 0xF7432B0: SDL_ConvertSurface (in /usr/lib/libSDL-1.2.so.0.7.3) ==23276== by 0xF745D30: SDL_DisplayFormat (in /usr/lib/libSDL-1.2.so.0.7.3)
> ==23276== Illegal opcode at address 0xF72BE5C > ==23276== at 0xF72BE5C: ConvertAltivec32to32_prefetch (in > /usr/lib/libSDL-1.2.so.0.7.3) Is it possible you could 'objdump -d' /usr/lib/libSDL-1.2.so.0.7.3 and figure out what instruction this is?
433fc: 48 00 00 e4 b 434e0 <SDL_SetTimer+0x25108> 43400: 80 1f 00 8c lwz r0,140(r31) 43404: 54 00 10 3a rlwinm r0,r0,2,0,29 43408: 7c 09 03 78 mr r9,r0 4340c: 80 1f 00 84 lwz r0,132(r31) 43410: 7d 29 02 14 add r9,r9,r0 43414: 3c 00 02 20 lis r0,544 43418: 60 00 04 00 ori r0,r0,1024 --->4341c: 7e 29 02 ac dstt r9,r0,1 43420: 80 1f 00 8c lwz r0,140(r31) 43424: 54 00 10 3a rlwinm r0,r0,2,0,29 Sorry, i have no idea what dstt is, and i have no means to find out.
But google is our friend, this page seems quite ok: http://developer.apple.com/hardwaredrivers/ve/caches.html
Laszlo, I looked at this a bit this evening and thought about fixing it. It would be nice to have a test case for it, since there are in fact a whole bunch of these cache hint insns and I suspect that if I fix this one then the program will die slightly further along from another; I would prefer to fix all the needed ones. What program were you running, on what CPU, on what Linux distro?
I don't have the machine in question, i just relayed the bugreport. program: GemRB (using SDL 1.2.11) OS: some linux machine: pegasos2 (32 bits ppc) (i've sent you a mail with a bit more details)
Fixed (trunk: vex r1709, 3_2_BRANCH vex r1710).