On Wed, Nov 11, 2015 at 4:37 AM, Tom Rini <tr...@konsulko.com> wrote:
> On Tue, Nov 10, 2015 at 07:59:03PM -0800, Khem Raj wrote:
>>
>> > On Nov 10, 2015, at 5:09 AM, Tom Rini <tr...@konsulko.com> wrote:
>> >
>> > On Thu, Nov 05, 2015 at 03:23:48PM +0100, Carlos Rafael Giani wrote:
>> >> On 11/05/2015 03:22 PM, Otavio Salvador wrote:
>> >>> Hello Carlos,
>> >>>
>> >>> On Thu, Nov 5, 2015 at 11:16 AM, Carlos Rafael Giani
>> >>> <d...@pseudoterminal.org> wrote:
>> >>>> So, this is because of the TOOLCHAIN_OPTIONS ?
>> >>>> Also, what about the ${CC} ? Right now it won't work properly with
>> >>>> clang for
>> >>>> example.
>> >>> The clang is problem might involve us to rework something but all this
>> >>> needs to be based on last U-Boot releases; we shouldn't put
>> >>> workarounds and hacks on OE-Core without good reasons.
>> >>>
>> >>> Has the clang been tested with 2015.10?
>> >>
>> >> Still, then I'd add something to output an error message like
>> >> "U-Boot can only be compiled with gcc". Right now, the error
>> >> messages that would occur would be highly confusing and misleading.
>> >
>> > U-Boot supports clang, but it's not as well tested as other things.
>> > However, this patch is still wrong as we do not want to try and force
>> > flags to gcc, just like we don't with the kernel. For more on U-Boot,
>> > see doc/README.clang (And then possibly do some fixups, I'm not having
>> > super luck with it right now, but I'm in a bit of a rush right now).
>> >
>>
>> This patch is however injecting flags externally, so in case you were to use
>> clang with OE in context the TOOLCHAIN_OPTION will be appropriately set as
>> well
>> so this should work fine. As far as u-boot’s own build architecture is
>> concerned
>> its fine. I think the real problem is arising due to toolchain defaults in OE
>> e.g. when we default to hard float gcc does not really use hard-float unless
>> specified on commandline. One can argue that OE should be fixed for that or
>> gcc
>> should be using the right ABI as default which corresponds to default
>> configs as used for gcc in toolchain.
>>
>> One concern here I have is that when we switch float-abi like this, what is
>> the impact on u-boot itself, has it ever been build and tested with
>> hard-float, as long as there are no float function arguments this should not
>> do anything to code
>> but then we need report on this.
>
> First, no, like the kernel, you do not go mucking with the float options
> that U-Boot wants to use. OE is correctly today letting U-Boot enforce
> what it wants (and then from time to time exposing latent bug from cases
> where the toolchain ends up overriding us).
>
so here u-boot does have some expectations from toolchain, and at one
side it claims independence of hosted environment. So u-boot should be
adding -ffreestanding -nostdinc -nodefaultlibs -nostdlib to its
compiler/linker flags otherwise toolchains can insert anything into
uboot
even without adding options on cmdline.
Radek, add -D__ARM_PCS_VFP to CFLAGS and that can get this going
> Second, it's currently a bit of a moot point as U-Boot for clang for ARM
> needs a bit of attention again as how we deal with global data is once
> again making clang unhappy and no one has gone and fixed it again.
>
Can you explain the problem a bit more ?
> --
> Tom
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
