On 14 April 2014 19:32, Leif Lindholm <leif.lindholm@linaro.org> wrote:It would be helpful to have a bit of background on how the difference
> On Mon, Apr 14, 2014 at 02:03:29PM +0100, Ryan Harkin wrote:
>> I'll be changing uefi-build.sh soon so that it uses the bare-metal toolchains.
>> I haven't pushed the change yet because I'm still testing stuff.
>>
>> Once I make the change, you will need to have the bare-metal toolchain
>> installed or you won't be able to build any more.
>>
>> So let me know if this will be a problem!
>
> This will be a problem.
>
>> Some background:
>>
>> OK, so I have to confess that I've been using the wrong toolchain for quite
>> some time now.
>>
>> I already have the linux-gnu- toolchain installed and it's always worked, so
>> I've been generally happy to keep using it. Whenever I get something new from
>> ARM (UEFI, TF, ...), it usually tells me to use the bare-metal toolchain. I
>> follow the instructions first time, then repeat with my "normal" toolchain.
>>
>> However, I've now come across a problem where building for an AArch64 platform
>> with the linux-gnu- platform toolchain doesn't boot, whereas using the
>> bare-metal toolchain is fine.
>
> This is a bug in EDK2 and should be fixed there. Not defaulting to
> building with embedded toolchains is a good thing which lets us spot
> things like this.
>
between bare metal and glibc toolchain causes this particular issue.
This effectively describes the difference between -fhosted and -ffreestanding.
> If someone wants to explicitly build with an embedded toolchain, they
> can do that just fine using CROSS_COMPILE/CROSS_COMPILE64.
>
>> Of course, I have never really known what the difference between the two is.
>> Enter the toolchain FAQ:
>>
>> https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ
>>
>> "The bare-metal ABI will assume a different C library (newlib for example) - or
>> even no C library to the Linux ABI (which assumes glibc). Therefore, the
>> compiler may make different function calls depending on what it believes is
>> available above and beyond the Standard C library.
>>
In other words, you can already make glibc gcc behave as bare metal
gcc (in this respect) by passing a single -f flag, and gcc even has
its own set of headers (e.g. stdint[-gcc].h) to use if -ffreestanding
prevents it from using the ones provided by the C library.
I understand this is a copy and paste job, but how would the
>> Also the bare-metal ABI and Linux ABI for the 32-bit Instruction sets make
>> different assumptions about the storage size of enums and wchar_t which you
>> have to be careful of (not a complete list). And the difference between the
>> 32-bit and 64-bit ABIs are also numerous and subtle (the obvious example being
>> pointer sizes)."
>>
difference between 32 bit and 64 bit ABIs relate to the difference
between bare metal and glibc?
>> ... ooops!
>
> I am aware of the purist toolchain engineer view on this, but in the real
> world, people will be using the default toolchain on their system.
>
Perhaps even push back a bit? I mean, what ffs is the point of, for
instance, defining uint32_t as 'unsigned int' on glibc for arm32 and
'unsigned long' on bare metal for arm32. If these things are causing
us grief, we should report them to the toolchain group as bugs.
> We must not cripple this reality by trying to conform to an idealistic
> fantasy.
>
> So ... could you raise a defect on the issue you've seen?
>
> /
> Leif
>
> _______________________________________________
> Linaro-uefi mailing list
> Linaro-uefi@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-uefi