Picolibc support

[keith-packard]

This adds picolibc as an optional C library for embedded systems.

There are patches included here for gcc which adds a command line convenience argument, '--oslib=', which would typically be processed by picolibc.specs when that is specified on the command line. As this toolchain configuration installs picolibc as the system C library, it is handy to not require '--specs=picolibc.specs' just to allow the --oslib option to work. However, that is a separable part of the series, so if custom gcc patches aren't interesting, it can be simply dropped.

This builds both C and C++ applications, with full support for libstdc++ as the picolibc patches required for that were merged into gcc quite a while ago.

[kito-cheng]

Hi Keith, do you mind send those GCC changes to GCC mailing list? we would like move most changes to upstream if possible :)

[keith-packard]

Done! I rebased to current GCC development head. If it would help, those patches are strictly optional -- they enable use of picolibc-specific support libraries without needing to include --specsfile=picolibc.specs on the GCC command line.

[kito-cheng]

I am thinking that maybe we should add an -mlibc=[newlib|newlib-nano|picolibc|unknown] to bare-matel toolchain, one reason is having an unify interface to select libc implementation between clang/LLVM, you might know spec is a GCC specific stuff, that cause very bad compatibility between GCC and clang/LLVM, and using having option to control that would be better since clang/LLVM don't have those configure time option.

[kito-cheng]

I just reply that on GCC mailing list too, -m option is kind of target specific option so we can decide that, but that would be great to gather boarder feedback from whole GCC community.

[cmuellner]

Do the check--picolib and the report--picolib targets work?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Copy'n'paste error?

[cmuellner]

Done! I rebased to current GCC development head. If it would help, those patches are strictly optional -- they enable use of picolibc-specific support libraries without needing to include --specsfile=picolibc.specs on the GCC command line.

If the patches are optional, then please remove the GIT URL change in .gitmodules.

[keith-packard]

Done! I rebased to current GCC development head. If it would help, those patches are strictly optional -- they enable use of picolibc-specific support libraries without needing to include --specsfile=picolibc.specs on the GCC command line.

If the patches are optional, then please remove the GIT URL change in .gitmodules.

will do. I'll work with gcc upstream to see what they want to include (if anything).

[keith-packard]

Do the check--picolib and the report--picolib targets work?

hanks for catching my copy-n-paste errors; I've fixed all of those. These targets now execute, but they don't come close to working. I suspect it would take significant effort in upstream gcc to support picolibc there, but I haven't looked.

I'm thinking that the least I could do is run the picolibc test suite; that exercises the compiler, picolibc and qemu. I could also run the glibc test suite, but that's a bit more involved. What kind of testing would you like to see here?

[keith-packard]

I've pushed an update to this branch which doesn't change the GCC version. That works fine, it just requires using --specs=picolibc.specs on the link command line to avoid trying to find libgloss.

[fanghuaqi]

Will this PR be merged? I see picolibc a good replacement for newlib-nano with good code size performance, Zephyr project is already integrated in its project, see zephyrproject-rtos/zephyr#26545.

It provide really impressive code size reduction compared to newlib-nano:

text	data	bss	dec	hex	version
16908	428	4917	22253	56ed	minimal
15460	464	4924	20848	5170	picolibc integer-only
20272	464	4924	25660	643c	picolibc full version
20862	548	4936	26346	66ea	newlib-nano integer-only
50542	916	4936	56394	dc4a	newlib-nano full version
48170	2924	4984	56078	db0e	newlib

[cmuellner]

We discussed this today and decided to include picolibc.

Kito or I will do some testing and final review in the next few days and either report if issues are left or merge the PR.
Thanks!

[keith-packard]

We discussed this today and decided to include picolibc.

Kito or I will do some testing and final review in the next few days and either report if issues are left or merge the PR. Thanks!

If you're planning on providing both newlib and picolibc along with libstdc++, you might want to consider a hack that crosstool-ng does to replace instances of #include_next with plain #include in the libstdc++ headers. That lets both C libraries peacefully coexist in one build tree.

[keith-packard]

I've rebased this. The only 'check' which works is the binutils one; the others fail because the toolchain needs additional arguments to link applications and I can't figure out how to get those past to the various tests. The toolchain is working though; I've tested it by running the full picolibc test suite.

[cmuellner]

I tested this a couple of days as well and noticed that the GCC tests don't work.
Are the failing GCC tests only those which need to link? If so, can these additional link arguments be provided via env variables?

[keith-packard]

I tested this a couple of days as well and noticed that the GCC tests don't work. Are the failing GCC tests only those which need to link? If so, can these additional link arguments be provided via env variables?

I think they probably need to link and run. I experimented with this for several hours and eventually gave up attempting to figure out how to pass the correct arguments through the system, including correct arguments to qemu to run the resulting programs. I did manage to compile, link, and run the dhrystone benchmark once I added 'times' support to picolibc in the semihosting code (that patch is moving upstream). If someone with knowledge of the build system wants to take a stab at making this work, you need the following options passed to the linker:

-specs=picolibc.specs --oslib=semihost -Wl,--defsym=__flash=0x80000000 -Wl,--defsym=__ram=0x80200000

With that, the examples should all work under qemu with semihosting enabled. The run-riscv script in picolibc is what I used for that as it sets all of the necessary qemu options.

https://github.com/picolibc/picolibc/blob/main/scripts/run-riscv

I'm happy to help with the picolibc bits when I can, but this build system has defeated me.

[TommyMurphyTM1234]

I'm just wondering what the current state of play is with this and what, if anything, remains to be done to finally make Picolibc a workable option for the RISC-V bare metal toolchain here (and/or upstream)?

[keith-packard]

I'm just wondering what the current state of play is with this and what, if anything, remains to be done to finally make Picolibc a workable option for the RISC-V bare metal toolchain here (and/or upstream)?

Thanks for the query -- I'd not applied the requested changes to the GCC patches and resubmitted them. I've done that and now we can see if the GCC team is interested in applying them. If this project would be willing to carry those patches out-of-tree in the meantime, we could get this finished up.

The GCC patches are in my gcc repo on the riscv-picolibc-oslib branch

https://github.com/keith-packard/gcc/tree/picolibc-oslib

I've also rebased and updated this series to separate out the GCC update from the rest of the series.

[TommyMurphyTM1234]

Thanks for the update @keith-packard.
Would you be able to summarise how one can try to build the Picolib bare metal toolchain from this repo now?
Is it a case of following the usual instructions but using upstream GCC sources (plus the patches in your repo?) out of tree?
Or does it require something else?
Thanks again.

[keith-packard]

Thanks for the update @keith-packard. Would you be able to summarise how one can try to build the Picolib bare metal toolchain from this repo now? Is it a case of following the usual instructions but using upstream GCC sources (plus the patches in your repo?) out of tree? Or does it require something else? Thanks again.

I've fixed my picolibc branch so that it (temporarily) moves the gcc bits to my mirror that includes the necessary changes. So, it should be sufficient to just checkout https://github.com/keith-packard/riscv-gnu-toolchain/tree/picolibc and follow the picolibc multilib instructions in the README.md file there.

I've got some more picolibc patches in motion that will make using the result even cleaner; once those have landed, you can actually do:

$ cat << EOF > hello-world.c
#include <stdio.h>

int
main(void)
{
	printf("hello, world\n");
	return 0;
}
EOF
$ riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 hello-world.c --oslib=semihost --crt0=semihost
$ qemu-system-riscv32 -semihosting-config enable=on -monitor none -serial none -nographic -machine virt,accel=tcg -cpu rv32 -bios none -kernel a.out
hello, world
$

[keith-packard]

Do the check-_-picolib and the report-_-picolib targets work?

I've removed all of the broken test bits. The only one remaining is check-binutils-picolibc. Next, I added in the ability to run the Picolibc test suite and use that as the target for check-gcc-picolibc. That performs higher level set of tests, checking the various standard C functions including the math library for correct operation.

Fixing the gcc tests would involve significant hacking to dejagnu, which appears to have C library knowledge spread throughout. If someone feels those tests would be valuable to run against picolibc, I wish them luck with that code base.

[mrv96]

upvote