[RFH] How to teach ld to choose in an intelligent fashion whichoutput sections to use for the ensemble of input sections.

[Björn Haase]

References: <D3C486BA1A1825409E44B17E8FA629600334BFA6@si-mail06.de.bosch.com>

>Hi Bjoern,
> 
>>What would be required for proper linking is that ld 1.)
>>dynamically chooses the output section for the different input sections.
>>I.e. all the ".text" input sections should end up in the output section
>>(and corresponding region) ".text_low" until it is full. Then the
>>remaining object files should be placed in the output section (region)
>>".text_high".
>
>Although the linker could be taught to do this, it is hard to do so
>optimally. Without profiling and control flow information the linker has to
>guess which output section would be the best for any particular input
>section.   
 
IIUC, there is nothing like "optimal placement" for the HC12 architecture: 
There is no penalty for calling a function residing in a different page of 
banked memory.

\begin{offtopic}

You mentioned the keyword: "optimal placement": I have seen that, when doing 
linker relaxation for avr one could possibly do better if the linker would 
try to arrange the sequence of the differend object sections (quite a lot of 
them when using -ffunction-sections) so that as many as possible jumps/calls 
end up as short pc-relative insn.
The present situation is not this bad, but I am convinced that one could do 
better. This might be good for up to 1% code size. 
Are there targets for which the linker does this kind of shuffling 
optimization in the source tree?

\end{offtopic}
 
>>Is there already a target that does something similar? 
>
>As far as I know, "no". 
... unfortunate ... I was already hoping to be able to use a kind of 
"cut-and-paste-with-switched-on-brain" approach for this issue like what 
worked for the linker relaxations for avr. :-(. OK, at least I now know that 
I would not be re-inventing the wheel.

>Normally in situations like this the problem is 
>resolved by the application writer explicitly choosing the output sections
>for particular input sections, tweaking them as necessary in order to fill up
>the memory banks and get the best performance.   

This is what I am doing now. Only, this is extremely cumbersome. Already all 
the parts stemming from libc (newlib) fill 6 pages alone. Dozens of tiny 
object files that you even don't know what they are good for. :-(


Thank's for the help. 

Bjoern.