I am thinking that maybe we should add -mlibc=[newlib|newlib-nano|picolibc|unknown] option to bare-matel toolchain, one reason is having an unify interface to select libc implementation between clang/LLVM, spec file is a GCC specific stuff, that cause very bad compatibility between GCC and clang/LLVM, and having option to control that would be better since clang/LLVM don't have those configure time option.
For linux toolchain, it uses -mbionic, -muclibc, -mglibc and -mmusl, maybe we could also use an unify -mlibc= option for that? On Thu, Aug 25, 2022 at 3:32 AM Keith Packard via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Andrew Pinski <pins...@gmail.com> writes: > > (removing gcc@ as not appropriate for patch discussions) > > Thanks for reviewing my patches; I appreciate the time you have taken to > think about this. > > > Why do you need to change the specs to support picolibc? Why not have > > the library supply the specs file instead, like what is done for > > newlib and libgloss? > > Several architectures do include support for newlib's libgloss in their > gcc configuration today (i386, m32r, microblaze, nds32, pru, riscv and > sh), so I wondered if it made sense to add support for picolibc's > target-specific libraries as well. > > Picolibc does deliver a spec file fragment which implements this > functionality, but that requires the addition of --specs=picolibc.specs > to the gcc command line instead of being built-in to gcc itself. When > creating an integrated toolchain using picolibc, it seems a bit odd to > require an option for the toolchain to work. > > > What OS libraries are not included in libc? I trying to figure out why > > this needs to be special cased here. > > As a general-purpose embedded C library, picolibc doesn't include any > OS-specific code. Instead, it defines a limited subset of POSIX > interfaces which are to be supplied by the target platform. > > Picolibc itself supplies sample implementations of these ABIs that can > run on top of bare metal systems with semihosting support which are used > while testing picolibc itself. > > This is similar to newlib's libgloss: the C library is built atop > another library which needs to follow it in the linker command line for > symbol resolution to work correctly. Making this work requires a change > in the *lib spec file fragment. > > Adjusting the *lib fragment can either be done in an externally provided > specs file, or built-in to gcc. Both of these mechanisms are present in > the gcc ecosystem today, leading me to wonder whether the gcc community > would be interested in having an integrated option available. > > -- > -keith
