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

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

[Andrew Cagney]

Hello,

There is currently a long thread (Remove all setup_xfail...)'s on 
gdb-patches@.  Several proposals, I think, can already be identified at 
this point in the discussion.

- yank the existing xfail PR markings (but not the actual xfails) (they 
apply to old internal Red Hat and HP bug databases and hence are 
meaningless).

- `moving forward' all new xfails, and all modifications to existing 
xfail's should include a bug report  (this way, new analyzed vs old 
unanalized xfail's can easily be differentiated).

- GDB have a new closed state `cannotfix'; or a new class `xfail' or 
`notabug' or ...; or even reuse the class `mistaken' that can be used to 
categorize xfail bug reports (not sure which is better here).

thoughts,
Andrew

PS: The state `willnotfix' was suggested.  I think that is wrong.  GDB 
shouldn't refuse to fix a real problem (just drop the priority to low), 
and here the problem is one of cannot fix.

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

[Andrew Cagney]

With revisions:

> There is currently a long thread (Remove all setup_xfail...)'s on gdb-patches@.  Several proposals, I think, can already be identified at this point in the discussion.
> 
> - yank the existing xfail PR markings (but not the actual xfails) (they apply to old internal Red Hat and HP bug databases and hence are meaningless).

Still stands.

> - `moving forward' all new xfails, and all modifications to existing xfail's should include a bug report  (this way, new analyzed vs old unanalized xfail's can easily be differentiated).

Still stands.

> - GDB have a new closed state `cannotfix'; or a new class `xfail' or `notabug' or ...; or even reuse the class `mistaken' that can be used to categorize xfail bug reports (not sure which is better here).

GDB has a new category `external'.  External bugs can either be 
`suspended' (I guess that implies that the bug is waiting on the 
external code to be fixed), or `closed' the external problem has been fixed.

Andrew

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

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 02:26:20PM -0500, Andrew Cagney wrote:
> With revisions:
> 
> >There is currently a long thread (Remove all setup_xfail...)'s on 
> >gdb-patches@.  Several proposals, I think, can already be identified at 
> >this point in the discussion.
> >
> >- yank the existing xfail PR markings (but not the actual xfails) (they 
> >apply to old internal Red Hat and HP bug databases and hence are 
> >meaningless).
> 
> Still stands.
> 
> >- `moving forward' all new xfails, and all modifications to existing 
> >xfail's should include a bug report  (this way, new analyzed vs old 
> >unanalized xfail's can easily be differentiated).
> 
> Still stands.
> 
> >- GDB have a new closed state `cannotfix'; or a new class `xfail' or 
> >`notabug' or ...; or even reuse the class `mistaken' that can be used to 
> >categorize xfail bug reports (not sure which is better here).
> 
> GDB has a new category `external'.  External bugs can either be 
> `suspended' (I guess that implies that the bug is waiting on the 
> external code to be fixed), or `closed' the external problem has been fixed.

Would an external defect relating to GCC 2.95.3, fixed in 3.2, be
marked "closed"?  This would be the one legitimate case for a failure
to refer to a closed bug report?  That seems reasonable at first blush.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[David Carlton]

On Fri, 17 Jan 2003 14:26:20 -0500, Andrew Cagney <ac131313@redhat.com> said:

>> There is currently a long thread (Remove all setup_xfail...)'s on
>> gdb-patches@.  Several proposals, I think, can already be
>> identified at this point in the discussion.
>> - yank the existing xfail PR markings (but not the actual xfails)
>> (they apply to old internal Red Hat and HP bug databases and hence
>> are meaningless).

> Still stands.

That certainly makes sense.

>> - `moving forward' all new xfails, and all modifications to
>>   existing xfail's should include a bug report (this way, new
>>   analyzed vs old unanalized xfail's can easily be differentiated).

> Still stands.

I'm not sure exactly what you mean by "moving forward", but if you
mean that all new xfails should have a bug report associated with
them, I think I agree with that.

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).

> GDB has a new category `external'.  External bugs can either be
> `suspended' (I guess that implies that the bug is waiting on the
> external code to be fixed), or `closed' the external problem has been
> fixed.

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.

David Carlton
carlton@math.stanford.edu

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

[Andrew Cagney]

>> GDB has a new category `external'.  External bugs can either be 
>> `suspended' (I guess that implies that the bug is waiting on the 
>> external code to be fixed), or `closed' the external problem has been fixed.

