[PATCH] bfd: fix filename encoding for Win32
Cyano Hao
c@cyano.cn
Mon Mar 2 10:05:07 GMT 2026
> ... there may not be a single, uniform code page that we can use. Which
> effectively looks to mean that case 5 needs handling, one way or another.
I agree. GCC writes UTF-8 filenames (source paths in debugging info, etc.);
Debug Adapter Protocol is JSON-based and born to be UTF-8, ... Everything in
a toolchain is migrating from legacy code page to UTF-8.
The best practice about encoding for cross-platform app is to use consistent
internal encoding (undoubtedly UTF-8 for Binutils and GDB), and explicitly
convert from/to UTF-16 for Win32 API interops.
I have tried injecting UTF-8 manifest to all tools so everything is UTF-8 on
Windows 10 1903+. And now I am trying a new way -- replacing "ANSI" API symbols
in MinGW's import libraries (libkernel32.a, libucrt.a, etc.) with thunks that
reinterpret 'char *' arguments as UTF-8 strings and forward them to "wide" APIs
with conversion -- reflecting the best practice. [1]
The results are impressive. Almost all problems about encoding are gone, with
no or minimal changes [2] to the codebase. The remaining problem is that
porting this solution to other MinGW distributions is not trivial.
I wish one day the best practice can be adopted by Binutils and GDB, and all
other tools in the toolchain.
But for now, I believe using 'CP_ACP', along with the previous change that
fixes path translation [3], is the practical solution. This solution has been
deployed in MinGW Builds and MinGW Lite for years. It does fix path-related
compilation failures, and not break anything else.
[1] MinGW Lite: https://github.com/redpanda-cpp/mingw-lite
UTF-8 manifest for GCC <= 15; UTF-8 thunk for GCC 16.
[2] For example, replacing GetProcAddress() with direct reference.
[3] bfd: correct dir separator conversion for Win32: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3f89802f207adad4f2f0b8e0f60c44d77727af42
More information about the Binutils
mailing list