Summary

Passes --specs=nano.specs on the linker command line for rp2, meaning newlib-nano is used instead of regular newlib. As mentioned by @Gadgetoid in #11143. This reduces both the binary size and (significantly) the static RAM usage. Should also save some RAM at runtime, particularly the stack footprint of libc printf.

Includes a commit to add the --cref linker argument, which adds a cross-reference table in the linker map file. This is useful to figure out how/why certain symbols are linked.

The specific libc pieces which are linked in the default rp2 build seem to be malloc/free/realloc and some printf support.

• The malloc/free/realloc looks like it's pulled in via pico_util queue.c and time.c, and operator new & delete (unclear why these are pulled in at all!) Can find via __wrap_free in the cross-reference table. This feels like with a small amount of work it could be removed, maybe...? Particularly as the default rp2 build has no C heap available.
• snprintf looks like it's being pulled in via some mbedTLS features, shared/readline, and shared/netutils. Can find via __wrap_snprintf in the cross-reference table. This feels like it'd be harder to remove the dependency for.

I don't think any of these use cases require "full" newlib support.

The best description I know for gcc specs and nano vs normal newlib is https://metebalci.com/blog/demystifying-arm-gnu-toolchain-specs-nano-and-nosys/

Testing

• Ran the default unit tests on RPI_PICO2.

Trade-offs and Alternatives

• Keeping default newlib is the safer path, particularly if there are any C usermodules that happen to depend on "full" libc features. However, MicroPython itself doesn't depend on much libc at all.

Generative AI

I did not use generative AI tools when creating this PR.