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 Mon, 2008-07-14 at 10:55 +0800, Jie Zhang wrote:
> Oh, I understand what Jonathan said now. But using objcopy is not 
> convenient. It needs to figure out what sections needs to be renamed. It 
> needs to change Makefile rules. People use "coarse grained method" to 
> put applications into L1 SRAM because it's convenient, i.e. adding two 
> or three options in LDFLAGS in Makeifle is enough.

Jie:

In the end, this isn't my decision, so I'm not going to post on it after
this note, but I think you are making a mistake with this patch.
Basically, you are introducing a hack to do exactly what the current
emulation templates are *designed* to do. Adding a second way to do a
rare case is almost always a bad idea.

We have a similar situation in Coyotos. We have a small linkage model
and a large linkage model, because we use the small address space
multiplexing tricks from L4 and EROS. The main difference between the
two models is where the text start address is (stack address also
changes, but we do not handle that from LD). We solved the problem by
adding a pair of coyotos-specific linker scripts. For example, our ARM
target has:

  ld/emulparams/armelf_coyotos.sh    # basically armelf.sh
  ld/emulparams/armelf_coyotos_small.sh

This required us to add support in the configure scripts. We also added
options --large-space and --small-space to gcc for the Coyotos target.
The effect of these options is simply to invoke the proper linker
template, which is really what you are trying to do.

Both of these patches are trivial enough (and Coyotos is still unusual
enough) that we have not felt any need to submit them upstream. Note
that --small-space/--large-space can already be done at the GCC command
line by telling the linker what script name to use. For our user base,
it was a convenience to add these options.

These changes have exactly the same effect as the change that you are
proposing, which is to handle it all with a single option. The
difference is that our approach works within the designed mechanisms of
ld, while yours does not.

Given this, my strong recommendation to Daniel is to reject this patch
because it will create an ongoing maintenance burden and it achieves
absolutely nothing beyond what the existing mechanisms already provide.


shap


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