Re: GDB is the GNU project's native debugger

[Andrew Cagney <cagney@gnu.org>]

Ian Lance Taylor wrote:

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

> When you talk about "attempt influence" I can't help but feel that you
> are exporting internal Red Hat dissension to the external world.  I've
> done plenty of embedded contract work, and frankly for most people
> getting the backend support into gdb is not all that important.  You
> just get one version of gdb working and stick with that for as long as
> you can--normally a few years.  (This has been somewhat broken
> recently as some new versions of gcc require new versions of gdb, but
> that was not historically the case--and indeed many people in the
> embedded world still use -gstabs+ when they compile to sidestep these
> problems).  I understand that within Red Hat things are different--Red
> Hat understandably tries to use a single source tree for both native
> and embedded work.

Red Hat, with it's GNU/Linux distributions (RHEL) uses a separate GDB 
rpm and not a combined source tree.  I also suspect that the contract 
engineering group you refer to ("Cygnus") are now rarely doing a GDB 
import, and are tending towards the model you describe.  If there were 
problems, I'm sure they would have been addressed.

What I do see is continuing pressure and lobying, some times comming 
from the most ironic of quarters :-)

Fortunatly, I also see a great deal of professionalism.  Embedded 
companies taking on the standards, meeting, and exceeding them.

Anyway, would it be useful if the process, as you describe it, was 
explicitly documented?

> My point is that in my experience, outside Cygnus/Red Hat, very few
> people's bottom line is affected by deprecating code or changing gdb
> internals.  So I think your point is wrong.

Andrew