Toolchain question

Toolchain question

[valerij zaporogeci]

Sorry for the really dumb question, but I wanted to ask you. What
compilers/tools you are using for building your UEFI/PI implementation
on arm (both aarch32 (armv7) and aarch64)? And generally, is there a
toolchain (available for downloading (not necessarily free) in binary
form) for the arm architecture able to make PE/COFF images natively,
without freaking translation from elf?

Re: Toolchain question

[Michael Zimmermann]

Hi,

I assume that you are using linux because you're talking about ELF files.
MinGW may be able to compile PE images in Linux but tbh there's no reason
for that and the "freaking" translation is actually a pretty good
implementation and works very well.

As for the kind of toolchain to use: there's always (at least) two types:
bare metal toolchains(arm-eabi,arm-none-eabi, aarch64-elf), and the ones
with a OS ABI(androideabi, linux-gnueabi,linux-gnueabihf, ...). While
unlike other bootloader/kernel projects EDK2 seems to work with all of them
I can only recommend using the bare metal variants.

For ARM and AArch64 I recommend using linaro's latest stable release(5.3 at
the time of writing):
http://www.linaro.org/downloads/
sometimes the website is out of date and you can go here directly:
https://releases.linaro.org/components/toolchain/binaries/

I've also CC'ed the Arm maintainers so you'll actually get answers unlike
me when I asked the same question about a year ago ;)

Thanks
Michael


On Tue, Aug 9, 2016 at 2:29 AM, valerij zaporogeci <vlrzprgts@gmail.com>
wrote:

> Sorry for the really dumb question, but I wanted to ask you. What
> compilers/tools you are using for building your UEFI/PI implementation
> on arm (both aarch32 (armv7) and aarch64)? And generally, is there a
> toolchain (available for downloading (not necessarily free) in binary
> form) for the arm architecture able to make PE/COFF images natively,
> without freaking translation from elf?
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>

Re: Toolchain question

[Ard Biesheuvel]

On 9 August 2016 at 06:07, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
> Hi,
>
> I assume that you are using linux because you're talking about ELF files.
> MinGW may be able to compile PE images in Linux but tbh there's no reason
> for that and the "freaking" translation is actually a pretty good
> implementation and works very well.
>

Agreed. I suppose Microsoft may offer a toolchain that targets Windows
RT (if that still exists) but free implementations like GCC and Clang
are not likely to implement this any time soon, simply because, other
than UEFI, there are no use cases.

The ELF translation may be a bit clunky, but it is very effective, and
allows us to use a wide range of toolchains: RVCT (ARM only), GCC and
Clang, all of which are under constant development.

> As for the kind of toolchain to use: there's always (at least) two types:
> bare metal toolchains(arm-eabi,arm-none-eabi, aarch64-elf), and the ones
> with a OS ABI(androideabi, linux-gnueabi,linux-gnueabihf, ...). While unlike
> other bootloader/kernel projects EDK2 seems to work with all of them I can
> only recommend using the bare metal variants.
>

I use both, and never notice any difference. The primary differences
are newlib vs glibc, and in some cases, whether symbols are decorated
with a leading _
The actual code generation is more dependent on the default target
(i.e., -march/-mthumb for ARM) than bare-metal/hosted.

> For ARM and AArch64 I recommend using linaro's latest stable release(5.3 at
> the time of writing):
> http://www.linaro.org/downloads/
> sometimes the website is out of date and you can go here directly:
> https://releases.linaro.org/components/toolchain/binaries/
>
> I've also CC'ed the Arm maintainers so you'll actually get answers unlike me
> when I asked the same question about a year ago ;)
>

We have had good results enabling LTO for GCC5. However, we only
recently added support for this, and Tianocore needs some tweaks that
ordinary glibc based environments do not need to enable LTO. Please
report any issues you see with GCC5, or switch to GCC49 (which works
fine for GCC 5.x toolchains as well, but does not enable LTO)

-- 
Ard.

Re: Toolchain question

[Leif Lindholm]

On Tue, Aug 09, 2016 at 06:07:36AM +0200, Michael Zimmermann wrote:
> As for the kind of toolchain to use: there's always (at least) two types:
> bare metal toolchains(arm-eabi,arm-none-eabi, aarch64-elf), and the ones
> with a OS ABI(androideabi, linux-gnueabi,linux-gnueabihf, ...). While
> unlike other bootloader/kernel projects EDK2 seems to work with all of them
> I can only recommend using the bare metal variants.
> 
> For ARM and AArch64 I recommend using linaro's latest stable release(5.3 at
> the time of writing):
> http://www.linaro.org/downloads/
> sometimes the website is out of date and you can go here directly:
> https://releases.linaro.org/components/toolchain/binaries/

So, while all of the above is fine, I only ever use the native
compiler under Linux, or one of the linaro "-linux-" flavours if
cross-compiling.

