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

[richard.purdie at linuxfoundation.org]

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.

> 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

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.

Cheers,

Richard