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: [PATCH] Utilize Blackfin L1 SRAM


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.

In any case, based on what you have said so far I agree with the
original view that this patch does not seem well motivated, and is very
unlikely to be generally useful.

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?

It's not my decision, but so far I'm not convinced that this patch or
this approach are good ideas.

shap


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