4 ms·
Neat technique. I had used it in a project where there was no linker and the compiler produced an absolute addressed binary for a custom chip. The flip side of
by rramadass 6y ago
Neat technique. I had used it in a project where there was no linker and the compiler produced an absolute addressed binary for a custom chip.
The flip side of this technique is to be careful about blowing up the size of the final executable since everything gets included. You may need a linker pass to remove unused sections from the final executable. One good example to manage this is found in the dinkumware C library where each function is in its own .c (and hence corresponding .o) file. This way only the functions actually used get linked into the final executable.
- psykotic 6y ago> The flip side of this technique is to be careful about blowing up the size of the final executable since everything gets included. Yeah, the 1970s linker model is very silly like this. The good news is that link-time optimization will handle this for you nowadays without any special per-symbol mark-up. As an experiment, put an unused 'deadfunc' function definition in a file called ltotest.c and then compare gcc -O2 ltotest.c -o ltotest && (objdump -D ltotest | grep deadfunc) and gcc -O2 -flto ltotest.c -o ltotest && (objdump -D ltotest | grep deadfunc)
- rramadass 6y agohttps://tetzank.github.io/posts/removing-unused-code/ https://tetzank.github.io/posts/removing-unused-code/
- psykotic 6y agoNeat, I didn't know about -fwhole-program as an alternative to -flto for single-file builds. It should help with compile times a little bit (though I normally only use LTO for release builds, rarely during development, so it's not a big deal either way). With MSVC I think you still have to use LTO (or LTCG as it's called there) to get this effect.