Re: GDB `cannotfix' pr state, require PR with xfail `moving forward'.

[Michael Elizabeth Chastain <mec@shout.net>]

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