From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7160 invoked by alias); 4 May 2003 06:43:29 -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 7153 invoked from network); 4 May 2003 06:43:28 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 4 May 2003 06:43:28 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b4) with ESMTP-TLS id 3840477; Sun, 04 May 2003 02:43:28 -0400 Date: Sun, 04 May 2003 06:43: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: ac131313@redhat.com, gdb@sources.redhat.com To: Michael Elizabeth Chastain From: Daniel Berlin In-Reply-To: <200305040610.h446Aa9D005783@duracef.shout.net> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00035.txt.bz2 On Sunday, May 4, 2003, at 02:10 AM, Michael Elizabeth Chastain wrote: > I've been waiting for DWARF 1 to come up. Here are some random facts: > > I've run the test suite with -gdwarf and -gdwarf+. My results were > 40+ ERRORs and 3400+ FAILs. > > In gcc 3.2.2, these targets prefer DWARF 1: > > i[34567]86-dg-dgux* > i[34567]86-sequent-ptx4* > i[34567]86-sequent-sysv4* This was scheduled to be obsoleted in 3.1, actually, I don't knwo what held it up. Quote a former member of sequent's compiler group (Janis Johnson): "On Mon, Apr 15, 2002 at 10:05:42AM -0700, Zack Weinberg wrote: > > There are a LOT of weird proprietary-Unix m68k and i386 ports. Would > someone more familiar with the history care to look through this list > and suggest more culls? > > i?86-sequent-sysv3* > i?86-sequent-sysv4* > i?86-sequent-bsd* > i?86-sequent-ptx1* > i?86-sequent-ptx2* These can probably all be dropped. Most of them are for operating systems that Sequent stopped supporting many years ago. The most recent, ptx2, wasn't upgraded for Y2K changes and hasn't been supported since." These weren't removed in 3.1 for no reason that i can tell (probably forgot), since nobody said to keep them. *All* the sequent targets (not just those in the email above) are scheduled to go in 3.3. > m88k-dg-dgux* > mips-sni-sysv4 > sparc-hal-solaris2* All of these are scheduled for deprecation in 3.3, which means nobody has been maintaining them for *quite* a while. > <2.95> list omitted If you guys want to support something because 2.95 does, feel free, but realize that the gcc team (me included) will close bug reports against 2.95.x where it's been fixed in a later version. So if you find some DWARF1 generation bug fixed between 2.95.x and now, the only options gdb has are either to work around it (thus increasing the burden of maintaining DWARF 1), or to mark it as wontfix. So i don't really see the point here in caring about targets on branches that are guaranteed to never see another release. > The real hang-up is non-gcc compilers that emit DWARF 1. It's not like DWARF-2 (or even STABS) is all that *new*. If we were talking about vendors only having a year or two to have added support for DWARF-2 that's one thing. But at this point, do you really think the remaining DWARF 1 only vendors are going to up and decide it's a good idea for them to *ever* move off DWARF 1 unless something drastic happens? Like say their GDB using customers who now can't use new GDB's threaten to switch to another compiler (since there aren't that many debuggers out there)? It could be a good thing too, if they switch to using free software like gcc because the vendor decides not to support anything but DWARF 1, customers be damned. Then again, this is probably just your typical "I'm doing this for your own damn good, you just don't know it yet, you should thank me" bullshit. :P Besides that, whether or not some non-free compiler emits DWARF 1 is irrelevant to supporting DWARF 1 in gdb. We don't care about non-free compilers, remember? If it's a burden to gdb to maintain, remove it. If it's not, keep it. > > I recall seeing two instances of that in bug reports in the past year, > but I don't have URL's handy. > > Michael C