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.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to