[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 --- Comment #17 from Peter Maydell --- 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? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 Peter Maydell changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #7 from Peter Maydell --- It seems a bit confusing to me that a function named foo_assert() doesn't do an assert()... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414268] Enable AArch64 feature detection and decoding for v8.x instructions (where x>0)
https://bugs.kde.org/show_bug.cgi?id=414268 --- Comment #15 from Peter Maydell --- The closest thing to single-source-of-truth is the architectural ID registers, which these days a Linux kernel will make available to userspace via trap-and-emulate and which presumably Valgrind does or should provide to its guest: https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.rst There's a hwcap that tells you if those are emulated for you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414268] Enable AArch64 feature detection and decoding for v8.x instructions (where x>0)
https://bugs.kde.org/show_bug.cgi?id=414268 --- Comment #7 from Peter Maydell --- Your logic attempting to identify v8.1, v8.2, etc isn't right. For instance: + /* Must be at least v8.2 if DC CVAP instruction available. */ + if (have_dpbcvap) +SET_VEX_ARM64_ARCHLEVEL(vai.hwcaps, VEX_HWCAPS_ARM64_V82); It's true that if you are v8.2 or better then DC CVAP is present, but this does not mean the converse (that if DC CVAP is present then you are v8.2). It is valid for a v8.1 implementation to provide this feature. I still think it would be better not to try to identify and base anything on v8.1 vs v8.2 vs v8.3...chances are really high that if some code is using "is this v8.1 ?" as a condition on something then that code is wrong, because it should be checking for a more specific feature field (or it will behave incorrectly on hardware which provides that feature without necessarily being the v8.x version where that feature became mandatory, or whatever). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414268] Enable AArch64 feature detection and decoding for v8.x instructions (where x>0)
https://bugs.kde.org/show_bug.cgi?id=414268 Peter Maydell changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #4 from Peter Maydell --- In the attachment of comment #2, this looks odd: + #define ID_AA64ISAR0_RDM_MASK 0x1 The ID register fields are all 4 bits wide, so looking at just the least significant bit will produce wrong answers if in future field value 2 is defined. The right way to test fields in these ID registers is to look at the entire 4-bit number and test that it is greater than or equal to the value representing the feature you're looking for. (See D13.1.3 "Principles of the ID scheme for fields in ID registers" in the v8A Arm ARM.) For A-profile my recommendation is as far as you possibly can to avoid having any "is this v8.1?" or "is this v8.2?" tests and instead to stick strictly to "is feature X present?". The architecture permits a v8.x implementation to include any arbitrary set of v8.(x+1) features as well, and pretty much everything has an ID register feature field you can check for, so it works better to just look at those. (FWIW QEMU's emulation does not need v8.1, v8.2, etc feature flags so I would be surprised if valgrind needed to do anything based on the architecture point version.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369509] ARMv8.1-a LSE instructions are not supported
https://bugs.kde.org/show_bug.cgi?id=369509 Peter Maydell changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #8 from Peter Maydell --- Feature identification via SIGILL is definitely not recommended for either 32-bit or 64-bit Arm. There are cases where it will give you the wrong answer (eg if the hardware supports the instruction but support is disabled by the kernel because of some erratum or because the kernel has had support compiled out). You have two recommended methods of detection: (1) hwcaps; or (2) for 64-bit only, you can directly access the ID registers via MRS and rely on the kernel to emulate this as documented in https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt. (You might want some kind of fallback for older kernels which don't support that; I forget when it came in.) PS: does valgrind implement 'emulate the kernel emulation of those ID registers' for an arm64 guest binary? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396001] unhandled instruction: 0xEC51 0x0F1E; ARMv7 libcrypto 'mrrc'
https://bugs.kde.org/show_bug.cgi?id=396001 Peter Maydell changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #1 from Peter Maydell --- 0xEC510F1E is actually "mrrcp15,1,r0,r1,c14", which is an access to CNTVCT. I think this is a duplicate of #344802. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395777] disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c)
https://bugs.kde.org/show_bug.cgi?id=395777 Peter Maydell changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #2 from Peter Maydell --- The last four of those are all in 0xe7fxxxfx, which is the UDF always-undefined insn. The only "handling" needed here would be suppressing the warning (probably reasonable, since these undefined insns tend to get used by JITs and the like for various clever tricks). 0xe611 is a random not-yet-allocated encoding in the "parallel arithmetic" instruction class. Google claims it was "used by gdb 4.x"... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 --- Comment #13 from Peter Maydell --- Based on a quick grep of guest_arm64_toIR.c to see what insns it has, I think Valgrind should be setting the hwcap bits AES, PMULL, SHA1, SHA2, CRC32, FP, ASIMD and making the rest zero. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 --- Comment #12 from Peter Maydell --- Sorry about the bogus kernel-source link -- I made the mistake of linking to the 'latest' version, which of course is a moving target so the line number reference gets out of date. Here's the link to a specific kernel version: https://elixir.bootlin.com/linux/v4.17.2/source/arch/arm64/kernel/cpufeature.c#L1221 which has an array with an entry for each hwcap, so eg HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_PMULL), says that the PMULL hwcap bit is set if the AES field in the system ID_AA64ISAR0_EL1 ID register is at least 2. You can then look that register up in the Arm ARM to see that it means the PMULL hwcap should be set if we have the PMULL/PMULL2 insns (as well as the AESE/AESD/AESMC/AESIMC insns that we have for a 1 value in that ID register and which the kernel reports via the AES hwcap). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 --- Comment #11 from Peter Maydell --- The A-profile Arm ARM can be downloaded from https://developer.arm.com/products/architecture/a-profile/docs without requiring a login/clickthrough/etc. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 --- Comment #6 from Peter Maydell --- Looking back in the history, my comment #3 should have enough information for somebody who knows what instructions Valgrind implements to be able to set the hwcaps appropriately. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 --- Comment #5 from Peter Maydell --- That workaround change looks wrong to me. Surely Valgrind supports at least FP and Neon ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393036] arm: unhandled instruction: 0xEBAD 0x1BC7 (sub.w fp, sp, r7, lsl #7)
https://bugs.kde.org/show_bug.cgi?id=393036 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #1 from Peter Maydell <peter.mayd...@linaro.org> --- Where does the condition "imm5 <= 7" come from? I can't see any justification for it in the pseudocode for this insn in the v7 or v8 ARM ARM. My guess is that the incorrect condition check you've hit is the result of confusion about the pseudocode UNPREDICTABLE condition "d == 13 && (shift_type != SRType_LSL || shift_n > 3)", which restricts the permitted shifts if SP is the destination register. Prior to valgrind commit a70670d3d92f028, the condition V imposed was "rD != 15 && rN == 13 && imm5 <= 3 && how == 0", which refused shifts greater than 3 in all cases, not just those with rD == 13. Then commit a70670d3d92f028 relaxed the imm5 check to <= 5: that correctly accepts a wider shift range for the rD != 13 case, but incorrectly accepts a wider shift range if rD == 13, and continues to incorrectly not accept the full up-to-31 shift range for rD != 13. The patch you attach seems to continue down this route, just bumping the imm5 check up to 7. I think the better approach would be to actually implement the restrictions the pseudocode requires... Note also that ARMv8 is less restrictive here than ARMv7 -- v8 removes the UNPREDICTABLE constraints on R13 operations entirely for this insn. So ideally V should impose a different condition depending on what architecture version the CPU it's emulating is. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #3 from Peter Maydell <peter.mayd...@linaro.org> --- 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? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #9 from Peter Maydell <peter.mayd...@linaro.org> --- Yes, I just mean that each thread sees its own copy with the value it last wrote. On exec() a fresh process image starts out with a zero value. On fork() or clone() a new thread or process inherits the value from its parent. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #5 from Peter Maydell <peter.mayd...@linaro.org> --- For the hardware, TPIDRURW has no behaviour except that it holds what you write to it. For the Linux kernel, this register is used to provide per-thread information, and its contents are context-switched when threads are context-switched. Looks like Austin will know better than me the exact details of what happens to the value on fork/clone. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381556] arm64: Handle feature registers access on 4.11 Linux kernel or later
https://bugs.kde.org/show_bug.cgi?id=381556 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #3 from Peter Maydell <peter.mayd...@linaro.org> --- I believe there's a plan in the works to add a docs patch to the kernel for the hwcap bit meanings, but in the meantime the kernel code for them is here: http://elixir.free-electrons.com/linux/latest/source/arch/arm64/kernel/cpufeature.c#L886 and it basically defines each HWCAP in terms of what the values in the relevant fields of the architectural ID registers (ID_AA64*) need to be -- you can look those up in the ARM ARM to find their meanings. The only one not in that table I think is HWCAP_CPUID, which is the "support emulation of access to CPU ID feature registers" bit. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377966] disInstr(arm64): unhandled instruction 0xD50B7425 (dc zva,)
https://bugs.kde.org/show_bug.cgi?id=377966 --- Comment #4 from Peter Maydell <peter.mayd...@linaro.org> --- Good point -- there's no inherent reason why valgrind would need to use the same cache line size that the host is using for DC ZVA. You can just pick an arbitrary value as long as you're consistent with the value of DCZID_EL0 you report to the guest. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377966] disInstr(arm64): unhandled instruction 0xD50B7425 (dc zva,)
https://bugs.kde.org/show_bug.cgi?id=377966 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #2 from Peter Maydell <peter.mayd...@linaro.org> --- You can read the DCZID_EL0 register, which will tell you both (a) whether it's permitted to use DC ZVA and (b) the size of the cache line affected. A big.Little system will always report the same cache line size for this purpose regardless of core -- it would be impossible to use DC ZVA reliably otherwise. (There is at least one SoC with a system integration bug where it reports different values on different cores, but the fix for this is at the Linux kernel level where the kernel can check for such errata and set the register up to trap so the kernel can fix up the reported values.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377420] Valgrind is missing an armv7 instruction
https://bugs.kde.org/show_bug.cgi?id=377420 --- Comment #2 from Peter Maydell <peter.mayd...@linaro.org> --- Doh, I meant bug 344802... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377420] Valgrind is missing an armv7 instruction
https://bugs.kde.org/show_bug.cgi?id=377420 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #1 from Peter Maydell <peter.mayd...@linaro.org> --- Looks like the same as bug 344082 to me (insn is reading CNTVCT). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 376279] disInstr(arm64): unhandled instruction 0xD50320FF
https://bugs.kde.org/show_bug.cgi?id=376279 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #5 from Peter Maydell <peter.mayd...@linaro.org> --- HINT #0x7 is XPACLRI which is one of the ARMv8.3 pointer authentication instructions. This is where they went into binutils: http://www.cygwin.com/ml/binutils/2016-11/msg00103.html (which gives a helpful link to https://community.arm.com/processors/b/blog/posts/armv8-a-architecture-2016-additions if you want to know what pointer authentication is all about). Since these HINT insns all NOP on CPUs before v8.3, gcc can happily use them even if it's not specifically compiling for a v8.3 CPU. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #14 from Peter Maydell <peter.mayd...@linaro.org> --- I think the assertion about "real world code not caring" is based on some popular CPUs not having an ll/sc combination (like x86!), and so portable atomicity primitives can't assume you don't get ABA because they have to work with a lowest-common-denominator cmpxchg CPU. I think your suggestion in comment 11 about trying to autodetect this kind of core sounds extremely fragile. The architecture says "don't do this", and implementations can take advantage, including perhaps being able to make forward progress in some cases even if not in others, so you might find your autodetect test code passed but later generated code didn't. Plus on big.LITTLE you might later be running on a CPU with a different microarchitecture from the one you ran your autodetection on... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #8 from Peter Maydell <peter.mayd...@linaro.org> --- FWIW QEMU is switching to emulating atomics (including ll/sc) via a common "cmpxchg" IR operation (which is then implemented in the backend via an ll/sc loop or whatever the host CPU has). This results in not-strictly-correct behaviour (it has the ABA problem) but realworld code doesn't really care. (I don't know much of the detail as I haven't been involved in the implementation.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #2 from Peter Maydell <peter.mayd...@linaro.org> --- I don't think this is strictly speaking invocation of undefined behaviour / UNPREDICTABLE -- it just isn't guaranteed that the code sequence will make forward progress. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362934] [AsusWRT] Arm v7 illegal instruction
https://bugs.kde.org/show_bug.cgi?id=362934 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #3 from Peter Maydell <peter.mayd...@linaro.org> --- "Features : swp half thumb fastmult edsp" in the /proc/cpuinfo means no Neon, and not even any VFP -- integer only core. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian
https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #33 from Peter Maydell <peter.mayd...@linaro.org> --- (In reply to Mark Wielaard from comment #32) > valgrind should already intercept the memcmp from glibc. This one however is > in a different library libcofi_rpi.so which looks like some kind of hack to > interpose some standard libc functions. It seems this is actually preloaded > somehow. So it might be as simple as removing the preload hack when running > under valgrind? The idea would be to do something which works out of the box; otherwise you won't stop the trickle of bug reports (and probably larger set of users who just decide valgrind doesn't work without reporting a bug). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian
https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #31 from Peter Maydell <peter.mayd...@linaro.org> --- If your JIT architecture doesn't permit a QEMU-style approach I would be tempted to go with "implement SETEND to throw away JITted code and print a warning about poor performance". At the moment people trying to valgrind code that uses it find valgrind doesn't run their code at all, which you could define as infinitely slow :-) Alternatively, if valgrind could do a redirection of memcmp() in the offending .so file to its own implementation (the way it already does for a bunch of other functions) that would be a very raspi-specific hack but would cover 90%+ of the complaints I suspect (and you could combine this with the slow-SETEND implementation to handle the last 10%). I don't have a raspi though so this is all just commentary from the peanut gallery. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 322935] disInstr(arm): unhandled instruction: 0xF1010200, valgrind: Unrecognised instruction on Raspbian
https://bugs.kde.org/show_bug.cgi?id=322935 --- Comment #29 from Peter Maydell <peter.mayd...@linaro.org> --- The way QEMU's JIT handles this kind of thing is that we track each translated code block by (start PC, cpu state flags), where the flags track the subset of the CPU's current state that we've baked into the translation. One of those state flags is "is CPSR.E set?", so when we later come to check whether we've already translated a code block we won't return one that was translated assuming the "wrong" endianness. (We also use this to be able to generate code that makes assumptions about the current setting of VFP vector length and stride, Thumb condexec bits, and some other stuff that only matters for kernel-mode code emulation.) This avoids the downsides of your options (1) and (2), though it does require that you're doing lookup of code blocks by something other than raw PC, which QEMU does anyway. I agree that rpi's memset implementation is a bit weird, but on the hardware they use (ARM1176) SETEND is pretty nearly free and it turns out to be fastest. They're not going to change it now, it's more likely that the rpi1 will vanish into the mists of history first. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361726] WARNING:unhandled syscall on ppc64
https://bugs.kde.org/show_bug.cgi?id=361726 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #4 from Peter Maydell <peter.mayd...@linaro.org> --- PPC64 syscall 365 is NR_membarrier. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366464] disInstr(arm): unhandled instruction: 0xF1010200
https://bugs.kde.org/show_bug.cgi?id=366464 --- Comment #4 from Peter Maydell <peter.mayd...@linaro.org> --- (In reply to Jeffrey Walton from comment #3) > Is there a way to get Valgrind's portion of the bug tracker to return search > results that are no longer open? Or at least include the ones marked as > "won't fix"? (Does the bug tracker have a per-project configuration). The simple search box only looks for open bugs, but you can always use a more complicated search query if you want to find closed bugs too. For instance if you start at https://bugs.kde.org/query.cgi you can select Status All, Product valgrind, Words 0xF1010200, which brings up the closed bug as well as the open ones. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366464] disInstr(arm): unhandled instruction: 0xF1010200
https://bugs.kde.org/show_bug.cgi?id=366464 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #2 from Peter Maydell <peter.mayd...@linaro.org> --- 0xF1010200 is "SETEND BE". This is almost certainly the optimized-for-1176 32-bit ARM raspberry pi memcmp. See bug #322935, closed WONTFIX in 2013. (This is a silly memcmp implementation for a Cortex-A53, where SETEND is rather more expensive than it was on the 1176, so the ideal fix would be to get the OS not to use it.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366345] Dirty compile from m_libcbase.c and vgdb-invoker-ptrace.c
https://bugs.kde.org/show_bug.cgi?id=366345 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #1 from Peter Maydell <peter.mayd...@linaro.org> --- I doubt it's related, but if the CPU doesn't support the crypto extensions why are you compiling with +crypto in your -march= flags ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw
https://bugs.kde.org/show_bug.cgi?id=360425 Peter Maydell <peter.mayd...@linaro.org> changed: What|Removed |Added CC||peter.mayd...@linaro.org --- Comment #3 from Peter Maydell <peter.mayd...@linaro.org> --- (In reply to Mark Wielaard from comment #1) > I couldn't find a precise arm64 instruction encoding table This is all documented in the ARMv8 Architecture Reference Manual, which is available from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html (you'll need to fill in a form to create an account on the webserver and there may be a click-through license of some kind). -- You are receiving this mail because: You are watching all bug changes.
