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


Andrew Cagney <cagney@gnu.org> writes:

> To address this (since you mention code removal) I've (lets face it is
> me willing to put my neck on the line and drive this forward) set
> clear technical criteria such as:
> 
> > * END-OF-LIFE frame compatibility module
> > GDB's internal frame infrastructure has been completely rewritten.
> > The new infrastructure making it possible to support key new features
> > ....
> 
> or:
> 
> - it has't built for a full release cycle
> - it has't worked for a full release cycle
> 
> to identify code that can be removed.

I don't have a problem with removing specific target backends that are
not supported.  I don't agree with the length of time--I think it
should be something like "a full release cycle or one year, whichever
is longer."  But I agree that in principle removing a specific
non-functional backend is not problematic.

> While this is helping, the fact that it is only by taking such action
> the code gets maintained tells us we should go further setting a
> clearer bar: for instance requiring test results against each major
> release; or clarifying that architectural changes to GDB's core
> allowing better support for native GNU systems take priority over
> concerns that it might break embedded code.

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.

> > If you want to state that, where there is a direct and immediatete
> > conflict between the needs of GNU systems and the needs of other
> > systems, the needs of the GNU systems take priority, I could support
> > that.
> 
> In addition, many people (including I) are now in a situtation where
> their financial future is in part dependant on their ability to work
> on GNU software.  As such they are finding that this conflict directly
> affects their, or their peers, bottom line.  A manouver that
> influences the timing of a decision to deprecate (new code can't use)
> or end-of-life (removing) a mechanism or accept/reject a change has
> the potential to either cost or save these embedded / contract
> engineering companies and their employees 10's if not 100's of
> thousands of dollars.
> 
> (Having worked in both GNU native and enbedded contract engineering, I
> can confidently state that the embedded side is brutally cut throat
> and far more likely to attempt influence.  This is also why when
> accepting a new architecture or system I've tried to set clear
> consistent acceptance criteria).

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.

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.

That's not to say that I am opposed to clear consistent acceptance
criteria for new backends.  Of course that is a good idea, and gcc
(which I think is clearly successful and should generally be the model
for this sort of development, as I've said before) has that as well.

> > If you want to state that this applies to considerations of resources,
> > and of which parts of gdb to mark obsolescent, I could not support
> > that.
> 
> I'm not sure what you mean.

I mean what I said in my second paragraph above, the one about the
"clarification."  In particular, it's very easy to apply a broad,
generally accepted statement in ways which are not, in fact, generally
accepted.

Ian


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