GDB is the GNU project's native debugger

[Andrew Cagney]

> 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