This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH ARC 3/8] GAS: new ARC port

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]