This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB is the GNU project's native debugger
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