I am however happy someone is testing the bare-metal profiles as well,
since we need to keep the environment (i.e. build configuration) rigid
enough that toolchain flavour does not affect things.

> I've also CC'ed the Arm maintainers so you'll actually get answers unlike
> me when I asked the same question about a year ago ;)

Thanks :)

Regards,

Leif

Re: Toolchain question

[Michael Zimmermann]

> I use both, and never notice any difference. The primary differences
> are newlib vs glibc, and in some cases, whether symbols are decorated
> with a leading _
> The actual code generation is more dependent on the default target
> (i.e., -march/-mthumb for ARM) than bare-metal/hosted.

> I only ever use the native
> compiler under Linux, or one of the linaro "-linux-" flavours if
> cross-compiling.

I think that works because edk2 excludes all toolchain libs with -nostdlib
and fno-builtin.
I know from other bootloader projects like LK(LittleKernel) which link
against libgcc that compiling with anything but bare-metal toolchains makes
the resulting binary un-bootable.

Thanks
Michael

On Tue, Aug 9, 2016 at 10:39 AM, Leif Lindholm <leif.lindholm@linaro.org>
wrote:

> On Tue, Aug 09, 2016 at 06:07:36AM +0200, Michael Zimmermann wrote:
> > As for the kind of toolchain to use: there's always (at least) two types:
> > bare metal toolchains(arm-eabi,arm-none-eabi, aarch64-elf), and the ones
> > with a OS ABI(androideabi, linux-gnueabi,linux-gnueabihf, ...). While
> > unlike other bootloader/kernel projects EDK2 seems to work with all of
> them
> > I can only recommend using the bare metal variants.
> >
> > For ARM and AArch64 I recommend using linaro's latest stable release(5.3
> at
> > the time of writing):
> > http://www.linaro.org/downloads/
> > sometimes the website is out of date and you can go here directly:
> > https://releases.linaro.org/components/toolchain/binaries/
>
> So, while all of the above is fine, I only ever use the native
> compiler under Linux, or one of the linaro "-linux-" flavours if
> cross-compiling.
>
> I am however happy someone is testing the bare-metal profiles as well,
> since we need to keep the environment (i.e. build configuration) rigid
> enough that toolchain flavour does not affect things.
>
> > I've also CC'ed the Arm maintainers so you'll actually get answers unlike
> > me when I asked the same question about a year ago ;)
>
> Thanks :)
>
> Regards,
>
> Leif
>

Re: Toolchain question

[Leif Lindholm]

On Tue, Aug 09, 2016 at 11:02:55AM +0200, Michael Zimmermann wrote:
> > I use both, and never notice any difference. The primary differences
> > are newlib vs glibc, and in some cases, whether symbols are decorated
> > with a leading _
> > The actual code generation is more dependent on the default target
> > (i.e., -march/-mthumb for ARM) than bare-metal/hosted.
> 
> > I only ever use the native
> > compiler under Linux, or one of the linaro "-linux-" flavours if
> > cross-compiling.
> 
> I think that works because edk2 excludes all toolchain libs with -nostdlib
> and fno-builtin.
> I know from other bootloader projects like LK(LittleKernel) which link
> against libgcc that compiling with anything but bare-metal toolchains makes
> the resulting binary un-bootable.

Sure, but those are effectively bugs in the corresponding projects.

If they require special options/libraries they should (where possible)
manually configure this, or (where not) exit with an error.

Regards,

Leif

Re: Toolchain question

[Ard Biesheuvel]

On 9 August 2016 at 12:02, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Tue, Aug 09, 2016 at 11:02:55AM +0200, Michael Zimmermann wrote:
>> > I use both, and never notice any difference. The primary differences
>> > are newlib vs glibc, and in some cases, whether symbols are decorated
>> > with a leading _
>> > The actual code generation is more dependent on the default target
>> > (i.e., -march/-mthumb for ARM) than bare-metal/hosted.
>>
>> > I only ever use the native
>> > compiler under Linux, or one of the linaro "-linux-" flavours if
>> > cross-compiling.
>>
>> I think that works because edk2 excludes all toolchain libs with -nostdlib
>> and fno-builtin.
>> I know from other bootloader projects like LK(LittleKernel) which link
>> against libgcc that compiling with anything but bare-metal toolchains makes
>> the resulting binary un-bootable.
>
> Sure, but those are effectively bugs in the corresponding projects.
>
> If they require special options/libraries they should (where possible)
> manually configure this, or (where not) exit with an error.
>

The problem with libgcc on AArch64 is that it is usually compiled with
the small code model, requiring 4 KB section alignment (up until
recently at least), and without -mstrict-align. In general, projects
that contain C code that should be able to execute with the MMU off
should steer clear of toolchain supplied target libraries.

-- 
Ard.