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

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Alan Modra <amodra@gmail.com> [2017-01-24 11:05:58 +1030]:

> 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.

If we use the vendor string alone this would work for now, but would
not be future proof.  If Mellanox introduced a second arc based
product that wanted a different default emulation then we'd be stuck.

However, you've already offered a solution below....

> 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.

... right now we don't use different targets for arc, instead the
processor target is either 'arc' (little-endian) or 'arceb'
(big-endian), we do however support the --with-cpu=NAME configure
switch throughout the toolchain (gcc/gas) and this seems to be working
well.

I'd rather not introduce arcnps400-* style targets, mainly because of
the confusion I think it would cause, would that target imply
--with-cpu=nps400, or would that still need to be added?  Why does
arcnps400-* work, but not arcarc600-* not work?  Basically we have a
scheme that works right now without making new targets, and I'd prefer
to keep it that way.

What we could is make use of the '--with-cpu=NAME' flag in the linker,
this would allow the choice of the default linker script to be moved
into the arc only section of ld/configure.tgt, and would remove the
need for a generic configure switch.  So we've have something like
this (not a patch, just a rough plan):

    arc*-*-linux*)
        case "${with_cpu}" in
            nps400)
                target_emul=arclinux_nps
                targ_extra_emuls="arclinux"
                ;;
            *)
                target_emul=arclinux
                targ_extra_emuls="arclinux_nps"
                ;;
        esac
        targ_extra_emuls="${targ_extra_emuls} arclinux_prof arcelf arcelf_prof arcv2elf arcv2elfx"

I might end up having to add some code to ld/configure.ac to make
--with-cpu=NAME visible in the ld configure script.... but how would
this look to you?

Thanks for your time reviewing this,

Andrew