Valgrind currently lacks support for the new z/Architecture instructions that were first implemented with z13. In particular: - load and zero rightmost byte (LZRF, LZRG); - load logical and zero rightmost byte (LLZRGF); - load halfword high immediate on condition (LOCHHI); - load halfword immediate on condition (LOCHI, LOCGHI); - load high on condition (LOCFHR, LOCFH); - store high on condition (STOCFH); - perform pseudorandom number operation (PPNO), with the functions PPNO-Query and PPNO-SHA-512-DRNG; - all vector facility instructions described in chapters 21-24 of the z/Architecture Principles of Operations, eleventh edition (March, 2015): - vector facility support instructions (chapter 21); - vector facility integer instructions (chapter 22); - vector facility string instructions (chapter 23); - vector facility floating point instructions. (chapter 24); - load count to block boundary (LCBB). Supporting the new vector facility instructions requires modelling the new z/Architecture vector registers. Reproducible: Always
Investigating this now, see: https://www.bountysource.com/issues/36651231-s390x-new-z13-instructions-not-implemented Are there some specific KDE binaries, perhaps distributed with Debian s390x, that have the missing instructions compiled in or are these instructions emitted with just about every gcc/g++ binary on s390x Linux?
(In reply to Zack Brdge from comment #1) > Are there some specific KDE binaries, perhaps distributed with Debian s390x, > that have the missing instructions compiled in or are these instructions > emitted with just about every gcc/g++ binary on s390x Linux? Binaries in current distributions usually do not contain any of the new instructions, since they are compiled for compatibility with older systems. One exception is the glibc, which contains performance-optimized z13 variants of some selected functions. Those are dynamically activated via ifunc if the hardware capabilities (HWCAP) indicate vector support. Since Valgrind will currently mask off vector support from HWCAP, glibc will fall back to the non-optimized variants when running under Valgrind. However, gcc and llvm may generate many of the new instructions when compiling for z13 or higher, i.e., when the command line option "-march=z13" is specified. A resulting binary can then not be debugged under Valgrind.
Andreas: thank you for the reply. This was very helpful. As I expected, I've pushed my timeframe back a couple more months. I'm not actually sure how long it will take to complete this, but I'm adding some more information here for anyone else approaching this without much background on z/Architecture and/or Valgrind with respect to s390. Much of my time so far has just been spent getting up to speed on how to test these instructions, the issue being that some of the Linux distributions and emulators encountered don't actually support z13 instructions in question. I do not believe hercules 3.x nor hyperion (hercules 4.x) have integrated support for any of the new z13 instructions either yet, so that appears to be a path to avoid. In particular, as far as I'm aware, both of the newest RHEL and SUSE default distributions on IBM's LinuxONE system *do not yet support* z13. The version of SUSE I'm working with right now having uname: > Linux valgrindtest 3.12.59-60.45-default #1 SMP Sat Jun 25 06:19:03 UTC 2016 (396c69d) s390x s390x s390x GNU/Linux Apparently, the 139 new vector instructions in z13 weren't added to the Linux Kernel until 3.18. Maybe this is different if running Ubuntu on IBM's cloud infrastructure. I haven't checked yet. My plan is just to compile a new kernel and try to reboot into it. So for example, the following test program will fail with an illegal instruction on the 3.12 kernel above. GCC 4.8 does not appear to support -march=z13, though binutils apparently does, so I built it with: "as -m64 -march=z13 test.S -o test.o && ld test.o -o test": > sys_exit=1 > .section .data > .section .text > .global _start > .section .bss > _start: > vgbm 16,0 # <-- fails here > la 1,sys_exit # exit syscall > la 2,0 # exit code should be 0 > svc 0 # call the kernel As for Valgrind, there are a couple files of immediate interest in the source tree and good starting points for working on this: 1) ./docs/internals/s390-opcodes.csv 2) ./include/vki/vki-s390x-linux.h Which should be pretty self explanatory. Hopefully, I'll have more time to update this with an actual patch soon as this is a fascinating platform.
Is anyone work on this issue?
(In reply to neverscaired from comment #4) > Is anyone work on this issue? neverscaired, I started working on this via bountysource, but it has since fallen off my radar. So I can tell you that I am *not* currently working on it and will remove myself from the bountysource listing. Hopefully you'll get something from the notes I left -- in particular if you're developing on IBM's public cloud s390x you'll need to pay close attention to the Linux kernel version in whichever distro you're running and you may need to recompile the Kernel to get access to the new vector instructions.
(In reply to neverscaired from comment #4) > Is anyone work on this issue? Currently I am *not* working on this issue, but I plan to start soon, if nobody else picks it up.
Andreas, what is the current status here? Could you test the latest Valgrind from SVN upstream?
(In reply to Ivo Raisr from comment #7) > Andreas, what is the current status here? I still haven't started working on this. And it seems that nobody has picked it up either. > Could you test the latest Valgrind from SVN upstream? Sure. It doesn't work. No wonder -- since it's not implemented yet.
I am working now on this issue (creating tests is first of all, see https://github.com/barkovv/valgrind/issues/1)
To make this item more manageable, I've split it up in multiple Bugs and made this one dependent on them.
(In reply to Andreas Arnez from comment #10) > To make this item more manageable, I've split it up in multiple Bugs and > made this one dependent on them. Actually, tracking becomes simpler without this extra Bug. The various parts of this work item are now tracked by Bugs 385408, 385409, 385410, 385411, and 385412. Thus drop this one.