On 18 August 2015 at 17:19, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
>> On 17 August 2015 at 20:53, Jordan Justen <jordan.l.jus...@intel.com> wrote:
>> > On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
>> >> MinGW generates PE/COFF not ELF, so much of the linker command line is
>> >> different, and it really deserves a toolchain of its own
>> >
>> > Why does it deserve a toolchain of its own if the other toolchain
>> > produces better code? Why should EDK II care about using the different
>> > linker path if it isn't the best recommended way to build images?
>> >
>> By the same logic, why on earth do we insist on retaining support for
>> GCC44 and GCC45?
> 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. Having a LLP64 toolchain
under Linux is nice, though, if only for test coverage

> Personally, I would not mind deprecating GCC44, but the biggest
> question I would have is what toolchains do the latest UDK releases
> claim to support.
> We also have the issue that every time I ask about deprecating a
> toolchain, Larry looks at me like I'm crazy. :)

Well, perhaps he can chime in and explain his motivation behind this?
At some point, we need to start removing things, surely. Larry just
has a higher tolerance for pain :-)

>> Note that it is not about the linker path, but about the options that
>> we pass, for instance to get 4 KB section alignment. MinGW does not
>> need a linker script for this, you can simply set --section-alignment
>> and --file-alignment on the command line.
>> As for the PE/COFF support: if you are incorporating PE/COFF binary
>> static libraries into your build, you need a native PE/COFF toolchain.
> Is this something we want to support?

Perhaps not

>> But in general, I think the ELF to PE/COFF conversion is not the most
>> elegant step in the build, and I would prefer to avoid it if possible
>> (only, there is no PE/COFF support in the GNU tools for ARM or
>> AARCH64)
> It is doing a better job than any other GCC based option we have.
> Certainly LTO will be a big change for our GCC based builds. If
> somehow LTO support is finally integrated into EDK II and manages to
> directly produce a PE/COFF image easily on Linux, then I don't think
> ELF is needed.

Yes, that is another thing to consider.

All in all, I think we agree that it would be useful to get rid of as
much cruft as we can, and my cleanup is intended to reduce the
maintenance burden of the GCC4x series that we want to keep. I am
perfectly happy getting rid of ELFGCC, CYGGCC and even UNIXGCC if we
can come up with a reasonble replacement.
edk2-devel mailing list

Reply via email to