Created attachment 153757 [details] Hacked and reduced test case based on wine/dlls/ntdll/unix/signal_x86_64.c SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Valgrind complains "unhandled instruction bytes" when running wine (the environment for running Microsoft Windows apps on Linux). STEPS TO REPRODUCE 1. gcc -c wine_syscall_dispatcher.S ## attached; simplified and hacked from wine/dlls/ntdll/unix/signal_x86_64.c 2. ld wine_syscall_dispatcher.o ## totally bare executable 3. valgrind ./a.out ## valgrind-3.19.0 OBSERVED RESULT vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==345631== valgrind: Unrecognised instruction at address 0x4010ce. EXPECTED RESULT No complaint about unhandled instruction "xsavec64 0xc0(%rcx)" SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Wine source: url = git://source.winehq.org/git/wine.git commit a8c1d5c108fc57e4d78e9db126f395c89083a83d (HEAD -> master, origin/master, origin/HEAD) Date: Mon Nov 14 10:57:50 2022 -0600 Based on mailing list message "Re: [Valgrind-developers] valgrind: Unrecognised instruction error" from mahin.pandya@actian.com; posted Tue, 1 Nov 2022 10:31:05 +0000
Doc for the opcode https://hjlebbink.github.io/x86doc/html/XSAVEC.html Presumably this needs to be added to guest_amd64_toIR.c around line 14603 between the case statements for 0xC6 and 0xD1.
Further investigation reveals that this bug may be invalid. Also, the original poster on the [valgrind-developers] mailing list omitted or did not emphasize important details. First, the OP used valgrind-3.15.0 (valgrind/focal-updates,now 1:3.15.0-1ubuntu9.1 amd64) which is an ancient version. The current valgrind version is 3.21; so the used version is at least 6 years old. In particular, valgrind-3.15 does not print the instruction stream bytes that correspond to an unrecognized instruction. Knowing these bytes is a great help. The OP should build valgrind-3.21 from source, then re-run. Next, the supposedly-reproducible test case "valgrind --trace-children=yes wine64 a.out.so > temp.out 2>&1" runs wine64, which requires an actual "install" of Microsoft Windows (probably version 10). This can be seen by careful examination of the temp.out when using valgrind-3.21: ===== grep Command: temp.out ==19914== Command: wine64 a.out.so ==19914== Command: /opt/wine-stable/bin/wine64-preloader /opt/wine-stable/bin/wine64 a.out.so ==19916== Command: /opt/wine-stable/bin/wineserver ==19919== Command: /opt/wine-stable/bin/wine64-preloader /opt/wine-stable/bin/wine64 C:\\windows\\syste m32\\wineboot.exe --init - - - - - grep preloader temp.out ==19914== Command: /opt/wine-stable/bin/wine64-preloader /opt/wine-stable/bin/wine64 a.out.so preloader: Warning: failed to reserve range 0000000000110000-0000000068000000 ==19919== Command: /opt/wine-stable/bin/wine64-preloader /opt/wine-stable/bin/wine64 C:\\windows\\syste m32\\wineboot.exe --init preloader: Warning: failed to reserve range 0000000000110000-0000000068000000 - - - - - grep err: temp.out 0024:err:environ:run_wineboot failed to start wineboot 40000003 ===== Because I don't have Windows installed, then most of the output from memcheck (total 7622 lines) complains about bad usage of Windows-reserved memory by ntdll.so. And because wine64 was not installed with debug symbols, then most of the tracebacks have scant information. My version of wine is: ===== $ dpkg --list | grep wine ii wine-stable 7.0.1~bullseye-1 amd64 WINE Is Not An Emulator - runs MS Windows programs ii wine-stable-amd64 7.0.1~bullseye-1 amd64 WINE Is Not An Emulator - runs MS Windows programs ii wine-stable-i386:i386 7.0.1~bullseye-1 i386 WINE Is Not An Emulator - runs MS Windows programs ii winehq-stable 7.0.1~bullseye-1 amd64 WINE Is Not An Emulator - runs MS Windows programs ===== So, the OP should 1) Build and use current valgrind-3.21. 2) Install debug symbols for wine64. 3) Realize that this use case may well be outside the domain of memcheck.
(In reply to John Reiser from comment #2) > Next, the supposedly-reproducible test case "valgrind --trace-children=yes > wine64 a.out.so > temp.out 2>&1" runs wine64, which requires an actual > "install" of Microsoft Windows (probably version 10). This can be seen by ... > Because I don't have Windows installed, then most of the output from Wine does not depend on or use native Windows installations. It _can_ use native windows DLLs in some cases, but this example doesn't use that. The 'windows binaries' seen are provided by Wine itself (windows doesn't have any executables called 'wineboot.exe' ;)).