From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2874 invoked by alias); 5 May 2003 17:49:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2866 invoked from network); 5 May 2003 17:49:39 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 5 May 2003 17:49:39 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3861537; Mon, 05 May 2003 13:49:38 -0400 Date: Mon, 05 May 2003 17:49:00 -0000 Subject: Re: Deprecate dwarf and mdebug support, delete nlm? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tim Combs , Michael Elizabeth Chastain , gdb@sources.redhat.com To: Andrew Cagney From: Daniel Berlin In-Reply-To: <3EB69FCA.70409@redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00057.txt.bz2 On Monday, May 5, 2003, at 01:30 PM, Andrew Cagney wrote: >> I don't think its a fair measure to equate number of patches with >> value. > > The number of patches does at least hint at the level of activity. As > for value, part of a value judgment is determining the cost. > >> I've still got users who are using commercial compilers that emit >> dwarf1 and >> it would be a great loss to these users if dwarf1 went away. > > Significant structural change, such as adding support for multiple > address spaces, moves more rapidly when there are fewer debug readers > to content with. I think the real problem isn't the number of debug readers, but in the particular implementations of these two debug readers. IE The problem with these two debug readers is precisely that *because* nobody has ever maintained or updated them, anyone wanting to improve our debug reading in general by changing structures or whatnot, has to contend with the old, obsolete, and sometimes non-existent methods these 2 readers use to build the various data structures gdb uses. Had they kept up with the passage of time, i don't think we'd be considering obsoleting them, because they wouldn't be in the way. They are so far past bit-rotted that they have evolved into their own obscure species. > These users potential loss is someone elses potential gain. These > users can also continue to use an existing GDB. > > As someone (michael?) suggested, can these users move to Free > compilers? Nope, it was me who made the suggestion. The other possibility I mentioned is that the vendor in question will wake up and implement a debug format from the past decade (DWARF 2.0 standard was published July 27th, 1993).