autorun_exit_tests built its own path from argv[0] and
windows_dependency_diagnostics_tests from GetModuleFileNameA. Both are in
the ANSI code page on Windows, but MinGW's std::filesystem::path reads a
narrow string as UTF-8, so in a build directory with characters such as
"ü" both tests stopped with "Cannot convert character sequence: Illegal
byte sequence" before testing anything (windows_diagnostic_fixture_isolation
runs the second one).
Take the path from GetModuleFileNameW on Windows. The relinker and the
generated diagnostic runner already use UTF-8 and wide APIs, so nothing
else changes.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
windows_dependency_diagnostics rewrites the fixture images right after the
diagnostic runner exits. The runner ends with an unhandled RaiseException of
STATUS_DLL_NOT_FOUND, and Windows fault handling keeps the exited process's
image files open for a short time after its handle is signaled: on Windows 11
22621 the Restart Manager names the exited runner as the holder and the file
opens 37 to 153 ms later. The rewrite then fails with ERROR_SHARING_VIOLATION,
and the final removal of the fixtures with access denied. Retry opening a
fixture while it fails with a sharing violation and the removal while it fails
with access denied, for at most 10 s each; every other failure still fails the
test at once.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
AnyPS5 exports some libkernel functions, such as __error, from
libc.prx, which libkernel.prx links. On Linux they resolve through that
dependency. On Windows, the import stubs search only the listed
modules, and libc.prx was listed only when libSceLibcInternal.prx was
needed. A PS4 homebrew that needs libkernel.prx but no C library (the
OpenOrbis graphics sample) failed with "unresolved ELF import
9BcDykPmo1I". libc.prx is now also listed when libkernel.prx is needed.
PS5 executables need libSceLibcInternal.prx and convert unchanged.
When a relinked executable fails to load a staged module, the dependency
diagnostics routine maps the same path as an image resource to walk its
imports. If that mapping failed it printed only "FAIL: dependency
diagnostics Windows API failed". The log then did not say whether the
staged module itself (libs\libSceRegMgr.prx in #4720) was absent or was
not a Windows image, and a module reached through another module's
imports was not named at all.
The register routine now reads GetLastError when LoadLibraryExW fails.
ERROR_FILE_NOT_FOUND and ERROR_PATH_NOT_FOUND print "dependency module
not found", ERROR_BAD_EXE_FORMAT prints "dependency module is not a
Windows PE image"; both name the module path, its importer and the
chain from the executable, like the existing missing-module report.
Other errors keep the generic message. An API set contract that
LoadLibraryExA reports as ERROR_MOD_NOT_FOUND now gets the
missing-module report too.
Refs #4720
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The --windows-diagnostics walker looked up modules and directories with
GetModuleHandleA, LoadLibraryExA, GetFileAttributesA,
GetModuleFileNameA and GetSystemDirectoryA, so under a directory outside
the ANSI code page it failed with "dependency diagnostics Windows API
failed" instead of naming the missing dependency.
Keep the walker's paths in UTF-8 and convert them at the Windows API
calls, which now use the wide functions. The entry stub passes it, and
prints, its paths as UTF-8 instead of the ANSI code page. The dependency
diagnostics test now builds its fixtures under a non-ASCII directory.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
