[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