OK, thanks, I ran Valgrind 3.13.0 on a 32-bit Raspberry Pi and it worked fine. Found bugs anyway. KDE and Fedora are way off my beaten path. Oh, I see even Raspbian Stretch finally got 3.13, they had one that didn't do arm at all.
On 6/16/18, Mark Wielaard <[email protected]> wrote: > On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote: >> > Linux version 4.16.0-2-arm64 ([email protected]) (gcc >> version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27) >> >> The Valgrind was a 3.13.0 that I'd built from the distribution >> tarball, then I discovered the same version had been added (Debian >> Unstable) to the standard debs. I wanted to see Valkyrie so I did a >> make uninstall and installed Valgrind and Valkyrie from the debs. >> >> From before it broke: >> >> ==6541== Memcheck, a memory error detector >> ==6541== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >> ==6541== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright >> info >> ==6541== Command: ./cmpi2 >> ==6541== >> ARM64 front end: branch_etc >> disInstr(arm64): unhandled instruction 0xD5380000 >> disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000 >> ==6541== valgrind: Unrecognised instruction at address 0x4014e2c. >> ==6541== at 0x4014E2C: init_cpu_features (cpu-features.c:72) >> ==6541== by 0x4014E2C: dl_platform_init (dl-machine.h:208) >> ==6541== by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231) >> ==6541== by 0x40018D3: _dl_start_final (rtld.c:414) >> ==6541== by 0x4001B57: _dl_start (rtld.c:523) >> ==6541== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) >> ==6541== Your program just tried to execute an instruction that Valgrind >> ==6541== did not recognise. There are two possible reasons for this. >> ==6541== 1. Your program has a bug and erroneously jumped to a non-code >> ==6541== location. If you are running Memcheck and you just saw a >> ==6541== warning about a bad jump, it's probably your program's fault. >> ==6541== 2. The instruction is legitimate but Valgrind doesn't handle it, >> ==6541== i.e. it's Valgrind's fault. If you think this is the case or >> ==6541== you are not sure, please let us know and we'll try to fix it. >> ==6541== Either way, Valgrind will now raise a SIGILL signal which will >> ==6541== probably kill your program. >> ==6541== >> ==6541== Process terminating with default action of signal 4 (SIGILL): >> dumping core >> ==6541== Illegal opcode at address 0x4014E2C >> ==6541== at 0x4014E2C: init_cpu_features (cpu-features.c:72) >> ==6541== by 0x4014E2C: dl_platform_init (dl-machine.h:208) >> ==6541== by 0x4014E2C: _dl_sysdep_start (dl-sysdep.c:231) >> ==6541== by 0x40018D3: _dl_start_final (rtld.c:414) >> ==6541== by 0x4001B57: _dl_start (rtld.c:523) >> ==6541== by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) > > That is https://bugs.kde.org/show_bug.cgi?id=381556 > arm64: Handle feature registers access on 4.11 Linux kernel or later > > In Fedora we carry a workaround as mentioned in comment #1: > https://bugs.kde.org/show_bug.cgi?id=381556#c1 > > But this really needs someone who knows what the various HWCAP flags > really mean on arm64 and which ones we should/shouldn't mask to > indicate what instructions valgrind/VEX emulates. > > Cheers, > > Mark > -- ------------- No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
