Andrew Pinski <pinskia@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