`GDB shall have', it doesn't :-)

> Would an external defect relating to GCC 2.95.3, fixed in 3.2, be
> marked "closed"?  This would be the one legitimate case for a failure
> to refer to a closed bug report?  That seems reasonable at first blush.

That's my guess.

Andrew

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

[Andrew Cagney]

> 
> - yank the existing xfail PR markings (but not the actual xfails) (they apply to old internal Red Hat and HP bug databases and hence are meaningless).

Just to clarify something here.  MichaelC wrote (on another thread):

 > ... you are talking
 > about 's/CLLbsNNNNN//', not 'g/CLLbsNNNNN/d'.
 >
 > I still think that's not useful in light of the progress we are
 > making but I would not be opposed to it happening.

`useful' doesn't come into this part of the equation.  Those references 
to an external bug database need to be removed.  The only thing up for 
negotiation on this one is the timing.

Andrew

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

[Eli Zaretskii]

> Date: Fri, 17 Jan 2003 14:28:01 -0600
> From: Michael Elizabeth Chastain <mec@shout.net>
> 
> Andrew C writes:
> > If the bug is fixed in GCC we might as well indicate this by closing our 
> > side of the bug report.  No reason to hang onto a bug report that has 
> > been resolved.
> 
> Does this include the XFAIL's for gcc v2 stabs+ in gdb.base/constvars.exp?
> 
> I really think that it's a year too early to close a gdb bug report
> with gcc 2.95.3 by saying "it works if you use gcc 3.X".

I agree.

I also think that if we introduce new bugs in some feature which did
support older compilers, that bug should be fixed, even if it's not
exposed by newer GCC versions.

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

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 06:28:11PM -0500, Andrew Cagney wrote:
> >On Fri, Jan 17, 2003 at 03:52:59PM -0500, Andrew Cagney wrote:
> >
> >>>On Fri, Jan 17, 2003 at 03:12:35PM -0500, Andrew Cagney wrote:
> >>>
> >
> >>>>
> >
> >>>
> >
> >>>>>In that case I'd want "broken in all GCC's" to be open rather than
> >>>>>suspended.  Does this bother anyone?
> >
> >>>
> >
> >>>>
> >>>>Yes, that bothers me, it would be wrong.  The only time a PR is in the 
> >>>>open state is when no one has looked at it.  As soon as someone looks 
> >>at >>the PR, it should be changed from open to some other state - 
> >>analized, >>suspended, closed, ...
> >
> >>>
> >>>
> >>>Substitute "a state other than suspended or closed".  Better?  Probably
> >>>"analyzed".
> >
> >>
> >>Not really.  Analyzed, I think, still implies that it is GDB's problem. 
> >> Suspended and closed, on the other hand don't
> >
> >
> >We don't work in a void; ideally, we want to fix debug info bugs which
> >are still present in current GCC.  It seems to me that tracking them in
> >the GDB PR system is reasonable.
> 
> Tracking them locally is definitly reasonable, yes.  Someone finds a 
> problem with GDB, searches the bug database and finds, that the problem 
> is known and in tool XYZ.
> 
> >Hmm, maybe not, maybe file a suspended bug and reference an open one in
> >GCC's PRMS.
> 
> Right.

Sounds good to me.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> On Fri, Jan 17, 2003 at 03:52:59PM -0500, Andrew Cagney wrote:
> 
>> >On Fri, Jan 17, 2003 at 03:12:35PM -0500, Andrew Cagney wrote:
>> >
> 
>> >>
> 
>> >
> 
>> >>>In that case I'd want "broken in all GCC's" to be open rather than
>> >>>suspended.  Does this bother anyone?
> 
>> >
> 
>> >>
>> >>Yes, that bothers me, it would be wrong.  The only time a PR is in the 
>> >>open state is when no one has looked at it.  As soon as someone looks at 
>> >>the PR, it should be changed from open to some other state - analized, 
>> >>suspended, closed, ...
> 
>> >
>> >
>> >Substitute "a state other than suspended or closed".  Better?  Probably
>> >"analyzed".
> 
>> 
>> Not really.  Analyzed, I think, still implies that it is GDB's problem. 
>>  Suspended and closed, on the other hand don't
> 
> 
> We don't work in a void; ideally, we want to fix debug info bugs which
> are still present in current GCC.  It seems to me that tracking them in
> the GDB PR system is reasonable.

