https://bugs.kde.org/show_bug.cgi?id=504648
--- Comment #12 from JojoR <[email protected]> --- (In reply to Mark Wielaard from comment #9) > (In reply to JojoR from comment #8) > > (In reply to Mark Wielaard from comment #5) > > > We probably need a real implementation of riscv_hwprobe see > > > https://bugs.kde.org/show_bug.cgi?id=503253 > > > Are there other ways programs check the availability of riscv extensions? > > > Are there auxval settings for example? > > > Or do programs probe by just trying to execute some extension instruction? > > > > I make a patch for determining hardware capability > > by trying to execute extension instruction. > > > > Please review these :) > > [PATCH 5/5] riscv64: Add zfh extension support: determine hardware > capability > > Looks good. So now valgrind can detect if the hardware supports and we need > to change the #ifdef __riscv_zfh checks in libvex with checks against having > VEX_HWCAPS_RISCV_Zfh in hwcaps. > Updated patch "0005-riscv64-Add-zfh-extension-support-determine-hardware.patch" I will check Zfh feature before calling disassembler function "dis_RV64Zfh" > Then if a program uses the same kind of illegal instruction check this > should work. But if the program uses the riscv_hwprobe syscall it won't. So > we still need an implementation of > https://bugs.kde.org/show_bug.cgi?id=503253 > It looks like an independent feature ? I will see that later. > For the testcases you will have to add something like > ./tests/x86_amd64_features.c so you can add it to the vgtests as e.g. > prereq: test -x float16 && ../../../tests/riscv64_features riscv64-Zfh > > And you should really check for __riscv_zfh in a configure check, so that > you only build the tests if the compiler knows about it. Updated patch "0004-riscv64-Add-zfh-extension-support-new-port-specific-.patch" Like other arch, I add "prereq" condition in execution for Zfh feature. -- You are receiving this mail because: You are watching all bug changes.
