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
signature.asc
Description: PGP signature
