05.04.2014 22:18, Michael Tokarev wrote: > 06.03.2014 04:35, Christoph Biedl wrote: [] >> # chroot /tmp/chroot/ /usr/bin/qemu-ppc-static /usr/bin/ssh-keygen >> >> Output: >> >> Invalid instruction >> NIP 6fe34874 LR 6fe34c78 CTR 6fc59508 XER 00000000 > ... >> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> FPSCR 00000000 >> Generating public/privat >> (...) >> >> Quite a surprise, the program continues to run and seems to do the >> right thing. So it might be just a visual thing, severity left at >> normal.
Actually this is not a bug per se. ssh-keygen runs two instructions: fcfid f1,f1 and vor v0,v0,v0 First is only available in ppc64 (64bit) mode, and qemu-ppc64 does not complain on it. Yet the 32bit ssh-keygen somehow tries it. The second is from altivec set, which qemu does not implement. Apparently what happens here is - ssh-keygen tries some specialized instructions and will use them if available. And if not, it will fall back to some software implementation. qemu just reports that it does not know the instruction it were asked to run, and generates a trap just like a real CPU will do. The difference with real CPU is that the CPU is silent in this case, it does nothing besides generating the trap. But qemu _also_ produces this quite scary message, because more often this happens when qemu actually misses some instruction which it _should_ implement, and from this message it can be decoded and necessary implementation added. The only possible complain to the qemu side is this extra output which it produces. Besides that, the rest works the way it should work. Thanks, /mjt > > Yeah. The same happens with 2.0.0-rc1. > > Tagging the bugreport for now. > > Thank you! > > /mjt > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
