From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31427 invoked by alias); 5 May 2004 05:57:09 -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 31420 invoked from network); 5 May 2004 05:57:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 5 May 2004 05:57:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i455v8kG008601 for ; Wed, 5 May 2004 01:57:08 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i455v5v31335; Wed, 5 May 2004 01:57:06 -0400 To: Kean Johnston Cc: "Nathan J. Williams" , Andrew Cagney , Michael Elizabeth Chastain , ezannoni@redhat.com, gdb@sources.redhat.com Subject: Re: Phasing out Dwarf 1? References: <20040503155621.CF3194B104@berman.michael-chastain.com> <4097B8C6.10805@gnu.org> <4097CE64.4040101@sco.com> From: Jim Blandy Date: Wed, 05 May 2004 05:57:00 -0000 In-Reply-To: <4097CE64.4040101@sco.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-05/txt/msg00032.txt.bz2 Kean Johnston writes: > > This seems like a poor argument. The availibility and suitability of > > modern GCC for building GDB does not imply that modern GCC will be > > suitable for building the application to be debugged. > > I agree. I think phasing out a whole debugging format > is ill-advised. Most people dont want to keep around > multiple versions of a tool. If I need to debug an > old binary becuase the libc I replaced today is breaking > something, I think I have a reasonable expectation of > being able to do so. I think it is quite appropriate to > phase out the *generation* of said format, but not its > interpretation in a debugger. You're assuming it's basically free to keep Dwarf 1 support in GDB. I don't think that's the case. If someone wants to work on the interfaces the debug readers use to the format-independent portion of GDB, then the Dwarf 1 reader is one more client of those interfaces to take into account. If you look in the ChangeLogs, you can see that dwarfread.c continues to require periodic tweaks. But these are almost all mechanical changes that somebody found by 'grep', or things the compiler caught. How many bugs have been introduced by semantic shifts elsewhere in GDB that the compiler has been unable to detect? I'll bet there are a lot. In these circumstances, it seems like wishful thinking to say that GDB supports Dwarf 1. I would be happy if either: - a volunteer were to adopt the Dwarf 1 reader, test it regularly against any compiler (GCC or otherwise), and work on reducing the number of test suite failures it has over the more actively maintained readers, or - we were to delete the Dwarf 1 reader, and make it that much easier for people to do symtab work. But to leave the code there, with no active volunteers to keep it useful, is the worst of both worlds.