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