Re: [PATCH] ld: Override default linker emulation at configure time

[Alan Modra <amodra at gmail dot com>]

On Fri, Jan 20, 2017 at 08:58:44AM +0000, Andrew Burgess wrote:
> * Alan Modra <amodra@gmail.com> [2017-01-20 11:37:28 +1030]:
> 
> > On Thu, Jan 19, 2017 at 04:38:31PM +0000, Andrew Burgess wrote:
> > > This commit adds a new configure option for ld that allows the default
> > > linker emulation to be selected at configure time.  The new option is:
> > > 
> > >     --with-default-linker-emulation=NAME
> > > 
> > > where NAME is the name of a linker emulation that would otherwise be
> > > valid for this target (as you'd pass to ld -mNAME).  The validity of
> > > NAME is checked at configure time.
> > > 
> > > The effect of this configure option is to make NAME the new default
> > > linker emulation.  The old default is still available in the list of
> > > alternative emulations and can be selected with the -m option to ld.
> > 
> > Do you have an example where this would be useful, and wouldn't be
> > better to configure for the correct target?
> 
> Sure, I'm currently support a customer Mellanox, to upstream support
> for their arc700 based architecture.  As part of this work we've added
> an additional linker script[1].
> 
> So, when Mellanox configure binutils a bit like this:
> 
>    ./configuire --target=arceb-mellanox-linux-uclibc
> 
> thanks to the 'arc*-*-linux*' specialisation in configure.tgt we set
> the default linker script to arclinux.  However, Mellanox will
> actually always want to use the arclinux_nps linker emulation, so
> ideally this would be the default.
> 
> I could add more specialisation in configure.tgt, but in [2] I was led
> to believe that using the vendor string of the configuration target for
> specialisation was discouraged wherever possible, and so...
> 
> ... the only idea I could come up with was adding a configure option.
> 
> I'm not tied to this implementation though, I'm happy to rework this
> in a different direction if you have any hints / suggestions.
> 
> Thanks,
> Andrew
> 
> [1] https://sourceware.org/ml/binutils/2016-12/msg00172.html
> 
> [2] https://sourceware.org/ml/binutils/2016-03/msg00195.html

I see.  I think there may be some misunderstanding.  We have precedent
for using the vendor part of a target string to select default linker
emulations.  eg. See arm-epoc-pe, arm-wince-pe, arm-*-pe in
ld/configure.tgt and various mips targets.

I prefer you select the default emulation based on the vendor rather
than add a new configure option..  That's just my opinion though.
Either way is OK, and it comes down to what is easiest for users.

Now if I understand correctly, the arc processor is highly configurable
and relatively easy for vendors to add features.  So we are likely to
have a multitude of slightly different processors, or targets.  You
can take the purist view that these are really different targets, so
the target part of the string ought to be different, but that requires
the vendor to invent a name for the variant processor (they probably
do that anyway!) and for the user to know it.  From a user perspective
it's likely much easier to remember arc-mellanox-linux rather than
arcnps400-linux or whatever you'd use if forced to use just the target
part of the triple to select the emulation.

The same argument applies to default cpu for assembly and
disassembly.  That could reasonably depend on the vendor part of the
triple too.  Note that I'm not saying the vendor part should be
allowed to change the support compiled into the opcode table, just the
default.

-- 
Alan Modra
Australia Development Lab, IBM