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


Mike Frysinger wrote:
> On Thursday 12 November 2009 20:27:56 Fabrice Gautier wrote:
>> 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.
> 
> presumably the ROM api is largely fixed, as is the address where it lives.  so 
> create a header file that declares const function pointers with a fixed 
> address.  then all your C code will simply call that address directly.

> if your ROM doesnt have any sort of stable abi, i imagine you could write a 
> script that converts the final linked addresses into a C header file.

Thats pretty much what we did before, but as you note you need some kind
of script to extract the linked address. This script parse the output of
nm to find the addresses, and so is likely to break if the output format
change or if we need to change toolchain.

Our script would either produce a list of PROVIDE directive to be
included in the linker script, or a C header file.

With PROVIDE directive you can directly use the header file from your
rom, and does not requires a function pointer. But this does not work
for the rom entry points that are mips16 code because then the compiler
has no way to know if they need to jump to 32 bit or 16 bit code. (I
suspect there might be similar issues for arm thumb code)

So for mips16 code we had to do some kludge where we need to redefine a
function pointer and assign the value "entry_point_address+1" (the "+1"
is how the mips knows its going to jump to mips16 code)
And using function pointers apparently also force the compile to use
register jumps (ie long jumps) instead of regular jumps.

Our current solution is believed to be better in the sense that it only
relies on the binutils tools and does not need extra parsing scripts (
(and as such is probably more portable)... But I'm still looking to
improve it.

-- Fabrice


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