Re: GDB is the GNU project's native debugger

[Kip Macy <kmacy at eventdriven dot org>]

I personally do not feel as strongly motivated by the GPL as many who
have or have at least tried to contribute to GNU software. However, I
also do not sympathize with those who strongly object to the GPL because
of the limitations it sometimes places on business use. It is the right
of those who have done the bulk of the work on a piece of software to
license it as they see fit. Thus I feel that I am fairly neutral in
this discussion.

One possible approach to discussing the difficult tradeoffs involved is
to take a page from legal discourse. Rather than speaking in terms of
"principles", talk about acceptance "criteria". To make their
application clear, you could create the moral equivalent of case law.
Create a document where you describe past issues such as async native,
frame handling, or architecture interface change, what the perceived
trade-offs were and why you made the decision that you did. This
document would be much more useful than wading through mail archives,
and it would make it easier, assuming you are self-consistent, to
justify future decisions.


			-Kip






On Thu, 18 Nov 2004, Ian Lance Taylor wrote:

> Andrew Cagney <cagney@gnu.org> writes:
> >
> > It's a complex problem and as such has middle ground and negotiation
> > dependant on the scale of the work:
> >
> > - Corinna recently changed an architecture interface and, since it was
> > straight forward, did the 'busywork'.
> >
> > - The frame code, on the other hand, was anything but straight
> > forward, it instead started with a single architecture and then
> > expanded as back end maintainers did their (much appreciated) stuff.
> > In the end though, a long list of architectures were simply deleted
> > (should I have instead done the 'busywork' of frameifying the ns32k?).
> >
> > Perhaps you can expand on your point by explaining where you would
> > strike up the balance for making an invasive change such as
> > asynchronous native (proc, ptrace) support.  GDB has many many
> > non-async embedded targets, but only two natives.  Should we predicate
> > the work on the modification of all the embedded inferiors?  Or should
> > we accept that the work is so key to GDB's future as a native that we
> > can tolerate a few short term problems?
>
> I think that in general you expanded on my point better than I could.
> As you say, it's a complex problem.  You are proposing a simple
> principle, and my concern is that once such a thing is adopted it will
> be used to enforce simplistic solutions to complex problems.  As I
> said before, the principle itself seems unobjectionable in many
> contexts.  My concern is that it will be applied in cases where it is
> too simple.
>
> Or, to put it another way: why do we need an overly simple statement
> about what we agree is a complex issue?
>
> On your specific issue, I think that async native support would
> require either a flag day or supporting two separate interfaces for
> some time.  A flag day is only acceptable if all major architectures
> can be converted simultaneously.  Off the cuff I would say that
> supporting two separate interfaces would have to last for at least a
> year.  Yes, this is hard.  Yes, it leads to more duplicated work.  A
> clean and elegant program is a goal, but it is not the only goal.
>
> > What I do see is continuing pressure and lobying, some times comming
> > from the most ironic of quarters :-)
>
> Well, you can make the lobbying public, or, since of course that may
> not be possible, you can ask for our input in an indirect fashion.
> I'm replying to the indirect query.  Naturally I don't have all the
> information which you have.
>
> > Anyway, would it be useful if the process, as you describe it, was
> > explicitly documented?
>
> I'm not sure it makes much difference, myself.  But on that question I
> may be too far on the inside, even though not a serious gdb developer.
> Perhaps for others with less historical knowledge, more documentation
> would be helpful.
>
> Ian
>