https://bugs.kde.org/show_bug.cgi?id=383010
Olivier Huber <oli.hu...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |oli.hu...@gmail.com
--- Comment #112 from Olivier Huber <oli.hu...@gmail.com> ---
(In reply to Michał Dec from comment #107)
> (In reply to Mark Wielaard from comment #103)
> > Normally glibc uses ifuncs which check whether avx512 is available. Since
> > valgrind doesn't advertise avx512 being available glibc should normally not
> > use it. Do you know why it does? How is your glibc build? What error do you
> > see under valgrind?
>
> > Do you know why it does?
>
> I don't know, that's why I'm asking. From what I understand in my next
> answer, I should disable multiarch and recompile glibc without AVX-512. But
> I don't wanna reboot for nothing. I have an AM5 system and I really hate
> rebooting it, it takes forever.
>
> > How is your glibc build?
>
> At the time of writing, this is the recipe for building the version of glibc
> considered stable on amd64:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.39-r6.
> ebuild?id=9adf7dbf124f3810b77c28a04f7dd7995d238854
> The flags I have enabled in my build are pretty common ones: cet multiarch
> ssp stack-realign
>
> > What error do you see under valgrind?
>
> ```
> vex amd64->IR: unhandled instruction bytes: 0x62 0xD2 0xFD 0x28 0x7C 0xC0
> 0x48 0x89 0xC6 0x31
> vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
> vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
> ==28914== valgrind: Unrecognised instruction at address 0x484f0cf.
> ==28914== at 0x484F0CF: memset (vg_replace_strmem.c:1390)
> ==28914== by 0x4A47F71: memset (string_fortified.h:59)
> ==28914== by 0x4A47F71: CRYPTO_zalloc (mem.c:224)
> ==28914== by 0x4A5A220: CRYPTO_THREAD_lock_new (threads_pthread.c:684)
> ==28914== by 0x4B330FC: do_rand_init (rand_lib.c:51)
> ==28914== by 0x4B330FC: do_rand_init_ossl_ (rand_lib.c:48)
> ==28914== by 0x4DE340F: __pthread_once_slow (pthread_once.c:116)
> ==28914== by 0x4DE3526: pthread_once@@GLIBC_2.34 (pthread_once.c:143)
> ==28914== by 0x4A5A31C: CRYPTO_THREAD_run_once (threads_pthread.c:786)
> ==28914== by 0x4B33B4C: RAND_get_rand_method (rand_lib.c:190)
> ==28914== by 0x4B347DC: RAND_bytes_ex (rand_lib.c:368)
> ==28914== by 0x10996B: (a function that calls RAND_bytes) (src.c:191)
> ==28914== by 0x109427: main (src.c:516)
>```
I am also on Gentoo and I have the same issue since I got my machine with an
AMD Ryzen 7 7840U.
I didn't really want to rebuild glibc with AVX-512 disabled just for valgrind.
I tried disabling AVX512 support by using `glibc.cpu.hwcaps`, to no avail.
The error I get is
===============================================================================
$ valgrind ls
==28786== Memcheck, a memory error detector
==28786== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==28786== Using Valgrind-3.23.1.GIT and LibVEX; rerun with -h for copyright
info
==28786== Command: ls
==28786==
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7F 0x48 0x7F 0x84 0x24
0x30 0x0 0x0
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==28786== valgrind: Unrecognised instruction at address 0x401d9cb.
==28786== at 0x401D9CB: _dl_start (rtld.c:563)
==28786== by 0x401C987: ??? (in /lib64/ld-linux-x86-64.so.2)
==28786== Your program just tried to execute an instruction that Valgrind
==28786== did not recognise. There are two possible reasons for this.
==28786== 1. Your program has a bug and erroneously jumped to a non-code
==28786== location. If you are running Memcheck and you just saw a
==28786== warning about a bad jump, it's probably your program's fault.
==28786== 2. The instruction is legitimate but Valgrind doesn't handle it,
==28786== i.e. it's Valgrind's fault. If you think this is the case or
==28786== you are not sure, please let us know and we'll try to fix it.
==28786== Either way, Valgrind will now raise a SIGILL signal which will
==28786== probably kill your program.
==28786==
==28786== Process terminating with default action of signal 4 (SIGILL)
==28786== Illegal opcode at address 0x401D9CB
==28786== at 0x401D9CB: _dl_start (rtld.c:563)
==28786== by 0x401C987: ??? (in /lib64/ld-linux-x86-64.so.2)
==28786==
==28786== HEAP SUMMARY:
==28786== in use at exit: 0 bytes in 0 blocks
==28786== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==28786==
==28786== All heap blocks were freed -- no leaks are possible
==28786==
==28786== For lists of detected and suppressed errors, rerun with: -s
==28786== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
===============================================================================
It's unclear that there is a way to not execute the instruction. The line
reported by valgrind is
https://github.com/bminor/glibc/blob/5c06c6e0b5078ffb0aa0c09bac79f086145e0897/elf/rtld.c#L563
Thanks for everyone working on this. Is it possible to develop a workaround to
be able to execute valgrind on a system where the glibc code contains AVX512
instructions? It's easy to compile the code begin developed without AVX512,
it's different to recompile the whole system just for the sake of using
valgrind.
--
You are receiving this mail because:
You are watching all bug changes.
