Hi Richard, I've only used custom linker scripts with my embedded work, so I don't know much about the GCC default.
Presently, every library function is already in its own section to facilitate --gc-sections optimization. However, I #include every file together to ensure that all of the sections are still built into a single object file. So far the linker has done what I've expected (i.e., placed all of the used functions/sections in a contiguous block of memory and discarded the unused functions). Is the linker aware of section hierarchy, such that using a common section prefix (e.g. ".text.m0fp.*") would gather the appropriate sections together from multiple object files? I didn't think it was so aware; rather, that such prefixes were just a convention to help organize custom linker scripts. Adding such rules to the default linker script wouldn't be ideal, as everyone using a custom script might then have library breakage unless they knew to add equivalent rules. If the consensus is to split the library, it might help to add a set of intermediate branches (trampolines?) in the libm portion. This would add execution cycles, but not require as many extra bytes. Regards, Daniel On Thu, Nov 8, 2018, at 11:19 PM, Richard Henderson wrote: > On 11/7/18 6:10 PM, Daniel Engel wrote: > > Also, loss of control of linking order would require all short branches in > > the libm section to be replaced with long branches. This particularly > > impacts the exception handling in almost every function. > > You could partially remedy this by placing all the code into a unique section, > e.g. ".text.m0fp". The default linker script would place all instances of > this > section together. Additional tricks can be played if we're willing to modify > the linker scripts further. > > > r~
