Repository navigation
Allow opting out of specific parts of core crate (e.g. core::fmt) #3665
Description
In embedded systems development, there's usually a small maximum binary size. (e.g. 8KiB).
The size of core::fmt when compiled into the executable is too big for this.
Take a freestanding, x86_64-unknown-none, panic="abort" executable with 3 functions: A panic handler, a function named panik, and the _start function. In both the panic and panik functions, the only expression is loop {unsafe {asm!("hlt");}}. In the _start function, the only expression is either panic!(); or panik();
If you run cargo bloat --release --target=x86_64-unknown-none on the program's source when the only expression in _start is panic!();, the resulting executable size is 665.4KiB, which is 83 times the hypothetical size limit of our executable.
However, if you run the same command when the function in _start used is panik();, the executable size is now only 1.8KiB, which is only 25% of the limit: 332 times smaller.
It would be very nice if we could opt out of using parts of core like core::fmt instead of struggling to avoid compiling it. When opted out of part of core, the compiler will output an error (E0412) upon compiling something that is in or depends on the opted out portion, instead of silently compiling it in. My suggestion for the syntax is unuse core::foo::bar;, though other syntax is fine.
Activity
workingjubilee commentedon Jun 24, 2024
We have begun exploring allowing size-based optimizations based on
cfgin core/std. Given how much of the code bloat is "for making printing numbers of large sizes and precisions very fast", and people still want to print numbers even on embedded, but would like that to not consume several hundred KiB, I think pursuing such optimizations would be more to-the-point than modifying the language, especially when we have barely done any at all, so far.RealSuperRyn commentedon Jun 24, 2024
Those optimizations might save a few dozen KiB, but I don't see them shrinking the code size below 8KiB. Adding the ability to opt out of parts of core should be a fairly small change to the language which requires less effort than making optional size optimizations in core.
workingjubilee commentedon Jun 24, 2024
people still use Arduino ATtiny85s? I figured they had all moved on to, like, Teensys by now.
RealSuperRyn commentedon Jun 24, 2024
I'm using 8KiB as an example because I saw a thread somewhere of someone having issues with not being able to get their code below that size when their job required it. Also, people can't just say "but there's new hardware" every time someone has issues with resource usage, otherwise code will only become more inefficient.
workingjubilee commentedon Jun 24, 2024
I suppose the ATmega line and STM32s are "new" on some timescale...
Talking about "efficiency" is a distraction. Space and time generally trade against each other. More recent processors often compute more efficiently, even more efficiently than microcontrollers, if you factor in how much work they get done, which would take more time for the microcontroller and thus potentially more energy.
Anyways, the problem is that your example with the smaller binary... exists. It works because it doesn't use code that wants to link against the formatting code. So simply declaring portions "unused" which nonetheless would want to be linked in has a slight problem: how do you handle the name resolution errors?
workingjubilee commentedon Jun 24, 2024
If the answer is "somehow the rest of libcore would magically adapt to the exclusion" then it seems you have arrived at another, even-more-aggressive
cfgoption for building core? So I still think that such is a more appropriate avenue to explore.RealSuperRyn commentedon Jun 24, 2024
Give an error saying that part of libcore depends on the excluded portion.
workingjubilee commentedon Jun 25, 2024
that demand occurs instantly upon building libcore, however.
DemiMarie commentedon Jul 4, 2024
I’m not an embedded developer, but my understanding is that this is often infeasible. There can be multiple reasons:
By building libcore without the calls to
core::fmt. IIUC these are almost all for eitherpanic!()messages or trait implementations. In constrained embedded systems, it makes much more sense to emit logs in binary form and convert to human-readable form on a general purpose system.workingjubilee commentedon Jul 5, 2024
Which is not implementable as
cfgand requires new language syntax to do it why exactly?DemiMarie commentedon Jul 5, 2024
@workingjubilee It is implementable as
cfg. No new language syntax required.surechen commentedon May 24, 2025
Hello, I am very interested in binary size reduction of standard libraries in embedded systems. Where can I get detailed progress information or participate in discussions? Also, does the std have a similar strategy? Thank you very much! @workingjubilee
kennytm commentedon May 24, 2025
The
cfg-based solution can already be used on nightly with -Zbuild-std-features like