From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1560 invoked by alias); 17 Jan 2003 19:57:25 -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 1553 invoked from network); 17 Jan 2003 19:57:24 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 17 Jan 2003 19:57:24 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h0HJvMu05896; Fri, 17 Jan 2003 13:57:22 -0600 Date: Fri, 17 Jan 2003 19:57:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301171957.h0HJvMu05896@duracef.shout.net> To: ac131313@redhat.com, carlton@math.stanford.edu Subject: Re: GDB `cannotfix' pr state, require PR with xfail `moving forward'. Cc: gdb@sources.redhat.com X-SW-Source: 2003-01/txt/msg00324.txt.bz2 David C writes: > Should all xfail bug reports be with reference to GDB's database, or > are references to external databases allowed? I kind of like the > former (though, presumably, the bug report in GDB's database might > well reference a bug in an external database). Me too. > The only categorization glitch that I'm worried about is: what if > there are external issues that can't be fixed? (E.g. limitations in a > certain debug format.) I suppose Michael Chastain's answer there > would be to not run the test at all in that situation. If you can't fix it, document it. Also I think it's okay for gdb to say "I can't do that" if it knows that it can't do something. Here's a concrete example: several users have filed bug reports that they can't debug C files with 100,000 lines of C code. (This happens if you use a program generator to generate C code from some other language). It turns out that they are using stabs+, and stabs+ has a 16-bit field for line numbers, and gas was quietly truncating the high bits. The problem manifests in gdb, but there's nothing gdb can do. gdb can't even warn about the problem without some flaky heuristic test that I don't want to consider (noticing the line numbers jumping around is problematic because it's legal for line numbers to do that in machine-generated code). So ... I would file a PR against the assembler, asking them to issue a warning or an error when this happens. binutils 2.13.2.1 does this now so that is okay. Then I would add some doco on the various debug formats that gdb supports and common issues that users encounter. We know the common issues that users encounter because we monitor the gnats database and the 'gdb' and 'bug-gdb' mailing lists. Michael C