Re: GDB is the GNU project's native debugger

[Ian Lance Taylor <ian at wasabisystems dot com>]

Andrew Cagney <cagney@gnu.org> writes:

> > The "clarification" in the last clause is not clear at all, and will
> > vary a great deal in the eye of the beholder.  One person's
> > architectural change allowing better support is another person's
> > arbitrary change requiring pointless busywork.  Who is responsible for
> > that busywork--the person making the change, or every single backend
> > maintainer?  These questions are not resolved by a general statement
> > in favor of supporting GNU systems.
> 
> 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