This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] [ARC] Improve filtering instructions while disassembling.
* Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com> [2016-07-15 11:38:28 +0000]:
> > 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 really confuse here, what are the sub-standard solutions which
> are u referring to? And what is the GNU standard which you also
The sub-standard solution I am referring to here is the patch you
propose. I outline in my first mail why I don't think this is the
right approach to take, but in summary:
- it is not guaranteed to get the right answer
- it can silently select the wrong encoding
- there's an alternative that has precedent within the GNU toolchain
that will solve the above problems.
I am not invoking any standard. It doesn't have to be written down
that we should strive to have the best toolchain possible - that just
goes without saying.
> > 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.
> Not sure how to interpret this paragraph either. We (Synopsys) are
> in the process of upgrading the ARC ABI exactly for this reason: to
> get first class solutions always among all our toolchains. I do not
> understand on what basis you do the above accusations.
OK, so do your "upgrading", then propose a patch for the GNU
toolchain, we'll discuss that solution then.
I think the cause of the disagreement here can be seen in your choice
of the phrase "all our toolchains", the GNU toolchain is not yours,
it's not Synopsys's, if it's "belongs" to anyone I guess that would be
the FSF, but I'd prefer to think of it "belonging" to the community;
and you are not the only person, or company, who has an interest, and
a stake in the ARC components of that toolchain.
> > 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.
> Your opposition is noted. I have updated the patch using options,
> and this is solving the disassembler problem. The proposed solution
> is not unique among other backends, and hence, it cannot be neither
> called "second rate solution" nor out of GNU standards.
Could you reference the other backends please, then we can know that
we're examining the same targets.