public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Tom Tromey <tromey@redhat.com>, Frysk List <frysk@sourceware.org>
Subject: Re: Roadmap beginnings
Date: Mon, 14 Jul 2008 16:58:00 -0000	[thread overview]
Message-ID: <487B85AD.30606@redhat.com> (raw)
In-Reply-To: <20080714164531.GA6283@caradoc.them.org>

Daniel Jacobowitz wrote:
> On Mon, Jul 14, 2008 at 10:33:48AM -0600, Tom Tromey wrote:
>   
>> Thanks in particular for your comments on the particular C++ work
>> items.  

Yes thanks, good to have as much input at possible.

>> I think those combined form a pretty powerful argument.
>> There's still some unaddressed though:
>>
>> * Multi-process.  I've seen some hints on the list that this is
>>   coming, but not enough info to really understand.  This seems like
>>   something that would affect many areas -- there would seem to be
>>   challenges from the CLI on down.
>>     
>
> Yes.  I can say that CodeSourcery is working on this, and I fully
> expect to have an implementation posted by ... say ... mid-October.
> Focus is likely to be on MI, though it will certainly be somehow
> CLI-accessible.  We plan to do the work (or at least the design) in
> public; if anyone wants to help...
>   

Being a definite newbie to GDB, how does the community reconcile the 
multiple and large changes that are being discussed, and implement them 
into a stable release base? To an outsider they all seem to be 
converging at once. I know "move to C++" and "multi-process" are 
orthogonal, but they have to exist in the same working code-base. If the 
C++ stuff happens, and it just so happens this new multi-process 
functionality is introduced, what then? Will C "only" patches be 
discouraged? These questions might be better suited to the the GDB list, 
in fact, but I'm curious with all these changes how they will be managed.

> One thing that might benefit GDB is for someone to sit down and come
> up with a few new-approach-to-debugging features like these.  Stick
> them up on the wiki or something...
>
> A nice thing about new features is that they're shiny, a.k.a. a good
> draw-in for new contributors.
>   
When one implements a new feature that has architecture specific 
components, is it the job of the new feature-implementer to implement 
these for as many architectures as possible? Does he champion the cause 
of other folk to go ahead and contribute for their chosen architecture? 
Or is it more of an approach of: "Here is a new feature, this is the 
architecture I implemented it on, lets review if it can work for others?"

Regards

Phil

  reply	other threads:[~2008-07-14 16:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:53 Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon [this message]
2008-07-14 17:09         ` Daniel Jacobowitz
2008-07-14 17:19     ` Ian Lance Taylor
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon

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=487B85AD.30606@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=drow@false.org \
    --cc=frysk@sourceware.org \
    --cc=tromey@redhat.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).