[yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

William Mills wmills at ti.com
Thu Oct 24 07:30:34 PDT 2019



On 10/24/19 10:02 AM, richard.purdie at linuxfoundation.org wrote:
> Hi Bill,
> 
> On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
>> I started looking at this thread because I had the same
>> questions.  Is it possible to make a recipe depend on another version
>> of GCC and restart the whole GCC build process again with a different
>> config.
>>
>> Or does this need multi-config?
> 
> A different version of gcc would be most easily handled with
> multiconfig, yes.
> 
>> This is the question I was trying to ask the other day.
>>
>>> I'm saying I don't think you need a second toolchain. I think you
>>> could
>>> use your existing arm toolchain with the right compiler options.
>>>
>>> See 
>>> https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
>>>
>>> So you'd just add the right flags to the compiler, something like:
>>>
>>> XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib
>>> -nostdinc
>>>
>>> i.e. tell it which processor to target and not to use standard
>>> libraries/includes.
>>>
>>> There isn't anything that special about a baremetal compiler except
>>> it
>>> sets some different default flags and is missing the library
>>> support.
>>>
>>
>> Really??
> 
> As I understand it. I'm by no means an expert but I do my best with the
> OE toolchain recipes.
> 
>> Lets start with the fact that the ARM binary toolchain has been
>> tested with M4 cores.
> 
> Sure, I'm not claiming this is a well travelled path. I don't see why
> it shouldn't work though, or why it makes much difference with the
> right compiler options.
> 
>> Then understand that you will need to supply your own gcc compiler
>> helpers and all stdc functions even the ones that port well like
>> strlen and memcpy.  (Because everyone should embedded their own
>> unoptimized memcpy in their projects.)
> 
> Right, that is by definition baremetal.
> 

Well not really.  All the "bare-metal" toolchains I have used come with
a proper libgcc and some conig of newlib that at least gets you usable
strlen and memcpy etc.  How much of the rest of it is usable on your
platform is variable.

This is true of the toolchain Oliver is pointing at and has been true
back to 2007 when I was using codesourcery releases.

>> This works for the kernel and u-boot but they were designed for this
>> and have many eyes on their version of memcpy etc.  They are also
>> running on the same CPU core as the Linux user space.
>>
>> Given this I can believe this would work for CLang/LLVM if M4 support
>> was enabled at build time.  I am not convinced for GCC.
>>
>> If the above really works then why does gcc insist on being compiled
>> again after the c library has been compiled?  I have asked and never
>> got an answer that I understood.  I have been told that it looks at
>> the c library headers and changes what it builds into the compiler.
> 
> I've never understood that either and looked into it. Back in December
> last year, we dropped gcc-cross-initial:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=0afd3ac3ada35dd986aaf3be41d7177dc6b71ade
> 

Cool, good to know.

> After that, YP does no longer rebuild gcc after building the c library,
> there is one cross toolchain. That one toolchain is used for all
> different arm targets, its only architecture specific.
> 
> The only thing we do rebuild is libgcc, which is why there is still a
> libgcc-initial and a libgcc, the latter being built after libc. That
> much kind of makes sense.
> 
>>   Does all that magic go away with just -nostdinc and -nostdlib?
> 
> I believe so, yes.
> 
>> I know this works for the kernel but targeting an RTOS or bare-metal
>> for a very different core would make me nervous.  Especially true if
>> the M4 would need to link libraries that were built outside of OE.
>>
>> I know I am pushing back hard but I am also hoping you will convince
>> me I am wrong.
> 
> You're probably right to have some concerns in that its not a well
> travelled path. There are libc specifics encoded into libgcc but I
> can't quite see where they change how gcc behaves other that the
> default option selection.
> 
> Equally there may be something I'm missing.
> 
> For full disclosure, gcc is built against linux-libc-headers wherease
> with baremetal it would be built without headers. I believe that
> changes the default options gcc uses for compiling but not the way the
> compiler itself works.

"baremetal" would be compiled against some config of newlib headers.
newlib has its own issues and many config choices (you get to pick your
threading model: none, bad, or hacky).  For TI-RTOS I think we rebuild
it with a different thread model.

Thanks,
Bill


More information about the yocto mailing list