This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH ARC 3/8] GAS: new ARC port
- From: Claudiu Zissulescu <claziss at gmail dot com>
- To: Nick Clifton <nickc at redhat dot com>, Binutils <binutils at sourceware dot org>
- Date: Fri, 4 Sep 2015 18:35:40 +0200
- Subject: Re: [PATCH ARC 3/8] GAS: new ARC port
- Authentication-results: sourceware.org; auth=none
- References: <1441282821-24854-1-git-send-email-claziss at gmail dot com> <CAL0iMy3mjK19TOka+y5UvNHf4D4bmgpTcw0cCAh9JipWvyoRDg at mail dot gmail dot com> <55E9B2A7 dot 7090609 at redhat dot com>
>>> -#define E_ARC_MACH_ARC5 0
>>> -#define E_ARC_MACH_ARC6 1
>>> -#define E_ARC_MACH_ARC7 2
>>> -#define E_ARC_MACH_ARC8 3
>>> +#define E_ARC_MACH_ARC600 0x00000002
>>> +#define E_ARC_MACH_ARC601 0x00000004
>>> +#define E_ARC_MACH_ARC700 0x00000003
> With these changes to the machine flag bits will you end up with
> incompatibilities between binaries generated by the old gas and the new
> gas ? Eg if an ARC700 binary was produced by the old gas it will have a
> value of 2 in the e_flags field, but if it is produced by the new
> assembler it will have a value of 3 ...
I am here between bad and worst situations. All our (official) clients are using the binutils tools provided via the Synopsys' Github account: https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb. The choice for those e_Flags values are done before my time in the office, and I have no one to ask about that decision.
Do u think it will be unacceptable to go with the new proposed values further?