Tracking them locally is definitly reasonable, yes.  Someone finds a 
problem with GDB, searches the bug database and finds, that the problem 
is known and in tool XYZ.

> Hmm, maybe not, maybe file a suspended bug and reference an open one in
> GCC's PRMS.

Right.

Andrew

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

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 03:52:59PM -0500, Andrew Cagney wrote:
> >On Fri, Jan 17, 2003 at 03:12:35PM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>In that case I'd want "broken in all GCC's" to be open rather than
> >>>suspended.  Does this bother anyone?
> >
> >>
> >>Yes, that bothers me, it would be wrong.  The only time a PR is in the 
> >>open state is when no one has looked at it.  As soon as someone looks at 
> >>the PR, it should be changed from open to some other state - analized, 
> >>suspended, closed, ...
> >
> >
> >Substitute "a state other than suspended or closed".  Better?  Probably
> >"analyzed".
> 
> Not really.  Analyzed, I think, still implies that it is GDB's problem. 
>  Suspended and closed, on the other hand don't

We don't work in a void; ideally, we want to fix debug info bugs which
are still present in current GCC.  It seems to me that tracking them in
the GDB PR system is reasonable.

Hmm, maybe not, maybe file a suspended bug and reference an open one in
GCC's PRMS.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> On Fri, Jan 17, 2003 at 03:12:35PM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >In that case I'd want "broken in all GCC's" to be open rather than
>> >suspended.  Does this bother anyone?
> 
>> 
>> Yes, that bothers me, it would be wrong.  The only time a PR is in the 
>> open state is when no one has looked at it.  As soon as someone looks at 
>> the PR, it should be changed from open to some other state - analized, 
>> suspended, closed, ...
> 
> 
> Substitute "a state other than suspended or closed".  Better?  Probably
> "analyzed".

Not really.  Analyzed, I think, still implies that it is GDB's problem. 
  Suspended and closed, on the other hand don't

Andrew

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

[Michael Elizabeth Chastain]

mec> ... you are talking
mec> about 's/CLLbsNNNNN//', not 'g/CLLbsNNNNN/d'.
mec>
mec> I still think that's not useful in light of the progress we are
mec> making but I would not be opposed to it happening.

