This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/


On Thu, Jan 16, 2003 at 09:27:12AM -0500, Fernando Nasser wrote:
> Daniel Jacobowitz wrote:
> >>
> >>>From the gdb user's point of view, a bug is a bug.  A gdb user can do
> >>the same thing as the test suite and then file a PR: 'gdb fails to
> >>print 'const' for const types'.
> >
> >
> >I'm not sure I agree with this.  My point of view was that either it's
> >an expected bug (environment) or it is a "known bug in the tool being
> >tested".  I don't like calling environment bugs KFAILs.  Do that, and
> >we'll just end up with no XFAILs...
> >
> >Associating a PR with them is a different issue.  Just because we
> >associate a PR doesn't mean we have to use KFAIL.
> >
> 
> That is correct.  The last argument of a setup_xfail, if it does not 
> contain '-' (Argh!  Don't blame me, it was already there since immemorial 
> times) is the PR number.  It can easily be a gdb/NNN bug id.  We cannot 
> enforce the syntax, but we can enforce it as a police.

[Last or first?  Oh, the answer is "either" according to framework.exp.]

> So, to address Michael's concerns, we could open a WONTFIX bug report (is 
> there such category?  This is the Bugzilla one) saying that it is a GCC or 
> whatever bug and outside of our control and add the id to the setup_xfail.

We could use the Suspended state for this, and we could just assign
them to a new environment/ category...

> Why doing this?  A script can go through the KFAILs (for each platform) 
> and, by reading the Gnats database, automatically create a KNOWN BUGS man 
> page section, or a section of a Release Notes document.  Using the same 
> principle, it can go through the XFAILs and generate a section of known 
> limitations _on a specific environment_ (the one where the test results 
> were obtained).
> 
> Regards,
> Fernando
> 
> P.S.: Does someone know how to programatically access the Gnats database?

Yes; the GNATS software package includes a number of remote tools,
particularly nquery-pr.  You have to find a copy of GNATS 3.x; the 4.x
tools don't interoperate with the version on sourceware.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]