msys2
pacman: Do strip all symbols from EXEs and DLLs
This has the effect of passing --strip-all instead of --strip-unneeded to strip, which can make installed executables a bit smaller.
For example, stripping all symbols from /mingw64/bin/gcc.exe can reduce its size from 2,351,500 to 2,344,448 (-7,052).
Microsoft documentation also suggests that there should be no symbol in PE files; see references about PointerToSymbolTable and NumberOfSymbols.
Reference: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format Signed-off-by: LIU Hao [email protected]
Is sacrificing some debugging possibilities worth 0.3% size decrease in case of GCC?
$ nm /clang64/bin/python.exe | wc -l
166
$ cp /clang64/bin/python.exe .
$ strip --strip-all python.exe
$ nm python.exe
python.exe: no symbols
Is sacrificing some debugging possibilities worth 0.3% size decrease in case of GCC?
Debug symbols are placed into .debug_* sections which are already stripped.
nm on current executables prints mostly symbols from the import table, which I think contributes too little to debugging. For example, what may __imp_EnterCriticalSection help? We can set a breakpoint on EnterCriticalSection instead.
It can be used to quickly tell whether some features of other libraries (like jit, specific compression formats) are enabled (or at least linked). It's not a huge deal for me since I mostly use LLVM toolset which allows checking import table but IIRC Binutils doesn't have such tools.
It can be used to quickly tell whether some features of other libraries (like jit, specific compression formats) are enabled (or at least linked). It's not a huge deal for me since I mostly use LLVM toolset which allows checking import table but IIRC Binutils doesn't have such tools.
objdump -p can be used to decode and print the import table. There doesn't seem to be a filter option though, it is only possible to grep the result.
Not sure if that's worth it. Does anyone know why Arch defaults to "--strip-unneeded" for libraries?
The issue is not about --strip-unneeded itself. It's all that, by definition, Windows DLLs (dynamic link libraries) are executables, not shared libraries, and they should match STRIP_BINARIES.
I think I had better propose a change to 'strip.sh' instead.
https://github.com/msys2/msys2-pacman/commit/e9ce0316ebcbddcc07d0ee0a47324d94c70ca8c7#diff-b39914dda73d12220ebef7e970cd3f7613f04113293e673f7936695a8969bc2aR204
I see, thanks (still wondering why Arch does it). The STRIP_BINARIES change makes sense I guess.
I guess if we'd have some minimal documentation in either the MSYS2 or mingw-w64 docs for how to list the imported symbols, then this is fine with me. (also fine if if it requires llvm, or links somewhere else)