From: Andrew Cagney <cagney@gnu.org>
To: Ian Lance Taylor <ian@wasabisystems.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB is the GNU project's native debugger
Date: Wed, 17 Nov 2004 01:24:00 -0000 [thread overview]
Message-ID: <419A9BBE.6010000@gnu.org> (raw)
In-Reply-To: <m3y8h1snmn.fsf@gossamer.airs.com>
> 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
next prev parent reply other threads:[~2004-11-17 0:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-16 17:14 Andrew Cagney
2004-11-16 17:26 ` Paul Breed
2004-11-16 17:35 ` Kris Warkentin
2004-11-16 20:09 ` Mark Kettenis
2004-11-16 17:50 ` Ian Lance Taylor
2004-11-16 21:48 ` Eli Zaretskii
2004-11-17 1:24 ` Andrew Cagney [this message]
2004-11-17 1:53 ` Ian Lance Taylor
2004-11-17 22:59 ` Andrew Cagney
2004-11-19 5:05 ` Ian Lance Taylor
2004-11-19 7:19 ` Kip Macy
2004-11-30 16:26 ` Andrew Cagney
2004-12-07 14:46 ` Ian Lance Taylor
2004-11-16 18:11 ` Dave Korn
2004-11-16 18:33 ` Ian Lance Taylor
2004-11-16 18:43 ` Dave Korn
2004-11-16 18:47 ` Ian Lance Taylor
2004-11-16 19:59 ` Mark Kettenis
2004-11-17 0:31 ` Steven Johnson
2004-11-16 19:30 Paul Schlie
2004-11-16 19:51 Paul Schlie
2004-11-16 21:11 ` Paul Breed
2004-11-16 23:58 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=419A9BBE.6010000@gnu.org \
--to=cagney@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=ian@wasabisystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).