This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] [ARC] Improve filtering instructions while disassembling.
Right - I think that I have to step in here.
I believe that what Andrew was trying to say is that it is a poor
idea to implement Claudiu's proposed solution to this problem if
Synopsis are already working on a better solution that will be
made available in the future. Unless, that is, there is an
urgent need for a solution right now.
The point being that the current proposed solution does have
limitations, and that we do not want to user's to become accustomed
to it, if it is just going to be replaced in the future.
So - Claudiu, Cupertino - is there a need for this solution to go
in now ? Would it impact the ARC user community if we wait for
your note-based ABI solution to be ready ?
[As an aside, you might want to consider the binutils community
as a good place for reviewing proposed ABI changes like this. I
think that there is a lot of experience here in working with ABI
tags and notes in general].
If the proposed patch were to go in then I think that it would
need a few changes to make it acceptable. Specifically:
* Make the selection of a subclass mandatory.
Ie if the disassembler encounters an encoding with multiple
potential decodings and it has not been told which subclass
to use, then it should issue an error message (or maybe a
warning) asking the user to provide the correct command line
The exception to this would be if the toolchain has been
built with the --with-cpu=ARCxxx option specified on the
configure command line. Currently this option is only
interpreted by GAS, but it could/should be extended to the
opcodes library to provide a default for disassembly.
* Note in the documentation and the --help output that the
subclass section option may be deprecated in the future.
* If the disassembler can produce the wrong output, then
include a testcase that does this, to remind us that the
problem needs to be addressed. I do not think that this
test should be XFAILed however, as although the failure
might be expected, its purpose is to remind us that there
is a problem and that it needs to be fixed.