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:


GDB is the GNU project's native debuger.  While we're certainly happy
to accomodate people using GDB as either an embedded debugger or
native debugger on other systems, the need to persue GDB as a native
debugger on GNU systems must be our first priority.

Do we all agree with this?


While I think we all agree with this in some sense, I think you should
spell out where you are going with this.

For example, it would be easy to use this statement as the motivation
for removing features required for using gdb for embedded systems, or
on Windows.  I don't think that would be appropriate.

I think this first needs a little context.


One group, the embedded companies have found that with very little effort (I believe the guesstimate is ~6 weeks) they can add an architecture to GDB, leveraging themselves a very powerful debugger. This work is typically contracted, and once the money dries up all incentive to further develop that code disappears.

This creates a very on-sided relationship. The embedded targets get all the cool features of GDB while the native developers get to "support" (i.e., maintain) it.

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.

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.

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).

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.


Andrew


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