public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Sami Wagiaalla <swagiaal@redhat.com>
To: tromey@redhat.com
Cc: Frysk List <frysk@sourceware.org>
Subject: Re: Changes
Date: Fri, 11 Jul 2008 17:04:00 -0000	[thread overview]
Message-ID: <48779286.600@redhat.com> (raw)
In-Reply-To: <48755276.2020801@redhat.com>


>> * GDB.  A recurring question is: why not expend our efforts improving
>>   gdb?  There are no easy answers here; the tradeoffs are complicated.
>>
>>   This is probably more of a Red Hat internal decision (it is about
>>   where we want to focus our efforts, not about the frysk project per
>>   se) -- but it is an obvious and important question and deserves to
>>   be brought up here.
>>
>>   We're open to arguments either way on this topic.  Given our goals,
>>   what would you choose to do?
>>
> 
> I would choose to not work on GDB. I think it would be difficult to get 
> our patches upstream especially ones as radical as we will propose, and 
> rightly so. If you send a patch to gdb that implements a thread state 
> machine for example, how would gdb maintainers know what effect this has 
> on all the permutations of archetecutre, language, and executable 
> formats that gdb supports ?
> 
> Any points which I have not responded to I have no objects or comments on.
> 

I want to add that I think that even if we work against the current and 
get a solution in a close time line. I dont think that we can achieve 
our extensibility goals our architectural design as I understand is 
completely different and achieves extensibility well.

I also want to say that we should reuse whatever code we can from gdb 
that is stable and mature and can be used as a black box. For example 
while visualizing c++ data structures is an open ended problem, there 
arnt many ways you can revolutionize unwinding. So even if the code is 
ugly but doesn't need to be extended nor debugged go for it.

Sami

  reply	other threads:[~2008-07-11 17:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-09 22:19 Changes Tom Tromey
2008-07-10  0:06 ` Changes Sami Wagiaalla
2008-07-11 17:04   ` Sami Wagiaalla [this message]
2008-07-10  4:17 ` Changes Thiago Jung Bauermann
2008-07-10  5:43   ` Changes Sami Wagiaalla
2008-07-10 13:14     ` Changes Rick Moseley
2008-07-10 13:26       ` Changes Phil Muldoon
2008-07-10 17:07       ` Changes Eric Bachalo
2008-07-10 19:43   ` Changes Dodji Seketeli
2008-07-11 16:55   ` Changes Tom Tromey
2008-07-10  8:24 ` Changes Phil Muldoon
2008-07-11 10:44 ` Changes Phil Muldoon
2008-07-17  7:51 ` Changes Jan Blunck

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=48779286.600@redhat.com \
    --to=swagiaal@redhat.com \
    --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).