Tested with kernel v4.12, valgrind crashes when trying to check for memory leaks: # valgrind --leak-check=yes ../test ==23307== Memcheck, a memory error detector ==23307== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==23307== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==23307== Command: ../test ==23307== ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380001 disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0001 ==23307== valgrind: Unrecognised instruction at address 0x4015734. Root cause is missing support for reads of MDIR_EL1
I will provide a patch
Created attachment 111541 [details] Iplements "mrs <reg>, mdir_el1" for VEX aarch64
Hi; your patch consistently typos the register name -- it is MIDR_EL1 (for Main ID Register). This register is only accessible at EL1 in hardware, though -- I guess your host kernel is emulating accesses to it? Are there other ID register accesses that also now need to be emulated in valgrind because the kernel passes them through to userspace?
(In reply to Peter Maydell from comment #3) > Hi; your patch consistently typos the register name -- it is MIDR_EL1 (for > Main ID Register). > Uups, thanks for noting. > This register is only accessible at EL1 in hardware, though -- I guess your > host kernel is emulating accesses to it? Are there other ID register > accesses that also now need to be emulated in valgrind because the kernel > passes them through to userspace? I'll have to investigate further on this. I'll update the after I can confirm that we only need MIDR access, or I'll add the necessary parts as well.
the following system registers are emulated by the kernel: MIDR_EL1 MPIDR_EL1 REVIDR_EL1 ID_AA64PFR0_EL1 ID_AA64PFR1_EL1 ID_AA64ZFR0_EL1 ID_AA64DFR0_EL1 ID_AA64DFR1_EL1 ID_AA64AFR0_EL1 ID_AA64AFR1_EL1 ID_AA64ISAR0_EL1 ID_AA64ISAR1_EL1 ID_AA64MMFR0_EL1 ID_AA64MMFR1_EL1 ID_AA64MMFR2_EL1 I have a patch which just puts faked values into the registers in guest_arm64_toIR.c But I wonder if we would need to actually provide the real values, as this may have influence on the program flow of the code under inspection. The registers give information about the underlying HW, like manufacturer, but also about which HW enhancements are present. Is my assumption correct, that we will need to provide the host values of this registers? Can anyone give guidance in which file/data structure this should be done.
I think you were already told on IRC when you asked that it should provide results which reflect the capabilities of the emulated environment, which in at least some cases is likely to mean not passing on host values.
Created attachment 112966 [details] implementation of system register emulation Emulate all system register accesses. Return only the bits that are supported by the emulation environment.
Created attachment 113113 [details] Implement emulated system registers. Fixes #392146. Updated version of the patch. I flip the registers of the bits which are not supported in the emulation environment in the dirty helper. Following the example of amd's cpuid.
Please provide some feedback about the patch.
any comments on that?
Julian, Peter, any comments on this patch?
*** Bug 482013 has been marked as a duplicate of this bug. ***
Do you have any tests for this?
I used to have a test for this, but I lost that over the last 6 years. But under "Implementation" https://bugs.kde.org/show_bug.cgi?id=482013 gives a code snipped that can be easily used to create a test.
Well it's time for me to look at this again. I just tried to run Firefox on FreeBSD under Valgrind and I got ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380609 disInstr(arm64): 1101'0101 0011'1000 0000'0110 0000'1001 ==2219== valgrind: Unrecognised instruction at address 0xdfa7880. ==2219== at 0xDFA7880: SkCpu::CacheRuntimeFeatures() (in /usr/local/lib/firefox/libxul.so)
And the patch seems to work, with the patch FF proceeds until it hits a SIGBUS (which is what I was looking for). I'll look at it in more detail.
The Linux kernel documents which ID registers and which fields in those registers it exposes here: https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt . Does FreeBSD expose the same set, or a different set?
(In reply to Peter Maydell from comment #17) > The Linux kernel documents which ID registers and which fields in those > registers it exposes here: > https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt . > Does FreeBSD expose the same set, or a different set? I don't know of any such document. I expect that they are similar since FreeBSD has a linux compatibility layer and it sets possibly different HWCAPs for FreeBSD apps and for Linux apps running under the compat layer.
*** Bug 450203 has been marked as a duplicate of this bug. ***
Created attachment 168951 [details] Attachment from 466732
*** Bug 466732 has been marked as a duplicate of this bug. ***