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

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

> I am glad that you are looking at this issue.  This is something I
> have been thinking about recently too.

I am glad to hear it.

> Please, correct me if I have miss-understood, but the way this patch
> solves the problem is that you maintain a list of instruction subclasses
> that are known to overlap in `is_compatible_p', then, the first time
> you encounter an instruction from one of the conflicting subclasses,
> you record that sub-class as being the one in use, and don't then
> present instruction from the other conflicting subclass.

Correct. It is just a heuristics which is intended to work without too much interaction from a user, and also it will keep consistent the encoding class chosen among the disassembled code. Hence the use of word "improve" in my intro letter.

> This relies I think on spotting a non-conflicting instruction first
> right?  If the first instruction you find is a conflicting one, and
> you happen to pick the wrong subclass then you'll be stuck using the
> wrong subclass for the rest of the disassembler run.

Right.

> I think that as a minimum, if we pursue this as a solution, then you
> will need to add an override mechanism to the disassembler to allow
> the instruction subclasses to be selected.  Under the current scheme,
> if you have a binary for which the disassembler gets it wrong, then
> your stuck.

That crossed my mind, and I will gladly add a couple of those switches. Though I am not a fun of those as the users are tending to ignore them.

> I also think that if you stick with the current scheme then you should
> include at least one example of a place where the disassembler gets it
> wrong, and mark this as an XFAIL in the testsuite.  This would make it
> easier if anyone wanted to improve things later.

An XFAIL example may make sense after all.

 > That said, I feel that we should probably consider an alternative idea
> first.  Many of the other targets embed information into the generated
> ELF file to indication which instruction set was used in the assembler
> (ARM, and x86 both do this)  I think that ARC should do the same.

We already had some talks earlier this year about this issue as far as I remember. That is indeed our direction to go for midterm with the ARC tools. However, we are evaluating/reviewing internally this ABI change and we would like to make those changes consistent among our tools ( which are not only GNU). Hence, it is too early to craft an implementation here, as it will be just incompatible with the upcoming ARC ABI change. Thus, although it sounds very appealing, we need to hold our horses until the ABI mods are agreed upon.

Bottom line: I will make a new proposal of the current patch where I add the switches and the XFAIL test.

Cheers,
Claudiu