On 19 August 2015 at 09:53, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 18 August 2015 at 22:29, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> On 18 August 2015 at 22:03, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >>> On 18 August 2015 at 19:35, David Woodhouse <dw...@infradead.org> wrote: >>>> On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote: >>>>> On 18 August 2015 at 17:19, Jordan Justen <jordan.l.jus...@intel.com> >>>>> wrote: >>>>> > Last time I checked, GCC44 ~ GCC49 all produced images roughly in the >>>>> > same ball park size-wise. UNIXGCC produced much larger images because >>>>> > it could not strip unused functions/data. >>>>> >>>>> Yeah, that is still true, unfortunately. >>>> >>>> Is it really still true? >>>> >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14 >>>> >>>> If the patch that Nick committed to fix this *isn't* working, please >>>> add a comment telling him that :) >>>> >>> >>> I did a quick test with the gdb-7.10-branch of binutils-gdb, and while >>> it does make some difference, it is still not sufficient >>> >>> Building OvmfX64 in RELEASE mode gives me >>> >>> Before: >>> the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000 >>> >>> After: >>> the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000 >>> >>> where GCC/ELF obviously produces something < 0xcc000 >>> >> >> I had mistakenly omitted the -ffunction-sections -fdata-sections >> switches, but adding those makes it even worse >> >> the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000 >> >> so there is definitely something dodgy going on here. >> > > I managed to make this work by also adding the > -fno-asynchronous-unwind-tables option. It appears that > (unsurprisingly) the unwinding info is preventing code from being > pruned. > > So with -Os -ffunction-sections -fdata-sections > -fno-asynchronous-unwind-tables, we get even better results than > GCC49, since we can actually turn on size optimization for MinGW. > On GCC49, we can only enable optimization if we also enable > -maccumulate-outgoing-args, which -according to the man page- results > in a notable increase in code size. (I assume this is the reason we > don't optimize the GCC49 X64 builds at all) > > If I just look at VolInfo of the FVMAIN_COMPACT.Fv generated by each > build (UNIXGCC with mingw 4.9 vs GCC49), I get 767 KB for MinGW for > the file length of the first embedded FV, where GCC49 takes up 794 KB. > Maybe not spectacular, but more than significant.
As it turns out, the -mcmodel=large we use for GCC4x/X64 is causing much of the bloat here. If I remove it, the GCC49 build shrinks to 751 KB (Again, the size of the first FV. Note that this is compressed size, but it is relevant nonetheless) Does anyone remember why we use that? My build runs fine without it _______________________________________________ edk2-devel mailing list email@example.com https://lists.01.org/mailman/listinfo/edk2-devel