From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12428 invoked by alias); 1 Dec 2002 23:19:06 -0000 Mailing-List: contact rda-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rda-owner@sources.redhat.com Received: (qmail 12392 invoked from network); 1 Dec 2002 23:19:04 -0000 Date: Sun, 01 Dec 2002 15:19:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Pierre Muller , rda@sources.redhat.com, gdb@sources.redhat.com Subject: Re: [ADMINISTRIVIA] New RDA mailing list Message-ID: <20021201231925.GA16409@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Pierre Muller , rda@sources.redhat.com, gdb@sources.redhat.com References: <5.0.2.1.2.20021127095625.02489ac0@ics.u-strasbg.fr> <3DE4E23E.5000104@redhat.com> <20021201212149.GC12876@nevyn.them.org> <3DEA91A9.6010009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEA91A9.6010009@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-q4/txt/msg00010.txt.bz2 On Sun, Dec 01, 2002 at 05:48:09PM -0500, Andrew Cagney wrote: > > >>No. GDBSERVER is part of GDB (which is part of the FSF's GNU project) > >>and it should continue to be discussed here. > > > > > >I really wish we could come to some resolution about the overlap. > >Should we sacrifice the FSF-owned gdbserver project in favor of > >extending RDA? As it is, there's a substantial amount of duplicated > >effort. I hate seeing effort wasted. > > gdb/gdbserver/ is the FSF's (and hence GDB's) remote debug agent. There > is no benefit to the FSF, and its objectives, in replacing something (C) > FSF with something (C) Red Hat. There is no benefit to the community in having a publicly developed RDA that I can see. Right now I don't believe it has any features that gdbserver doesn't, although I could be wrong - I only checked briefly - I know that it used to have threads support when gdbserver didn't but we implemented that before RDA was released. And now Red Hat employees can contribute things like tracepoint support to the community by adding them to the (c) Red Hat RDA, when the community would benefit as much or more having them in gdbserver. So we get two stubs with mostly-overlapping but different feature sets. Obviously Red Hat doesn't want to drop RDA in favor of gdbserver. But having gdbserver as a second-rate cousin until someone spends weeks playing feature catchup with RDA (e.g. I or someone else finds the time to implement the introspect stuff in gdbserver, if I can even do it...) does no one but Red Hat any good. I'm sorry to keep harping on this unpleasant subject, but it really irks me. There's a gdbserver project out there to contribute to. It was in bad shape; I like to think we've put it back together now! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer