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.
- Little-endian multilib Elf32
- Big-endian multilib Elf32
- Little-endian uClibc for ARC700 (ARCompact or ARCv1 ISA)
- Big-endian uClibc for ARC700
- Little-endian uClibc for ARC HS (ARCv2 ISA)
- 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:
- Still big-/little-endian platforms require different tools
- Developers need to have Linux toolchain for user-space stuff because of C-library
- 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-linu... [3] http://git.denx.de/?p=u-boot.git;a=commit;h=a67ef280f46803e319639f5380ff8da6...
Signed-off-by: Alexey Brodkin abrodkin@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:
- SPDX license header is missing
- Some identation made with spaces
- Spaces are missing in code or there're more than needed
- A couple of "#if 0"
etc etc.
And that poses a question: what is mandatory to be fixed and what not?
- I guess SPDX license header MUST be inserted, right?
Yes. And this is what we've done for other GCC imports as well btw.
- 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.