Don't place libc.a in RAM

[will-v-pi]

As part of a bugfix to place mem functions in RAM as intended (dc3a2e8), now all of libc.a gets placed in RAM too which takes up a lot of extra space. This fixes that to only place the mem functions in RAM, and leave libc.a in Flash.

It looks like this may have been missed because on some (possibly most) toolchains (e.g. Debian arm-none-eabi-gcc 14.2.1) if there are any -g flags passed, the toolchain uses libg.a instead of libc.a, and PICO_DEBUG_INFO_IN_RELEASE (which defaults to 1) passes -g. Therefore there was no libc.a to place in RAM, so the size increase doesn't occur.

Reproduced the issue from #3070 with PICO_DEBUG_INFO_IN_RELEASE=0 and the kitchen_sink_printf_compiler test, which shows the increase in RAM usage due to placing libc.a in Flash

Fixes #3070

[kilograham]

So what you are saying was that with -g the functions were never placed in RAM?

Even an 800 byte size difference is something not to be scoffed at - some existing projects may be very space constrained

[will-v-pi]

So what you are saying was that with -g the functions were never placed in RAM?

Even an 800 byte size difference is something not to be scoffed at - some existing projects may be very space constrained

I think that they were previously never placed in RAM with or without -g (at least not with my compiler/newlib), because the original *libc.a:*lib_a-mem*.o pattern did not catch *libc.a:*libc_a-mem*.o or *libg.a:*libc_a-mem*.o

When I made this change I was going off the comment which said:

        /* TODO revisit this now memset/memcpy/float in ROM */
        /* bit of a hack right now to exclude all floating point and time critical (e.g. memset, memcpy) code from
         * FLASH ... we will include any thing excluded here in .data below by default */

but the code wasn't actually including memset/memcpy as they are under libc_a-mem*.o rather than lib_a-mem*.o, so I fixed it so that memset/memcpy etc do go into RAM but accidentally included all of libc.a in RAM too