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 <abrod...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
