Hi,
On Wed, 09 Dec 2020 06:15:57 +0900 =?UTF-8?Q?Marc_Dequ=C3=A8nes_=28duck=29?=
wrote:
Control: tags -1 +help
Quack,
I tried building with LTO but it does not work with problems similar to
this:
https://sourceware.org/bugzilla/show_bug.cgi?id=12762
I tried the workarounds to no avail.
I do not wish to sacrifice the hardening flags just to save some space,
knowing that's still a small amount compared to the size of most games.
Help welcome.
\_o<
--
Marc Dequènes
Hi,
I've found that the dll.so files contains debug info, which is the cause
of the large file size.
For example, /usr/lib/dxvk/wine64-development/d3d11.dll.so contains these
sections:
/usr/lib/dxvk/wine64-development/d3d11.dll.so: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0021e098 000359051000 000359051000 1000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 6410 00035927 00035927 0022 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .rdata00067c00 000359277000 000359277000 00227000 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .pdata00017b80 0003592df000 0003592df000 0028f000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .xdata00028bdc 0003592f7000 0003592f7000 002a7000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .bss 2c90 00035932 00035932 2**4
ALLOC
6 .edata00c2 000359323000 000359323000 002d 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .idata1a8c 000359324000 000359324000 002d1000 2**2
CONTENTS, ALLOC, LOAD, DATA
8 .CRT 0060 000359326000 000359326000 002d3000 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .tls 0010 000359327000 000359327000 002d4000 2**2
CONTENTS, ALLOC, LOAD, DATA
10 .rsrc 0340 000359328000 000359328000 002d5000 2**2
CONTENTS, ALLOC, LOAD, DATA
11 .reloc3798 000359329000 000359329000 002d6000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .debug_aranges 7880 00035932d000 00035932d000 002da000 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_info 07261214 000359335000 000359335000 002e2000 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_abbrev 000b2dfc 000360597000 000360597000 07544000 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_line 002524c8 00036064a000 00036064a000 075f7000 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_frame 000719e0 00036089d000 00036089d000 0784a000 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_str001521fc 00036090f000 00036090f000 078bc000 2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_loc0097bbcd 000360a62000 000360a62000 07a0f000 2**0
CONTENTS, READONLY, DEBUGGING
19 .debug_ranges 0027bbf0 0003613de000 0003613de000 0838b000 2**0
CONTENTS, READONLY, DEBUGGING
From x86_64-w64-mingw32-objdump -h
/usr/lib/dxvk/wine64-development/d3d11.dll.so)
The debug sections are the cause of the large file size, with debug_info
using more than 119 MB.
Maybe the debug size wasn't that large without LTO, but given that d3d11
is probably C++ and large, I guess this is expected to have such a large
debug info size.
Even if these are dll files, maybe a solution would be to split the debug
info into a -dbgsym package, the same way this is done on normal Linux
packages.
I've tried to replicate what dh_strip does (when autogenerating -dbgsym
packages), but with mingw's binutils.
Moving debug info in a second file works, but there is no build id.
The script in attachment will generate a .debug file from a PE executable
or DLL and will strip and add a gnu_debuglink to the original file.
Usage to test it:
$ x86_64-w64-mingw32-gcc -g test.c -o test.exe
$ ./strip_debug.sh test.exe
$ winedbg --gdb --no-start --port 2345 test.exe &
$ gdb test.exe
(gdb) target remote localhost:2345
Maybe you can use the commands in the script to generate a separate package
manually with debug info (dh_strip won't work with PE files so won't
generate -dbgsym packages automatically).
When using this script on d3d11.dll.so, I get this resulting file sizes:
original d3d11.dll.so: 137M
d3d11.dll.so: 2,9M
d3d11.dll.so.debug: 134M
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F|
strip_debug.sh
Description: application/shellscript
