[PATCH ARC 3/8] GAS: new ARC port
Nick Clifton
nickc@redhat.com
Mon Sep 7 15:44:00 GMT 2015
Hi Claudiu,
>>>> -#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:
> Do u think it will be unacceptable to go with the new proposed values further?
Hmmm, if the new values are already in use, then you had better stick
with them. The question is - do binaries built with the old sources (ie
prior to your patches) need to be supported ? This also leads to the
question - why is this new port being made ? What is wrong with the old
one ? If it is just a matter of supporting newer ARC variants, why
can't the old port be extended ?
If support for the old values of e_flags is needed then you are going to
have to implement a linker command line option that lets the user select
which flag bits to use. You may also need to extend that option so that
it can specify on a per-input-file basis whether the old or new values
should be used. (If you want to allow users to mix old and new binaries).
Cheers
Nick
More information about the Binutils
mailing list