platform: add option to build BMP FW with picolibc #2291

hrm commented 2026年07月11日 14:31:20 +02:00

Detailed description

Added an option for the stm32 platforms to build against picolibc instead of newlib-nano. Contrary to my expectation the resulting build uses a bit more flash:

newlib-nano:

Memory region Used Size Region Size %age Used
 rom: 117576 B 128 KB 89.70%
 ram: 9832 B 20 KB 48.01%

picolibc:

Memory region Used Size Region Size %age Used
 rom: 117880 B 128 KB 89.94%
 ram: 9576 B 20 KB 46.76%

Maybe I'm missing some optimization opportunities, but regardless I'd still prefer to have the option to build against picolibc if I choose so

Edit: Under Windows with arm-none-eabi-gcc.exe (xPack GNU Arm Embedded GCC x86_64) 15.2.1 20251203 with picolibc added I get this very welcomed saving:

Memory region Used Size Region Size %age Used
 rom: 115236 B 128 KB 87.92%
 ram: 9580 B 20 KB 46.78%

Please note that we not only get over 2KiB of flash saved, but also 250bytes of bss. There are no downsides that I can see. Furthermore I also expect the printf implementation of picolibc to be slightly faster

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

<!-- Filling this template is mandatory --> ## Detailed description Added an option for the stm32 platforms to build against picolibc instead of newlib-nano. Contrary to my expectation the resulting build uses a bit more flash: newlib-nano: ``` Memory region Used Size Region Size %age Used rom: 117576 B 128 KB 89.70% ram: 9832 B 20 KB 48.01% ``` picolibc: ``` Memory region Used Size Region Size %age Used rom: 117880 B 128 KB 89.94% ram: 9576 B 20 KB 46.76% ``` Maybe I'm missing some optimization opportunities, but regardless I'd still prefer to have the option to build against picolibc if I choose so Edit: Under Windows with arm-none-eabi-gcc.exe (xPack GNU Arm Embedded GCC x86_64) 15.2.1 20251203 with picolibc added I get this very welcomed saving: ``` Memory region Used Size Region Size %age Used rom: 115236 B 128 KB 87.92% ram: 9580 B 20 KB 46.78% ``` Please note that we not only get over 2KiB of flash saved, but also 250bytes of bss. There are no downsides that I can see. Furthermore I also expect the printf implementation of picolibc to be slightly faster <!-- Explain the **details** for making this change. * Is a new feature implemented? * What existing problem(s) does the pull request solve? * How does the pull request solve these problems? Please provide enough information so that others can review your pull request. Information embedded in the description part of the commits doesn't count. --> ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [ ] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues <!-- put "fixes #XXXX" here to auto-close the issue(s) that your PR fixes (if any). -->

hrm commented 2026年07月11日 15:59:50 +02:00

Unfortunately if I use --printf=m for minimal picolibc implementation, the build breaks. When we use --printf=i, the build is approximately 1k larger

Unfortunately if I use `--printf=m` for minimal picolibc implementation, the build breaks. When we use `--printf=i`, the build is approximately 1k larger

hrm commented 2026年07月11日 17:16:14 +02:00

Update:

Before I was building under Arch with picolibc from here - https://aur.archlinux.org/packages/arm-none-eabi-picolibc .

If I build under Windows with the official release of picolibc - https://github.com/picolibc/picolibc/releases/tag/1.8.11 and xpack-gcc - https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v15.2.1-1.1

I get a very nice flash savings:

Memory region Used Size Region Size %age Used
 rom: 110692 B 128 KB 84.45%
 ram: 9816 B 20 KB 47.93%

Memory region Used Size Region Size %age Used
 rom: 107332 B 128 KB 81.89%
 ram: 9564 B 20 KB 46.70%

Therefore I'll definitely advise to merge this. It will not affect the default build, but it will have a very welcomed upside for whoever wants to setup gcc with picolibc.

Update: Before I was building under Arch with picolibc from here - https://aur.archlinux.org/packages/arm-none-eabi-picolibc . If I build under Windows with the official release of picolibc - https://github.com/picolibc/picolibc/releases/tag/1.8.11 and xpack-gcc - https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v15.2.1-1.1 I get a very nice flash savings: ``` Memory region Used Size Region Size %age Used rom: 110692 B 128 KB 84.45% ram: 9816 B 20 KB 47.93% ``` ``` Memory region Used Size Region Size %age Used rom: 107332 B 128 KB 81.89% ram: 9564 B 20 KB 46.70% ``` Therefore I'll definitely advise to merge this. It will not affect the default build, but it will have a very welcomed upside for whoever wants to setup gcc with picolibc.

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

You are not authorized to merge this pull request.