On Sat, 2008-07-12 at 02:47 +0800, Jie Zhang wrote:
Yes. The loader will do relocation when load application or shared
library into L1 SRAMs. We use FD-PIC ABI here since Blackfin has no MMU.
In FD-PIC ABI, each segment can be relocated independently. In fine
grained control, code segment for normal code will be loaded into SDRAM,
while code segment for L1 SRAM will be loaded into L1 instruction SRAM.
In coarse grained control, all code segment will be loaded into L1
instruction SRAM if EF_BFIN_CODE_IN_L1 is set in ELF header. The
situation for data is similar.
Since the linker already provides the relocation capability you need,
it's not clear why you felt compelled to complicate your tool chain, but
I'm sure you had what seemed like good reasons. That being said, note
that using "ld -r" initially followed by a final "ld" run to specify
final target addresses will handle all of this.
Is there some requirement I am failing to understand that precludes
using the existing tools to accomplish what you want?
1. Use objcopy to rename the sections after each .o is produced.
2. Modify the linker script template to gather and group
the new section names (if the necessary parts aren't there
already).
What requirement do you have that cannot be solved using this approach?