Re: Linking to rom code symbols

[Fabrice Gautier <fabrice at sdesigns dot com>]

Joel Sherrill wrote:
> 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


hum... yes it could also actually work.

using: ld -R rom.elf -o rom.sym

It slightly different from the "objcopy --extract-symbol" in that it
actually transforms the symbols in Absolute Symbols rather than section
relative symbols.
It also create dummy .text and .data sections in the output at default
addresses and complain about entry point not found. But I guess those
could be removed with appropriate options...

It also would have the advtange of not having to create a .rom section
in the app linker script just for that, you could just specify the
rom.sym as part of the object files.

-- Fabrice

>> 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
>>   
> 
>