Re: [Valgrind-users] Is there a Valgrind that knows arm64/aarch64?

[Alan C. <ala...@gm...>]

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 <ma...@kl...> wrote:
> On Sat, 2018-06-16 at 19:09 -0400, Alan Corey wrote:
>> > Linux version 4.16.0-2-arm64 (deb...@li...) (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