Linking to rom code symbols

[Joel Sherrill]

Fabrice Gautier wrote:
> Replying to my own questions (found a solution i can live with) ...see
> below...
>   
Would this have ld option have worked? 

      -R filename
       --just-symbols=filename
           Read symbol names and their addresses from filename, but do not
           relocate it or include it in the output.  This allows your output
           file to refer symbolically to absolute locations of memory 
defined
           in other programs.  You may use this option more than once.

           For compatibility with other ELF linkers, if the -R option is
           followed by a directory name, rather than a file name, it is
           treated as the -rpath option.

--joel
> Fabrice Gautier wrote:
>   
>> Hi,
>>
>> I'm trying to find an efficient and convenient way to link a aplication
>> to rom code.
>>
>> The rom code is compiled as a rom.elf file.
>>
>> I stripped this file to keep only the needed symbol (using strip -K)
>>
>> Then in my application, I use the following linker script:
>>
>> SECTIONS
>> {
>>         .rom 0x80190000 :
>>         {
>>                 rom.elf
>>         }
>>
>>
>>         .text 0x801e0000:
>>         {
>>                 _ftext = . ;
>>                 *(.text)
>>                 . = ALIGN(4);
>>                 etext = . ;
>>         }
>>
>>         .data 0x801f0000:
>>         {
>>                 _fdata = . ;
>>                 *(.data)
>>                 . = ALIGN(4);
>>         }
>> }
>>
>> Linking with this works fine and give me an app.elf file.
>>
>> I can then extra the .text and .data section in binary files and load
>> the app this way.
>>
>> I have a couple of (minor) issues with this method though:
>>
>> a) This requires me to carry around the rom.elf file. The actual code
>> itself should not be required to link, only the symbol tables i believe.
>>
>> So I would like to find a way to generate a "symbol file" that I can
>> easily include in my linking.
>>
>> I tried to use the "objcopy --extract-symbol" to create a rom.sym file,
>> which is still an elf file but that contains only the symbol tables.
>> But this did not work. For some reason, it gets the offset all wrong
>> when linking. ie, even though readelf or nm return the symbols in the
>> 0x80190000 range when looking at the rom.sym file, after the linking
>> process, the rom symbols in the app.elf file are in the 0x320000 range.
>>
>> I'm not sure if thats a bug of the particular toolchain i'm using or
>> because I'm not doing the right thing.
>>     
>
> I now understand what --extract-symbol exactly does.
> Symbols are stored as an offset to section start, and --extract-symbol
> will set the address of all section to 0 AND adjust the offset so that
> the absolute address is still the same. (nm and readelf will print the
> calculated absolute value, not the offset)
>
> So I can use the file generated this way, but in my linker script i need
> to set the start of the rom section to 0, by using:
>  .rom 0 :
> instead of
>  .rom 0x80190000 :
>
> As it was, the beginning of the rom symbols would be 0x80190000 (from my
> app linker script) + 0x80190000 (offset from the rom.sym file) =
> 0x00320000, (with integer overflow)
>
>
>   
>> b) The second issue is that I need to specify the .rom address in my app
>> linker script, but that information should already be in the rom.elf file.
>>
>> Is there an easy and clean way to extract this information to give it to
>> the linker script ?
>>     
>
> I dont need to solve that anymore since i'll just use 0 as base address
> for my rom.
>
> But anyway, one way to address this is to declare a absolute symbol in
> the rom linker script. This is done by doing this just before the text
> section:
>
> SECTIONS
> {
>         _rom_start = . ;
>
>         .text :
>         {
>                 *(.text)
>                 . = ALIGN(4);
>         }
> [...]
> }
>
>
> _rom_start will be an absolute symbol (marked with "A" instead of "T"
> when you use nm) that could then be used in the app linker script.
>
>
> Hope this helps somebody else.
>
> -- Fabrice
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985