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