| Summary: | (wine xsavec64) vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | John Reiser <jreiser> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | austinenglish, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.19.0 | ||
| Target Milestone: | --- | ||
| Platform: | PCLinuxOS | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Hacked and reduced test case based on wine/dlls/ntdll/unix/signal_x86_64.c | ||
|
Description
John Reiser
2022-11-15 03:27:22 UTC
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' ;)). |