From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27383 invoked by alias); 11 Jul 2008 17:04:31 -0000 Received: (qmail 27376 invoked by uid 22791); 11 Jul 2008 17:04:30 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 17:04:13 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6BH4B9g020938 for ; Fri, 11 Jul 2008 13:04:11 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BH4Bow008193; Fri, 11 Jul 2008 13:04:11 -0400 Received: from localhost.localdomain (vpn-12-215.rdu.redhat.com [10.11.12.215]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BH48c5029774; Fri, 11 Jul 2008 13:04:09 -0400 Message-ID: <48779286.600@redhat.com> Date: Fri, 11 Jul 2008 17:04:00 -0000 From: Sami Wagiaalla User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: tromey@redhat.com CC: Frysk List Subject: Re: Changes References: <48755276.2020801@redhat.com> In-Reply-To: <48755276.2020801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00022.txt.bz2 >> * 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