This is the mail archive of the
mailing list for the binutils project.
Re: [PATCHv3 0/7] Add initial arc nps400 support
- From: Andrew Burgess <andrew dot burgess at embecosm dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: binutils at sourceware dot org, Claudiu dot Zissulescu at synopsys dot com, Cupertino dot Miranda at synopsys dot com, noamca at mellanox dot com, Nick Clifton <nickc at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Thu, 17 Mar 2016 17:15:01 +0000
- Subject: Re: [PATCHv3 0/7] Add initial arc nps400 support
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1456947552 dot git dot andrew dot burgess at embecosm dot com> <cover dot 1458082098 dot git dot andrew dot burgess at embecosm dot com> <56EAD80B dot 10200 at redhat dot com>
* Pedro Alves <email@example.com> [2016-03-17 16:15:07 +0000]:
> On 03/15/2016 11:01 PM, Andrew Burgess wrote:
> > Here's a rewrite that removes the need to use the vendor string in
> > order change the behaviour of binutils.
> >  I still don't understand why that's a bad thing though....
> In an --enable-targets=all world, you need to be able to select
> any supported target at run time. Thus, IIUC, in the vendor string
> version, an --enable-targets=all build wouldn't include
> nps400 support, unless you also specified the primary
> target as --target=arm-mellanox.
> Nowadays, the vendor/manufacturer string is meant to be free
> form, and set by whoever builds the tools to whatever they
> like, for branding purposes and $PATH coexistence.
Thanks for the explanation. And remembering that I've already updated
the patch, so I ask only out of interest...
... I still think that allowing the vendor string to control some
defaults would be nice. So in my case it would be great if the
default architecture for an arc-mellanox toolchain was nps400, from a
user PoV that seems like it would be a nicer experience .... maybe.
Anyway, thanks again for the explanation,