andrewc> `useful' doesn't come into this part of the equation.
andrewc> Those references to an external bug database need to be removed.
andrewc> The only thing up for negotiation on this one is the timing.

Pedantically: I mean it's not useful, for the goal of cleaning up
xfails, to purge the CLLbs.

For the goal of cleaning up dangling references it's very useful.
I'll get out of my damn mailer and go purge those bad boys from
gdb.c++/*.exp right now.

Michael C
talking too much, maintaining too little :-/

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

[Michael Elizabeth Chastain]

Andrew C writes:
> If the bug is fixed in GCC we might as well indicate this by closing our 
> side of the bug report.  No reason to hang onto a bug report that has 
> been resolved.

Does this include the XFAIL's for gcc v2 stabs+ in gdb.base/constvars.exp?

I really think that it's a year too early to close a gdb bug report
with gcc 2.95.3 by saying "it works if you use gcc 3.X".

But, okay, in that case, I'll stop testing with gcc 2.95.3.  Because
any bugs that I find with gcc 2.95.3 that do not manifest with gcc 3.2.1
would just get closed with "fixed in gcc 3.2.1".

Michael C

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

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 03:12:35PM -0500, Andrew Cagney wrote:
> 
> >In that case I'd want "broken in all GCC's" to be open rather than
> >suspended.  Does this bother anyone?
> 
> Yes, that bothers me, it would be wrong.  The only time a PR is in the 
> open state is when no one has looked at it.  As soon as someone looks at 
> the PR, it should be changed from open to some other state - analized, 
> suspended, closed, ...

Substitute "a state other than suspended or closed".  Better?  Probably
"analyzed".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> Daniel J writes:
> 
> 
>> Would an external defect relating to GCC 2.95.3, fixed in 3.2, be
>> marked "closed"?
> 
> 
> I think not.  I think it would continue to be "suspended".

If the bug is fixed in GCC we might as well indicate this by closing our 
side of the bug report.  No reason to hang onto a bug report that has 
been resolved.

Andrew


> My opinion is that we support gcc 2.95.3 and gcc 3.2.1.  "support"
> means that we test with them before releasing gdb, that we pay attention
> to bug reports on those versions, and that we don't automatically tell
> people using that software to upgrade.  E.g. we don't support gcc 2.95.2,
> or gcc 3.0.4.
> 
> It would be great to have a more authoritative document about what
> compilers gdb supports (and what "support" means) than the preceeding
> paragraph, which I basically made up.
> 
> The fact that "gcc 2.95.3" and "gcc 3.2" have different major version
> numbers has something to do with this, but not everything.  I don't
> think we support gcc 1.42 or whatever the last gcc 1.X was.
> 
> Whenever the Head Maintainer says that gcc 2.95.3 is no longer supported
> then I will stop testing with it.  I think that is the proper time to
> close an external defect that is "broken with gcc 2.95.3, works with
> gcc 3.2".
> 
> Michael C
> 

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

[Andrew Cagney]

> In that case I'd want "broken in all GCC's" to be open rather than
> suspended.  Does this bother anyone?

Yes, that bothers me, it would be wrong.  The only time a PR is in the 
open state is when no one has looked at it.  As soon as someone looks at 
the PR, it should be changed from open to some other state - analized, 
suspended, closed, ...

Andrew

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

[Michael Elizabeth Chastain]

Daniel J writes:
> In that case I'd want "broken in all GCC's" to be open rather than
> suspended.  Does this bother anyone?

If "external" is a class, it's okay with me if some of them
are "open" and some of them are "suspended".

I wish the state was an indicator of who we are waiting for:

  open      -> waiting for gdb investigator
  analyzed  -> waiting for gdb patch-writer
  external  -> waiting for external issue to be fixed
  suspended -> waiting for some miscellaneous condition
  feedback  -> waiting for original user
  closed    -> not waiting

But since we're headed for 'external' as a class rather than a state,
this isn't going to happen.

Michael C

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

[Michael Elizabeth Chastain]

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

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

[Daniel Jacobowitz]

On Fri, Jan 17, 2003 at 01:45:13PM -0600, Michael Elizabeth Chastain wrote:
> Daniel J writes:
> 
> > Would an external defect relating to GCC 2.95.3, fixed in 3.2, be
> > marked "closed"?
> 
> I think not.  I think it would continue to be "suspended".
> 
> My opinion is that we support gcc 2.95.3 and gcc 3.2.1.  "support"
> means that we test with them before releasing gdb, that we pay attention
> to bug reports on those versions, and that we don't automatically tell
> people using that software to upgrade.  E.g. we don't support gcc 2.95.2,
> or gcc 3.0.4.
> 
> It would be great to have a more authoritative document about what
> compilers gdb supports (and what "support" means) than the preceeding
> paragraph, which I basically made up.
> 
> The fact that "gcc 2.95.3" and "gcc 3.2" have different major version
> numbers has something to do with this, but not everything.  I don't
> think we support gcc 1.42 or whatever the last gcc 1.X was.
> 
> Whenever the Head Maintainer says that gcc 2.95.3 is no longer supported
> then I will stop testing with it.  I think that is the proper time to
> close an external defect that is "broken with gcc 2.95.3, works with
> gcc 3.2".

In that case I'd want "broken in all GCC's" to be open rather than
suspended.  Does this bother anyone?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Elizabeth Chastain]

Daniel J writes:

> Would an external defect relating to GCC 2.95.3, fixed in 3.2, be
> marked "closed"?

I think not.  I think it would continue to be "suspended".

My opinion is that we support gcc 2.95.3 and gcc 3.2.1.  "support"
means that we test with them before releasing gdb, that we pay attention
to bug reports on those versions, and that we don't automatically tell
people using that software to upgrade.  E.g. we don't support gcc 2.95.2,
or gcc 3.0.4.

It would be great to have a more authoritative document about what
compilers gdb supports (and what "support" means) than the preceeding
paragraph, which I basically made up.

The fact that "gcc 2.95.3" and "gcc 3.2" have different major version
numbers has something to do with this, but not everything.  I don't
think we support gcc 1.42 or whatever the last gcc 1.X was.

Whenever the Head Maintainer says that gcc 2.95.3 is no longer supported
then I will stop testing with it.  I think that is the proper time to
close an external defect that is "broken with gcc 2.95.3, works with
gcc 3.2".

Michael C