This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH] [ARC] Improve filtering instructions while disassembling.
> Hmm, so how do you ensure that the user does not attempt to link an
> application intended for one particular ARC variant with a library
> built for a different ARC variant ? Or is this something which is
> not currently addressed, but which the ABI notes are intended to
> address ?
That is the current problem, which we try to avoid using the .note. At this moment, we make a very raw selection between various architectures ARC6xx, ARC7xx, ARCHS, and ARCEM based on e_flags and friends. However, even added .note will not fully solve the issue as there may be programmers tring to link objects which are incompatible. For example, libraries obtained with Synopsys payed compiler with gnu build object. Hence, though .note seems to solve all the problems it doesn't until all ARC elf producing/consuming tools are aligned to this standard. Thus, my quest for standardization among all ARC tools free or not.
> Umm, so does that mean that the meaning of ARC opcodes can be changed
> on a per-customer basis ? Isn't that going to make correct disassembly
> almost impossible if the tool has not been customised for that particular
> customer ? (Sorry about the pun).
That is possible, although some of our customers are hiring people like Andrew to place their custom ops/ or custom configuration into mainline and correct this deficiency. Others are just happy with extinstruction pseudo-op and friends to add support for their custom insns.
> Also - with multilibs you have to select the desired CPU variant using
> a command line switch when compiling right ? So a [multilib experienced]
> user will already be familiar with the idea of selecting a cpu, and adding
> an option to objdump (to override a default set up by the --with-cpu) will
> hardly be a difficulty for them.
>From gcc point of view, they are used to pass the options combinations to the driver, but sometime we teach them to build the toolchain only for a particular configuration. Hence, everything works without the switches. It really depends on how much a customer wants to be involved in gnu building process. Like, I just want to use a prebuild toolchain versus I want to have my toolchain to match my custom configuration.