[Picolibc] Integrating Picolibc into a GCC toolchain

[R. Diez]

> Yes. Thanks for catching this -- I'm actually building things
> incorrectly (using the right libc, but the wrong cstdio option). Not
> surprisingly, this "works" for my tests using semihosting as that
> provides the necessary posix functions, but a pure picolibc environment
> would not.
> [...]

I would like to understand the implications of not having "--enable-cstdio=stdio_pure" when building GCC against Picolibc.

I am running a small test program for an ARM Cortex-M3 inside QEMU, and I did not notice any problems yet.

Is that because my firmware is using neither "FILE *" nor C++ stream I/O?

Would you expect a compilation problem or a run-time crash when attempting to use C++ stream I/O?

If I understand it correctly, a crash would mean that libstdc++-v3 is picking up some headers from my system with the internals of FILE. That is possible, but unlikely, because my cross-toolchain makefile is not using Newlib at all when it is told to switch to Picolibc. So those headers cannot come from Newlib. But Picolibc does have a copy of Newlib's "legacy stdio". Is it exposing those headers even when using tinystdio?

For users of my cross-toolchain makefile, would it be enough to tell them to refrain from using C++ stream I/O when configuring with tinystdio? Perhaps all of the C++ stream I/O are just templates that are not compiled at all if you do not use them.

About your not noticing: not using "stdio_pure" means that libstdc++-v3 is actually using "--enable-cstdio=stdio", and not "stdio_posix", so I wouldn't expect that availability of Posix on your test system was hiding the issue. Or does "--enable-cstdio=stdio" use a few Posix calls too?

How could this slip through the automated tests? Does Picolibc have no C++ stream I/O test case that gets automatically run against a bare-metal QEMU virtual machine?

Regards,
   rdiez