From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11722 invoked by alias); 25 Oct 2006 13:38:56 -0000 Received: (qmail 11710 invoked by uid 22791); 25 Oct 2006 13:38:55 -0000 X-Spam-Check-By: sourceware.org Received: from cirrus.netspace.net.au (HELO mail.netspace.net.au) (203.10.110.92) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Oct 2006 13:38:49 +0000 Received: from [192.168.0.10] (220-253-28-230.VIC.netspace.net.au [220.253.28.230]) by mail.netspace.net.au (Postfix) with ESMTP id 8F1FA170495 for ; Wed, 25 Oct 2006 23:38:46 +1000 (EST) Message-ID: <453F68E9.9050800@netspace.net.au> Date: Wed, 25 Oct 2006 13:38:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1 MIME-Version: 1.0 CC: gdb@sourceware.org Subject: Re: Gdb References: <453F0CA7.7070309@netspace.net.au> <20061025124921.GA15974@nevyn.them.org> In-Reply-To: <20061025124921.GA15974@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00238.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Oct 25, 2006 at 05:05:11PM +1000, Russell Shaw wrote: > >>There is far too much complexity for the simple things that gdb does. > > I just don't know what to do with this message. > > Yes, GDB is a bit crufty and could use some new design in places. But > calling the target control tasks "simple" is absurd. It is a typical > fallacy to assume that a task you are only lightly familiar with is > simple, when in fact most of the existing complexity is necessary. There are places with long sequences of: if() { ... } if() { ... } if() { ... } Instead of something more rigorous like: if() { ... } else if { ... } else if { ... } ... else { ... } This makes touching anything unpredictable, as there's too many combinations of possible code paths that may or may not be valid. That's only one small example. The code is not well modularized. It's hard to show that here. When a "run" resets a simple breakpoint, the stack depth is no less than 35 levels. It also invokes a tortuous 10-level trip thru various "memory set" functions until it eventually reaches target_xfer_partial or whatever, intermingled with re-reading symbol files, re-syncing dynamic libraries, and resetting breakpoints. >>If there's no plans to redo gdb, i'll do it anyway. > > You are welcome to submit individual patches which make areas of GDB > easier to understand. There are even some suggestions on the wiki. It's undoable by anyone not intimately familiar with the code which means weeks of prodding with a second gdb. The payoff is better in making something totally different and new.