[U-Boot] [PATCH] ARC: Import entire libgcc from GCC 8.1.0

[Tom Rini]

On Thu, Jun 07, 2018 at 08:31:49PM +0300, Alexey Brodkin wrote:

> Some background on private libgcc on ARC first.
> 
> The whole point of having private libgcc in U-Boot is to be
> toolchain agnostic. I.e. have an ability to use any more or less
> up-to-date ARC GNU tools for building U-Boot for any platform with
> ARC core.
> 
> As of today we have at least 6 (sic!) flavors of GNU toolchains for ARC.
>  1. Little-endian multilib Elf32
>  2. Big-endian multilib Elf32
>  3. Little-endian uClibc for ARC700 (ARCompact or ARCv1 ISA)
>  4. Big-endian uClibc for ARC700
>  5. Little-endian uClibc for ARC HS (ARCv2 ISA)
>  6. Big-endian uClibc for ARC HS
> 
> In foreseeable future we'll have multilib Linux toolchain so
> we'll cut number of tools down to 4. Anyways...
> 
> In general we don't need Linux toolchain for building U-Boot and since
> Elf32 GNU tools have libs for most of "standard" ARC core templates [1]
> it might be a good toolchain for U-Boot. But:
>  1. Still big-/little-endian platforms require different tools
>  2. Developers need to have Linux toolchain for user-space stuff
>     because of C-library
>  3. People tend to build more Linux tools, like Linux kernel crootools
> 
> So it looks like multilib Linux toolchain might be a bit more convenient
> option, at least it addresses (2) and (3) from above, i.e. we'll only
> need to deal with big-/little-endian story and that should be fine as
> not that many developers in the world play simultaneously with platforms
> of both types.
> 
> But no! Linux multilib toolchain will only be built for very limited
> list of mcpu's [2]. Basically only "arc700" and "archs" (with few
> flavors for HS38 templates). That's because only those cores are capable
> of running Linux and uClibc/glibc couldn't be built for others. I.e. all
> the simpler cores where U-Boot could be perfectly used [and in fact is
> used more and more] won't have libgcc pre-built as the part of the
> toolchain.
> 
> And really ultimate solution is to build libgcc as a part of U-Boot and
> have no external dependencies. That's something that we used to do for
> quite some time [3] with limited amount of functions really required by
> existing platforms. But with addition of more platforms like those with
> missing multiplier (MPY and friends) we need to have more libgcc
> functions and to make things simple and at the same time very optimal
> we're importing entire libgcc for ARC from latest stable GCC (8.1.0 as of
> today).
> 
> [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arc/t-multilib#L24
> [2] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arc/t-multilib-linux#L19
> [3] http://git.denx.de/?p=u-boot.git;a=commit;h=a67ef280f46803e319639f5380ff8da6c6b7fbe7
> 
> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> ---
> 
> Since that's an import from GCC I intentionally didn't do any changes
> to imported files. And that means checkpatch.pl is pretty unhappy.
> In particular because:
>  1. SPDX license header is missing
>  2. Some identation made with spaces
>  3. Spaces are missing in code or there're more than needed
>  4. A couple of "#if 0"
> etc etc.
> 
> And that poses a question: what is mandatory to be fixed and what not?
> 
>  1. I guess SPDX license header MUST be inserted, right?

Yes.  And this is what we've done for other GCC imports as well btw.

>  2. All the rest I'd really like to keep as it is now to simplify
>     subsequent updates of newer libgcc versions.

Yes, leaving the style otherwise non-matching is OK.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180608/ae87936d/attachment.sig>