Hacker News new | ask | show | jobs
by astrobe_ 335 days ago
Yes, these are really esoteric options, and IIRC GCC's docs say they can be counter-productive.
4 comments

One engineer's esoteric is another's daily driver. All 3 of those options are borderline mandatory in embedded firmware development.
These options can easily be found by a Google Search or via LLM, whichever one prefers

> they can be counter-productive

Rarely[1]. The only side effect this can have is the constant pools (for ldr rX, [pc, #off] kind of stuff) not being merged, but the negative impact is absolutely minimal (different functions usually use different constants after all!)

([1] assuming elf file format or elf+objcopy output)

There are many other upsides too: you can combine these options with -Wl,-wrap to e.g. prune exception symbols from already-compiled libraries and make the resulting binaries even smaller (depending on platform)

The question is, why are function-sections and data-sections not the default?

It is quite annoying to have to deal with static libs (including standard libraries themselves) that were compiled with neither these flags nor LTO.

Esoteric? In embedded, people know of these from BEFORE they stop wearing diapers
-ffunction-sections has 750k hits on github. It is among the default flags for opt mode builds in Bazel. There are probably people who consider them defaults, in practice.
Well, C and C++ together have around 7M repos, so about 10%. Actually not entirely esoteric, but Github is only a fraction of the world's codebase and users of these repos probably never looked in the makefile, so I'd say 10% of C/C++ developers knowing about this is a very optimistic estimate.
Looking at GitHub is probably significantly undersampling the kinds of C projects that would be doing static linking, many of which pre-date GitHub.