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!
I think I'll also put a check into the script to test if you actually have the toolchain on your path and give an error if not. At the moment, it will just try to build and fail later on.
Where do you get the bare metal toolchain from?
http://releases.linaro.org/14.03/components/toolchain/binaries http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-ar... http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-aa...
I believe the latest version that ARM have used/tested is 13.11. I am yet to find out if 14.03 works or not...
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.
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. 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)."
... ooops!
On 14 April 2014 14:03, Ryan Harkin ryan.harkin@linaro.org 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!
I think I'll also put a check into the script to test if you actually have the toolchain on your path and give an error if not. At the moment, it will just try to build and fail later on.
Where do you get the bare metal toolchain from?
http://releases.linaro.org/14.03/components/toolchain/binaries
http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-ar...
http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-aa...
another oops, that's the aarch64 [b]ig [endian] download! try this one:
http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-aa...
I believe the latest version that ARM have used/tested is 13.11. I am yet to find out if 14.03 works or not...
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.
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. 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)."
... ooops!
On Mon, Apr 14, 2014 at 6:03 AM, Ryan Harkin ryan.harkin@linaro.org 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!
I think I'll also put a check into the script to test if you actually have the toolchain on your path and give an error if not. At the moment, it will just try to build and fail later on.
Where do you get the bare metal toolchain from?
http://releases.linaro.org/14.03/components/toolchain/binaries
http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-ar...
http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-aa...
I believe the latest version that ARM have used/tested is 13.11. I am yet to find out if 14.03 works or not...
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.
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. 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)."
... ooops!
I'm wondering how this will affect the use of boot-time and run-time services? Currently we have been using the same toolchain or Linux and UEFI, and calling directly into boot time/runtime services without worrying about ABI differences. It seems like this change may break some of these assumptions regarding the ABI.
Roy
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-uefi
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.
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.
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)."
... 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.
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
On 14 April 2014 19:32, Leif Lindholm leif.lindholm@linaro.org wrote:
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.
It would be helpful to have a bit of background on how the difference between bare metal and glibc toolchain causes this particular issue.
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.
This effectively describes the difference between -fhosted and -ffreestanding. 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.
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)."
I understand this is a copy and paste job, but how would the 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
I'm abandoned this change. But I don't think this problem is over yet...
On 14 April 2014 19:43, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 14 April 2014 19:32, Leif Lindholm leif.lindholm@linaro.org wrote:
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.
It would be helpful to have a bit of background on how the difference between bare metal and glibc toolchain causes this particular issue.
Yes, it would :-/
I haven't a clue how it causes it, I only know that it happens.
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.
This effectively describes the difference between -fhosted and -ffreestanding. 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.
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)."
I understand this is a copy and paste job, but how would the difference between 32 bit and 64 bit ABIs relate to the difference between bare metal and glibc?
I suppose that's a question for the toolchain team.
... 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.
I agree: why must the types be different. I understand the libraries and
function call being different, but type sizes should be fixed. How on earth do we cope with that?? But whether it's a bug or a feature is a different matter.
We must not cripple this reality by trying to conform to an idealistic fantasy.
I think the problem is deeper than this. The real world you talk about is the current reality, where we are depending on UEFI and the kernel being built with the same toolchain and where we build them ourselves.
The other real world is one where UEFI will be provided by the vendor and the kernel by a distro. Neither of which will be under our control or build environment. So depending on the toolchain to sort this stuff out isn't going to fly, surely? I'm glad it's not my problem to sort out ;-)
Imagine what happens when a BIOS vendor builds UEFI using the ARM compiler. Or, more likely: a Microsoft compiler.
So ... could you raise a defect on the issue you've seen?
Sure. Were you thinking a launchpad bug, or raising with ARM? Or even one of those JIRA things in the Landing Team space?
At the moment, the platform I am working on is using a binary build of UEFI supplied by ARM; that's the only one that works. I have no control over what toolchain that's built with, of course. This is my alternate reality.
/ Leif
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-uefi
On 15 April 2014 12:09, Ryan Harkin ryan.harkin@linaro.org wrote:
I'm abandoned this change. But I don't think this problem is over yet...
I'm sure it's not :]
It would be helpful to have a bit of background on how the difference between bare metal and glibc toolchain causes this particular issue.
Yes, it would :-/
I haven't a clue how it causes it, I only know that it happens.
So, dead from reset?
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.
I agree: why must the types be different. I understand the libraries and function call being different, but type sizes should be fixed. How on earth do we cope with that?? But whether it's a bug or a feature is a different matter.
If we do come across anything like this, we should be able to script this in the BaseTools. "Somehow." UEFI still has its own definitions for _all_ data types - so the actual source should be safe. The issue you're seeing may be due to some
We must not cripple this reality by trying to conform to an idealistic fantasy.
I think the problem is deeper than this. The real world you talk about is the current reality, where we are depending on UEFI and the kernel being built with the same toolchain and where we build them ourselves.
The other real world is one where UEFI will be provided by the vendor and the kernel by a distro. Neither of which will be under our control or build environment. So depending on the toolchain to sort this stuff out isn't going to fly, surely? I'm glad it's not my problem to sort out ;-)
I'm not. So it may well be worth setting up CI jobs building with bare-metal too. And adding a command line option for "toolchain profiles".
Imagine what happens when a BIOS vendor builds UEFI using the ARM compiler. Or, more likely: a Microsoft compiler.
Indeed.
So ... could you raise a defect on the issue you've seen?
Sure. Were you thinking a launchpad bug, or raising with ARM? Or even one of those JIRA things in the Landing Team space?
Yeah - linaro-uefi. Ilias promised to set up some sort of defect review - so we can go through it then and decide whether we report it to ARM or not.
At the moment, the platform I am working on is using a binary build of UEFI supplied by ARM; that's the only one that works. I have no control over what toolchain that's built with, of course. This is my alternate reality.
Yeah, I feel your pain. So, I assume this is a release blocker for you. All platforms?
/ Leif
On 15 April 2014 13:52, Leif Lindholm leif.lindholm@linaro.org wrote:
On 15 April 2014 12:09, Ryan Harkin ryan.harkin@linaro.org wrote:
I'm abandoned this change. But I don't think this problem is over yet...
I'm sure it's not :]
It would be helpful to have a bit of background on how the difference between bare metal and glibc toolchain causes this particular issue.
Yes, it would :-/
I haven't a clue how it causes it, I only know that it happens.
So, dead from reset?
Not quite. It gives some garbage on the serial terminal and then nothing happens. I was hoping it was only serial corruption and that the boot countdown would run and boot the kernel, but nope, I just get a load of garbage on the terminal.
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.
I agree: why must the types be different. I understand the libraries and function call being different, but type sizes should be fixed. How on
earth
do we cope with that?? But whether it's a bug or a feature is a
different
matter.
If we do come across anything like this, we should be able to script this in the BaseTools. "Somehow." UEFI still has its own definitions for _all_ data types - so the actual source should be safe. The issue you're seeing may be due to some
... assembly language? like a rogue "w" instead of "x" in a register move? That's one of Tixy's ideas when I was sounding this out with him earlier.
We must not cripple this reality by trying to conform to an idealistic fantasy.
I think the problem is deeper than this. The real world you talk about
is
the current reality, where we are depending on UEFI and the kernel being built with the same toolchain and where we build them ourselves.
The other real world is one where UEFI will be provided by the vendor and the kernel by a distro. Neither of which will be under our control or
build
environment. So depending on the toolchain to sort this stuff out isn't going to fly, surely? I'm glad it's not my problem to sort out ;-)
I'm not. So it may well be worth setting up CI jobs building with bare-metal too. And adding a command line option for "toolchain profiles".
Imagine what happens when a BIOS vendor builds UEFI using the ARM
compiler.
Or, more likely: a Microsoft compiler.
Indeed.
So ... could you raise a defect on the issue you've seen?
Sure. Were you thinking a launchpad bug, or raising with ARM? Or even
one
of those JIRA things in the Landing Team space?
Yeah - linaro-uefi. Ilias promised to set up some sort of defect review - so we can go through it then and decide whether we report it to ARM or not.
Ok, will do.
At the moment, the platform I am working on is using a binary build of
UEFI
supplied by ARM; that's the only one that works. I have no control over what toolchain that's built with, of course. This is my alternate
reality.
Yeah, I feel your pain. So, I assume this is a release blocker for you. All platforms?
No, it's not all that serious so far: I don't need to build my own UEFI for this new platform just yet. The binary version from ARM works fine for now. The other platforms, including 64 bit models, are all working fine today with the linux-gnu toolchain.
It would be nice to be able to build UEFI for the hwpacks though, so I can set a sensible default config and so on.
/ Leif
-
Ard Biesheuvel -
Leif Lindholm -
Roy Franz -
Ryan Harkin