This is the mail archive of the binutils@sourceware.org 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] |
Hi Nick, > I am not sure that this patch is a good idea. What happens if the tools > (readelf, objcopy, objdump, etc) are used on an old binary that still has > the old E_ARC_MACH_NPS400 value set in the ELF flag bits ? Presumably they > won't recognise it. If there is a possibility that these old binaries exist > then we must maintain backwards compatibility for them. I think that the possibility that there are existing binaries around that use the E_ARC_MACH_NPS400 value is quite remote - this value was only added recently (since the 2.26 release). I think that for someone to have created NPS-400 binaries with this value, they would have had to have checked out and built from binutils master, but I don't think this is likely since the implementation for NPS-400 in master is still incomplete (missing many instructions). Because of this, anyone needing to build code for an NPS-400 will be using an implementation of the toolchain provided by Mellanox/EZChip, which never generated binaries with the E_ARC_MACH_NPS400 value - it always used the E_ARC_MACH_ARC700 value. With that in mind, I was hoping that we could correct this "mistake" of ever adding E_ARC_MACH_NPS400 before the next release, so that there isn't a release version that ever generates binaries with this value. Given the current situation, could it still be appropriate to remove the E_ARC_MACH_NPS400 value? Many thanks, Graham.
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |