Windows binary includes lots of C header metadata

[lifthrasiir]

Not sure how did they end up there, but even with the simple code like fn main() {} and aggressive compilation options like -Z lto --opt-level=3 the current master gives over 18 MB of binary, of which 16 MB consists of string constants seemingly derived from C headers (e.g. "ERROR_DS_DRA_INCOMPATIBLE_PARTIAL_SET __MSABI_LONG(8464)\x00\x01\xca\n", from mingw-w64 winerror.h).

Last checked with rust nightly 0550b79 2014-05-12 00:31:52 -0700.

[alexcrichton]

Wow, this is pretty awful. This seems like a regressions, so it may be nice to pinpoint where it happened.

[alexcrichton]

Nominating, it's tough to explain we work well on windows with a wart like this.

[lifthrasiir]

objdump -h output:

q.exe:     file format pei-i386

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         000a9be8  00401000  00401000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00001d58  004ab000  004ab000  000aa000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        00008fa4  004ad000  004ad000  000abe00  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .eh_frame     00008a0c  004b6000  004b6000  000b4e00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000cc0  004bf000  004bf000  00000000  2**5
                  ALLOC
  5 .idata        00001274  004c0000  004c0000  000bda00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .CRT          0000001c  004c2000  004c2000  000bee00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .tls          00000020  004c3000  004c3000  000bf000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .debug_aranges 00000450  004c4000  004c4000  000bf200  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_info   000738e8  004c5000  004c5000  000bf800  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 00006829  00539000  00539000  00133200  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_line   0001f235  00540000  00540000  00139c00  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_str    00000f7d  00560000  00560000  00159000  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0005343b  00561000  00561000  0015a000  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_macro  00fe688b  005b5000  005b5000  001ad600  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_ranges 00016aa0  0159c000  0159c000  01194000  2**0
                  CONTENTS, READONLY, DEBUGGING

I really don't have any idea why .debug_macro section has such enormous garbage.

Some more information: My build environment is a stock MinGW (not MinGW-w64) with GCC 4.8.1. Not sure if this issue also occurs on MinGW-w64. I've confirmed that i686 MinGW-w64 with GCC 4.9.0 exhibits the same issue. Curiously, both environments produce a different executable but the size of .debug_macro section remains same.

[klutzy]

nightly's std also contains the blob:

$ objdump -h std-aad93cea-0.11-pre.dll 2>/dev/null | grep debug_macro -2
 17 .debug_loc    00050dcd  6f2ef000  6f2ef000  00463200  2**0
                  CONTENTS, READONLY, DEBUGGING
 18 .debug_macro  00fe688b  6f340000  6f340000  004b4000  2**0
                  CONTENTS, READONLY, DEBUGGING
 19 .debug_ranges 000164c8  70327000  70327000  0149aa00  2**0

[thestinger]

We're using the default jemalloc compilation options, which includes a high debug level (-g3) where macro expansion is tracked. I suspect this might come from there. What happens if you compile with -C link-args=-s or strip the binary?

[lifthrasiir]

@thestinger Aha, indeed. -C link-args=-s strips all debug sections. Is -g3 required for some reason, or can we live with lower debug levels?

[thestinger]

@lifthrasiir: we don't really need jemalloc debug symbols at all beyond the basics that are there without -g since we're unlikely to even find any jemalloc bugs - I just didn't override the defaults, because it wasn't a large increase in unstripped size on Linux.

[pnkfelix]

P-high, 1.0 milestone.

[emberian]

@lifthrasiir can you confirm that this is fixed now?

[lifthrasiir]

@cmr The current Windows nightly (d92926c 2014-05-16 01:06:25 -0700) does not include the relevant commit yet. I'll check it as soon as the nightly is updated.

[lifthrasiir]

@cmr Okay, I've confirmed that this is fixed as of 8befaba 2014-05-17 01:01:22 -0700.

[emberian]

Sweet, thanks!

On Sat, May 17, 2014 at 7:43 AM, Kang Seonghoon notifications@github.51.alwrote:

@cmr https://github.com/cmr Okay, I've confirmed that this is fixed as
of 8befaba 2014-05-17 01:01:22 -0700.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14144#issuecomment-43408698
.

http://octayn.net/