This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Please allow me to give my personal opinion about this reply.

On 07/15/2016 10:44 AM, Andrew Burgess wrote:
> 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.
Although the patch is not mine I feel a little insulted with this first
3 paragraphs.

The reality is that we have never based our code decisions on any other
toolchain or non-GNU project. And your statements are purely fictional
and/or imaginative.

Claudius statement about consistency with other tools, is only at ABI
level and does not impact in any way what binutils implementation is
performed. Saying that it does, would mean the same as saying that we
would implement ARC binutils support without taking into consideration
the ARC architecture decisions, or upcoming targets variations.

> 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.
Although we would like to reach a perfect implementation at the first
run, that is the Nirvana each and every programmer tries to reach.
In my opinion as long as the patch improves upon what was the previous
state of the tools it should be considered an improvement, and welcome
by the GNU community.

On the other hand, if you have a better solution for the problem, and
you are willing to contribute to fix the problem, please show us what
you have and when will you be able to contribute.
We will make sure, that everyone is able to contribute to this target

Best regards,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]