RE: [RFC] arc/ld: Linker script extensions to support nps targets

[Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>]

Hi,

> However, I'm open to suggestions for alternative strategies.  The only
> idea I have right now is creating an nps specific clone of the
> arclinux linker emulation, and having GCC select this when compiling
> for nps.  I considered this, but initially rejected it as
> over-engineering, but again, I'd like to hear what people think.

I've collected a number of reactions from ARC Linux maintainers which I would like to share them with you:

Vineet:
I would prefer a separate script for non standard ARC SoC. EZChip have FMT / CMEM
hardware contraptions which are wired to fixed user virtual addresses say
0x57f00000, normally used in ARC for user stack (and their kernel actively tries
to not have stack there). The linker script fragment naturally reserves this which
affects where .stack gets generated.

Anton:
1) I'm not sure it is good to use common names like "_cmem_start" for vendor-specific extensions. I'd rather see names like "_nps400_cmem_start" or something like. What if I'm an another Synopsys customer, who also wants a symbol named _cmem_start?
2) How this will work with their own future Melanox processors? Say, they make NPS 600 where .cmem should be mapped at different address. But there is already script that maps it and this script is always applied. Now one has to use ".cmem2", I guess?

Alexey:
But for the sake of clarity I'd prefer a separate linker script for NPS platform.

...and myself (not a Linux maintainer, though :) ):
Changing the default linker script used by many other ARC platforms to match a single instance of ARC700 doesn't look like a good idea to me. Moreover, the proposed linker script is only tested on NPS400 and not on alternative ARC Linux platforms. In my opinion, the NPS400 should be handled separately as it is specific for this particular cpu. 

Thanks,
Claudiu