This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linking to rom code symbols


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]