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

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com> [2016-07-15 08:07:53 +0000]:

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

It is good to know that you agree in principle about a better way to
solve this problem.

However, it concerns me that you feel GNU should accept a sub-standard
solution while some other non-free, non-GNU toolchain decides what it
wants to do.

I am all for compatibility wherever possible, but this project "just"
a free knock-off of some other toolchain, it is a first class project
in its own right, and deserves first class solutions to all problems
wherever possible.

Given that we can see this solution you propose is not the way to go
in the long term (and I think we agree there) then I disagree
_strongly_ that we should therefore accept a second rate solution in
the short term.

If there is a technical solution already being evaluated within
Synopsys, then we could hold off implementing a solution within the
GNU toolchain until Synopsys have made their choice.  However, if
there's a need for a solution now, and the desire to create a solution
then I don't think we should delay implementing that solution just so
we can fall in line with what some non-free toolchain may (or may not)
decide at some arbitrary date in the future.

Many thanks,
Andrew