Re: [PATCH 0/3] picolibc: Add picolibc linking help

[Kito Cheng <kito.cheng@gmail.com>]

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 <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