Re: [PATCH] [ARC] Improve filtering instructions while disassembling.

[Nick Clifton <nickc at redhat dot com>]

Hi Everyone,

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

      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.

Cheers
  Nick