Linking to rom code symbols

Fabrice Gautier fabrice@sdesigns.com
Sat Nov 14 01:00:00 GMT 2009


Actually, I take it back, none of those work properly.

It links fine if I compile the app with -mlong-calls, but if I do not
then the linker complain about "relocation truncated to fit"

Although, it does link if I do specify literally the .rom section
address but not if I use a Absolute symbol....

So if I have two scripts:

Script A:

rom_start = 0x80190000 ;

SECTIONS
{
        .rom rom_start :
        {
                rom.elf
        }

        .text 0x8001e0000 :
        {
                *(.text)
        }

        .data 0x8001f0000 :
        {
                *(.data)
        }
}


And Script B:
(where _rom_start is an absolute symbol in rom.elf equal to 0x80190000)

rom_start = _rom_start ;

SECTIONS
{
        .rom rom_start :
        {
                rom.elf
        }

        .text 0x8001e0000 :
        {
                *(.text)
        }

        .data 0x8001f0000 :
        {
                *(.data)
        }
}


When not using long calls to compile, only script A will actually link.
But when usign long calls, both script will work, and produce the exact
same binary.

I dont get it, is that a bug ???
Or is it because ld doesn treat absolute symbols coming from input files
as they would an absolute symbol defined in the linker script ?

-- Fabrice


Fabrice Gautier wrote:
> 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
>>>   
>>
> 



More information about the Binutils mailing list