On 2007-04-12, David Brown <[email protected]> wrote:
>> FWIW the linker will "recognize" both segments just fine. The
>> problem is that it recognizes them as two separate memory
>> segments (hey, they _are_ two separate memory segments -- blame
>> TI for that). AFAIK, gnu ld doesn't support non-contiguous
>> memory segments. [If you want an authoritative answer, ask on
>> the binutils mailing list.] That means that the linker script
>> is going to have to tell the linker which modules go in which
>> "text" segment.
>>
>> Supporting non-contiguous memory segments in a efficient manner
>> is an example of the classic "bin packing problem". It's a
>> combinatorial NP-hard problem. That's why a CPU with
>> non-contiguous code space is a bad idea.
>
> Yes, that's the problem. When you know what functions or data
> you want in the upper half of memory, it's easy - make a new
> output section in the linker (called ".text2", for
> convenience), and put all ".text2" input sections there. In
> the C code, use "__attribute__ ((section(".text2"))) to force
> specific items into this section. Alternatively, you could
> specify the ".text" section from specific object files or
> libraries to be put in the new section.
>
> It is also perfectly feasible to drop the "vectors" from the
> "memory" command, and just have a single "text" section
> covering the entire flash. The issue then is how to get the
> "vectors" input section to link at the specific absolute
> address of 0xffc0. It's easy enough to link it there by
> specifying it in the "sections" command. The trouble is
> trying to get the normal ".text" sections to flow around it.
> As you say, it doing this optimally is a hard problem, but
> doing it lazily is not.
I've been thinking more about the problem. I think with the
degenerate case of only 2 bins, the problem isn't actually that
hard. If I've got it figured correctly, doing it optimally is
O(N^B), where N is the number of input sections and B is the
numbr of bins. With N==2, a brute force optimal solution
should be feasible (especially for a small number of input
sections).
A slightly sub-optimal solution would be fairly simple. As you
note, if you enable -ffunction-sections even the most naive
algorithm should produce good results.
> I have used other linkers (for other processors) that handle
> this reasonably well. When faced with a selection of normal
> relocatable input sections and some fixed absolute input
> sections, the linker starts by placing the absolute input
> sections first. Then it places the relocatable input sections
> as normal, starting from the top. If an input section would
> crash with an absolute section, the location counter is set to
> the end of the absolute section and the process continues.
> You'll end up with a sub-optimal gap before the absolute
> section(s), but so what? In this particular case, there is
> only the one absolute section - and if there is too much space
> taken up, you can always use -ffunction-sections for finer
> grained sections.
Exactly
> I don't know whether ld has this functionality or not
I believe that it doesn't (but I could be wrong). Adding it
shouldn't be a huge effort, but I think it's going to touch a
lot of stuff deep inside the linker. IOW, for somebody who
already knows the details, it shouldn't be hard. But, for
somebody like me who only tinkers around the edges, it would
take quite a while to get up to speed to the point where I
would know how to add it. Hopefully that makes sense.
> - I can't see any way to get it. But the binutils mailing
> list is definitely the place to ask for it if this is the way
> to go.
--
Grant Edwards grante Yow! I want DUSTIN
at HOFFMAN!! ... I want
visi.com LIBRACE!! YOW!!
