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

[Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>]

Hi Nick,
 
>   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.

I need to confess that my description of the problem solved by my patch was not very verbose, which may led to misinterpretation. Hence, I need to apologies for this.

My proposal is orthogonal to the note proposal, and addresses situations when the compiler doesn't place the notes into the asm file or we have intermediate elf processing steps that are throwing or messing up with the note section. Hence, once a note solution will get in it will not runout the need for the solution proposed, as they may be old compilers which may not produce the newly introduced note section.

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

As far as I can see, it will not be replaced in the future, because, even if GNU-binutils will accept quickly the .note system, probably other tools (free or not) will slowly incorporate the new system. Moreover, if Andrew or others wants to come with their own .note implementation then, the need for my patch becomes more stringently.

> 
>   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 ?

The need is for Arduino 101 and future Intel chips which are using FPX/DSP/FPU mixes. Intel is using actively gnu for their products. At this moment they are using our Synopsys git based tools, but I would like Intel to use the mainline tools. We will have new GNU tools rolled out in couple of months, and I would like to offer them at least an alternative to get the right disassembler code.

>   [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].

That is my intention as well. 

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

I will add this feature for the (sub)classes which are conflicting (e.g., FPU/DSP/FPX).

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

I see a limitation here, we use multilib. So, even if we build with --with-cpu, we will have situations when we want to disassemble differently for a different ARC cpu. Also, the ARC cpus are templates and, basically, we do not know what instruction mix a customer will choose until they come back to us. Basically, --with-cpu selects a class of CPUs and not a precise implementation.

> 
>     * Note in the documentation and the --help output that the
>       subclass section option may be deprecated in the future.

See my first paragraphs, probably it will not be deprecated anytime soon and will co-exist with .note as well.

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

In my refurbish patch I did this as Andrew suggested, and it doesn't xfail but it just shows how a wrong encoding is chosen.

Thank you,
Claudiu