Re: how to link a section in specific .o inside .a via linker script?

[Mat Hostetter <mat at lcs dot mit dot edu>]

>The problem here is that the purpose of libraries is to allow the
>linker to choose which, if any, of the object files it contains should
>be included in the final output.  If you know in advance that you are
>definitely going to need a particular object file that is normally
>held in a library then the "proper" way of doing things would be to
>extract it from the library first, and then include it on the linker
>command line.

In my case, I have created a tool that requires the following steps:

- compile normally, although ideally use -ffunction-sections -fdata-sections
- link your program normally, creating a "-Map" file
- run the program against a training set, collecting cache tracing data
- use the "-Map" file plus the tracing data to select a good cache
  packing for the sections (an absolute address for each section).
  This step emits a linker script.
- relink using the linker script to put sections at exactly
  the desired addresses.

So you see, I *do* know exactly which .o files in which .a files I
want, because they were listed in the -Map file. ld already decided it
wanted them during the first link.

I could create a wrapper around ld that extracts the desired .o files
out into temporary files and then links them together using existing
mechanisms, but creating a slightly more powerful linker script seemed
much cleaner than having to create an ld wrapper. Both approaches are
defensible.

>> I've been playing around with an experimental patch to fix this, where
>> there is a new (admittedly ugly) MEMBER operator in the linker script
>> that lets you specify a pair of a .a and .o file, that you can use in
>> place of any normal (possibly wildcarded) filename, e.g in my case:
>>     /* Only get .text section from bar.o inside foo.a */
>>     .text : { MEMBER(foo.a , bar.o)(.text) }

>Interesting.  Would this syntax mean that .text section from bar.o
>*has* to be included in the linker's output at this point, or that it
>*might* be included in the  output, but only if the linker decides
>that bar.o is needed ?

The latter (I have this working). Basically I changed wildcard
iteration to have an optional filter in the 'struct wildcard_spec'
where it will only consider .o files in an optional member list.

Once I have this properly tested I can submit a patch, but I don't
know if anyone else actually wants this feature. Admittedly there are
messy issues I did not address or think about, like SORT(MEMBER(...)),
etc.

-Mat

P.S. I also needed to change the link map generator to write out the required
     alignment of each section alongside its address and size information.
     I wrote it out as a comment to try to be compatible with any tools
     parsing linker maps, but that's kinda gross. I wonder if anyone
     else wants the alignment information in a convenient way.