Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

ac> Er, we already have a repostory of known bugs, it's called the bug 
ac> database.  Why duplicate the content and tracking effort?

Because it works.

The actual part of PROBLEMS that you're objecting to is the paragraphs
which talk about setting breakpoints in constructors in C++ code.
This doesn't work with gcc v3 because gcc v3 emits multiple copies
of the object code, and gdb sets the breakpoint in just one of them.

Before PROBLEMS talked about this, we got several reports per month
about this issue.  Now we don't get any.  And for each user that takes
the trouble to e-mail us, there are many more users who run into the
issue and appreciate having a short description of it.

I think we should keep that part of PROBLEMS as long as gdb has this
problem.

Also, the PR database does not track user-visible bugs.  It has
numerous maintainance entries which do not impact the user at all.

> PROBLEMS should draw the users attention to late breaking and immediate 
> issues that will hurt them (gdb doesn't build, this broke going from the 
> previous release).

Sure.  To me, that means every regression from previous releases,
plus bugs that are likely to be important to a large part of the
user population.

> A bug already present in the previous release _isn't_ new news.

Some of those bugs are important to users, though.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

ac> Er, we already have a repostory of known bugs, it's called the bug 
ac> database.  Why duplicate the content and tracking effort?

Because it works.

The actual part of PROBLEMS that you're objecting to is the paragraphs
which talk about setting breakpoints in constructors in C++ code.
This doesn't work with gcc v3 because gcc v3 emits multiple copies
of the object code, and gdb sets the breakpoint in just one of them.

Before PROBLEMS talked about this, we got several reports per month
about this issue.  Now we don't get any.  And for each user that takes
the trouble to e-mail us, there are many more users who run into the
issue and appreciate having a short description of it.

I think we should keep that part of PROBLEMS as long as gdb has this
problem.

Also, the PR database does not track user-visible bugs.  It has
numerous maintainance entries which do not impact the user at all.

> PROBLEMS should draw the users attention to late breaking and immediate 
> issues that will hurt them (gdb doesn't build, this broke going from the 
> previous release).

Sure.  To me, that means every regression from previous releases,
plus bugs that are likely to be important to a large part of the
user population.

> A bug already present in the previous release _isn't_ new news.

Some of those bugs are important to users, though.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Thu, 18 Mar 2004 11:24:02 -0500 (EST), mec.gnu@mindspring.com
(Michael Elizabeth Chastain) said:

> The actual part of PROBLEMS that you're objecting to is the
> paragraphs which talk about setting breakpoints in constructors in
> C++ code.  This doesn't work with gcc v3 because gcc v3 emits
> multiple copies of the object code, and gdb sets the breakpoint in
> just one of them.

> Before PROBLEMS talked about this, we got several reports per month
> about this issue.  Now we don't get any.  And for each user that
> takes the trouble to e-mail us, there are many more users who run
> into the issue and appreciate having a short description of it.

> I think we should keep that part of PROBLEMS as long as gdb has this
> problem.

I agree.  I can see the point of mentioning fiddling little
regressions once in PROBLEMS and then deleting the entry on subsequent
releases, even if the regressions remain.  But it makes sense to me to
leave important, frequently encountered bugs in PROBLEMS.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Thu, 18 Mar 2004 11:24:02 -0500 (EST), mec.gnu@mindspring.com
(Michael Elizabeth Chastain) said:

> The actual part of PROBLEMS that you're objecting to is the
> paragraphs which talk about setting breakpoints in constructors in
> C++ code.  This doesn't work with gcc v3 because gcc v3 emits
> multiple copies of the object code, and gdb sets the breakpoint in
> just one of them.

> Before PROBLEMS talked about this, we got several reports per month
> about this issue.  Now we don't get any.  And for each user that
> takes the trouble to e-mail us, there are many more users who run
> into the issue and appreciate having a short description of it.

> I think we should keep that part of PROBLEMS as long as gdb has this
> problem.

I agree.  I can see the point of mentioning fiddling little
regressions once in PROBLEMS and then deleting the entry on subsequent
releases, even if the regressions remain.  But it makes sense to me to
leave important, frequently encountered bugs in PROBLEMS.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

> ac> Er, we already have a repostory of known bugs, it's called the bug 
> ac> database.  Why duplicate the content and tracking effort?
> 
> Because it works.

At a level it does, but it can also get out of control.

> The actual part of PROBLEMS that you're objecting to is the paragraphs
> which talk about setting breakpoints in constructors in C++ code.
> This doesn't work with gcc v3 because gcc v3 emits multiple copies
> of the object code, and gdb sets the breakpoint in just one of them.

I'm objecting to:

>> "Regressions since gdb 6.0"
>> and "Regressions since gdb 5.3".

If specific problems are present in 6.1 and are going to _really_ hurt 
the user then they should be mentioned (if they happened to be in 6.0 as 
well, oops).

However, we should not allow PROBLEMS to accumulate just because they 
are still present -- heavy editing is required to ensure that the 
PROBLEMS file is both relevant and focused (Several releases back I 
deleted chunks of README as, although technically correct, they were 
simply not relevant).

> Before PROBLEMS talked about this, we got several reports per month
> about this issue.

Actually, somewhat perversely, that is a good thing.

It leads to a cluster of bug reports that provide a strong pointer to a 
specific problem that is hurting many of our users.  If we introduce 
mechanisms that artificially filter out this information we end up with 
a skewed view of our user base.

 >  Now we don't get any.  And for each user that takes
 > the trouble to e-mail us, there are many more users who run into the
 > issue and appreciate having a short description of it.
> I think we should keep that part of PROBLEMS as long as gdb has this
> problem.

Definitly no.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Daniel Jacobowitz]

On Thu, Mar 18, 2004 at 02:45:36PM -0500, Andrew Cagney wrote:
> >  Now we don't get any.  And for each user that takes
> > the trouble to e-mail us, there are many more users who run into the
> > issue and appreciate having a short description of it.
> >I think we should keep that part of PROBLEMS as long as gdb has this
> >problem.
> 
> Definitly no.

What do we gain by removing something that continues to be a major
problem from the file named PROBLEMS?  I just don't get it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 19:27:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> What do we gain by removing something that continues to be a major
> problem from the file named PROBLEMS?  I just don't get it.

I second the question.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

> On Thu, Mar 18, 2004 at 02:45:36PM -0500, Andrew Cagney wrote:
> 
>>>> >  Now we don't get any.  And for each user that takes
>>>> > the trouble to e-mail us, there are many more users who run into the
>>>> > issue and appreciate having a short description of it.
>>>> >I think we should keep that part of PROBLEMS as long as gdb has this
>>>> >problem.
>>
>>> 
>>> Definitly no.
> 
> 
> What do we gain by removing something that continues to be a major
> problem from the file named PROBLEMS?  I just don't get it.

Please read my most recent reply from yesterday.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Fri, 19 Mar 2004 10:03:31 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > What do we gain by removing something that continues to be a major
> > problem from the file named PROBLEMS?  I just don't get it.
> 
> Please read my most recent reply from yesterday.

Andrew, I did read your reply, and I still don't get it; please bear
with us.

Assuming that we only leave in PROBLEMS those bugs that have visible
user-level effect, do you still object to have there bugs from old
versions?  If so, please tell why you think users should not know
about them.

TIA

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

>>Date: Fri, 19 Mar 2004 10:03:31 -0500
>>> From: Andrew Cagney <cagney@gnu.org>
>>
>>>> > 
>>>> > What do we gain by removing something that continues to be a major
>>>> > problem from the file named PROBLEMS?  I just don't get it.
>>
>>> 
>>> Please read my most recent reply from yesterday.
> 
> 
> Andrew, I did read your reply, and I still don't get it; please bear
> with us.
> 
> Assuming that we only leave in PROBLEMS those bugs that have visible
> user-level effect, do you still object to have there bugs from old
> versions?  If so, please tell why you think users should not know
> about them.

Er, this is what I wrote:

> I'm objecting to:
> 
>>> "Regressions since gdb 6.0"
>>> and "Regressions since gdb 5.3".

> If specific problems are present in 6.1 and are going to _really_ hurt the user then they should be mentioned (if they happened to be in 6.0 as well, oops).
> 
> However, we should not allow PROBLEMS to accumulate just because they are still present -- heavy editing is required to ensure that the PROBLEMS file is both relevant and focused (Several releases back I deleted chunks of README as, although technically correct, they were simply not relevant). 

Put simply those titles should be removed.

Andrew




[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4576 bytes --]

From: Andrew Cagney <cagney@gnu.org>
To: Michael Elizabeth Chastain <mec.gnu@mindspring.com>
Cc: eliz@elta.co.il, gdb-patches@sources.redhat.com
Subject: Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0
Date: Thu, 18 Mar 2004 14:45:36 -0500
Message-ID: <4059FC60.2090605@gnu.org>

> ac> Er, we already have a repostory of known bugs, it's called the bug 
> ac> database.  Why duplicate the content and tracking effort?
> 
> Because it works.

At a level it does, but it can also get out of control.

> The actual part of PROBLEMS that you're objecting to is the paragraphs
> which talk about setting breakpoints in constructors in C++ code.
> This doesn't work with gcc v3 because gcc v3 emits multiple copies
> of the object code, and gdb sets the breakpoint in just one of them.

I'm objecting to:

>> "Regressions since gdb 6.0"
>> and "Regressions since gdb 5.3".

If specific problems are present in 6.1 and are going to _really_ hurt 
the user then they should be mentioned (if they happened to be in 6.0 as 
well, oops).

However, we should not allow PROBLEMS to accumulate just because they 
are still present -- heavy editing is required to ensure that the 
PROBLEMS file is both relevant and focused (Several releases back I 
deleted chunks of README as, although technically correct, they were 
simply not relevant).

> Before PROBLEMS talked about this, we got several reports per month
> about this issue.

Actually, somewhat perversely, that is a good thing.

It leads to a cluster of bug reports that provide a strong pointer to a 
specific problem that is hurting many of our users.  If we introduce 
mechanisms that artificially filter out this information we end up with 
a skewed view of our user base.

 >  Now we don't get any.  And for each user that takes
 > the trouble to e-mail us, there are many more users who run into the
 > issue and appreciate having a short description of it.
> I think we should keep that part of PROBLEMS as long as gdb has this
> problem.

Definitly no.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Fri, 19 Mar 2004 10:54:19 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Er, this is what I wrote:
> 
> > I'm objecting to:
> >
> >>> "Regressions since gdb 6.0"
> >>> and "Regressions since gdb 5.3".

If it's only the "Regressions since gdb X.Y" that you are opposed to,
I don't have anything against renaming them.

> > If specific problems are present in 6.1 and are going to _really_
> > hurt the user then they should be mentioned (if they happened to
> > be in 6.0 as well , oops).
> >
> > However, we should not allow PROBLEMS to accumulate just because
> > they are still present -- heavy editing is required to ensure that
> > the PROBLEMS file is both relevant and focused (Several releases
> > back I deleted chunks of README as, although technically correct,
> > they were simply not relevant).

I support these points.

Your initial messages in this thread sounded like you were opposed to
having in PROBLEMS entries from past releases.  Sorry if I
misunderstood.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> The last sentence should probably say "Add known regressions since
> gdb 6.0."  ``regressions I know about'' is not something that should
> be in a ChangeLog; it goes without saying that ``known'' means
> ``known to the person who makes the change.''

I'll be happy to do it your way, although I like it better when
statements have explicit subjects.

> A typo.

Oops.  Thanks.

IACTN,

Michael C

===

2004-03-16  Michael Chastain  <mec.gnu@mindspring.com>

        * PROBLEMS: Add section headers, "Regressions since gdb 6.0"
        and "Regressions since gdb 5.3.".  Add known regressions since
        gdb 6.0.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> The last sentence should probably say "Add known regressions since
> gdb 6.0."  ``regressions I know about'' is not something that should
> be in a ChangeLog; it goes without saying that ``known'' means
> ``known to the person who makes the change.''

I'll be happy to do it your way, although I like it better when
statements have explicit subjects.

> A typo.

Oops.  Thanks.

IACTN,

Michael C

===

2004-03-16  Michael Chastain  <mec.gnu@mindspring.com>

        * PROBLEMS: Add section headers, "Regressions since gdb 6.0"
        and "Regressions since gdb 5.3.".  Add known regressions since
        gdb 6.0.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

Yes, I too wish there was a list of PR's fixed.

I don't think it's all that helpful to the users.  As a user of *gcc*,
I look at their list of PR's fixed, and I say "yeah okay cool", and
then I run my own before+after spin anyways.  But as a tester of gdb,
I enjoy looking at my "compare by gdb" tables and seeing all the
FAIL->PASS transititions.

> Of course, it helps that GCC has several people who try to make sure
> that their bug database is as up to date as possible and organized in
> such a way as to make it easy to figure out this information.

Our bug database has several deficiencies.  It's hard to make
attachments (bugzilla is much easier).  We ask for fields that are
not important, like "severity", and do not ask for information that
is critical, like "what compiler are you using".  We need a page that
says "here is the Unix 'script' command, please attach a typescript
with your bug report".  And then there's all that nifty milestone
stuff.

> Whereas you're the only person seriously looking at the GDB bug database,
> and you're also focused (perhaps more focused) on regression testing.

Mark K and Andrew C and Daniel J and David C spend a lot of time
in there too.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

Yes, I too wish there was a list of PR's fixed.

I don't think it's all that helpful to the users.  As a user of *gcc*,
I look at their list of PR's fixed, and I say "yeah okay cool", and
then I run my own before+after spin anyways.  But as a tester of gdb,
I enjoy looking at my "compare by gdb" tables and seeing all the
FAIL->PASS transititions.

> Of course, it helps that GCC has several people who try to make sure
> that their bug database is as up to date as possible and organized in
> such a way as to make it easy to figure out this information.

Our bug database has several deficiencies.  It's hard to make
attachments (bugzilla is much easier).  We ask for fields that are
not important, like "severity", and do not ask for information that
is critical, like "what compiler are you using".  We need a page that
says "here is the Unix 'script' command, please attach a typescript
with your bug report".  And then there's all that nifty milestone
stuff.

> Whereas you're the only person seriously looking at the GDB bug database,
> and you're also focused (perhaps more focused) on regression testing.

Mark K and Andrew C and Daniel J and David C spend a lot of time
in there too.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> I don't think that looking for KFAILs is a good way to identify
> whether or not a specific PR is a regression.

That's why I quoted the script's input and gdb's output.
It's pretty clear that something simple and useful worked
in gdb 6.0 and does not work in gdb 6.1.  Some of the local.exp
results are a real pain in this regard.

> In this particular instance, if you go to your table comparing 6.0 suite
> HEAD to 6.1 suite HEAD and, for example, look at the third column (GCC
> 3.3.3, DWARF-2), you'll see a whole bunch of FAIL=>PASS transitions.

That's true.

> So I think the testsuite regression=>PR+description transition should
> involve some more steps - the corresponding PR may be much broader
> than the particular testsuite regression, and some of those broader
> areas may involve situations where GDB has improved rather than
> regressed.

My first impulse is to pop open a more narrow, more accurate PR
for "print (ClassWithEnum::PrivEnum) 42".  What do you think?

I agree with you; there is a step where we have to translate
PR gdb/NNNN into text for PROBLEMS.  The text in PROBLEMS has to
be accurate, and I want it to actually cover all the regression
problems that we know about.  And it's also better if it's narrow,
because the more narrow it is, the more users can say "okay, THAT
bug does not affect me, I can upgrade".

(I think regressions are special compared to regular bugs because
if someone is using gdb 5.3 or gdb 6.0, and they are considering
upgrading to gdb 6.1, then the new regressions are the bugs that are
most important to them).

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> I don't think that looking for KFAILs is a good way to identify
> whether or not a specific PR is a regression.

That's why I quoted the script's input and gdb's output.
It's pretty clear that something simple and useful worked
in gdb 6.0 and does not work in gdb 6.1.  Some of the local.exp
results are a real pain in this regard.

> In this particular instance, if you go to your table comparing 6.0 suite
> HEAD to 6.1 suite HEAD and, for example, look at the third column (GCC
> 3.3.3, DWARF-2), you'll see a whole bunch of FAIL=>PASS transitions.

That's true.

> So I think the testsuite regression=>PR+description transition should
> involve some more steps - the corresponding PR may be much broader
> than the particular testsuite regression, and some of those broader
> areas may involve situations where GDB has improved rather than
> regressed.

My first impulse is to pop open a more narrow, more accurate PR
for "print (ClassWithEnum::PrivEnum) 42".  What do you think?

I agree with you; there is a step where we have to translate
PR gdb/NNNN into text for PROBLEMS.  The text in PROBLEMS has to
be accurate, and I want it to actually cover all the regression
problems that we know about.  And it's also better if it's narrow,
because the more narrow it is, the more users can say "okay, THAT
bug does not affect me, I can upgrade".

(I think regressions are special compared to regular bugs because
if someone is using gdb 5.3 or gdb 6.0, and they are considering
upgrading to gdb 6.1, then the new regressions are the bugs that are
most important to them).

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 14:30:26 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

>> So I think the testsuite regression=>PR+description transition
>> should involve some more steps - the corresponding PR may be much
>> broader than the particular testsuite regression, and some of those
>> broader areas may involve situations where GDB has improved rather
>> than regressed.

> My first impulse is to pop open a more narrow, more accurate PR
> for "print (ClassWithEnum::PrivEnum) 42".  What do you think?

I'll go and do that.

> I agree with you; there is a step where we have to translate
> PR gdb/NNNN into text for PROBLEMS.  The text in PROBLEMS has to
> be accurate, and I want it to actually cover all the regression
> problems that we know about.  And it's also better if it's narrow,
> because the more narrow it is, the more users can say "okay, THAT
> bug does not affect me, I can upgrade".

> (I think regressions are special compared to regular bugs because if
> someone is using gdb 5.3 or gdb 6.0, and they are considering
> upgrading to gdb 6.1, then the new regressions are the bugs that are
> most important to them).

Those paragraphs make sense to me.

I think one of the things that is bothering me is that we're
highlighting new bugs but not highlighting bugs that have been fixed.
Some of the latter is in NEWS, but NEWS is both at a higher level (it
doesn't mention specific PR numbers) and it tends to concentrate on
new features, which isn't quite the same thing.  For GCC releases,
Gerald Pfeifer (if I'm remembering correctly) goes through the list of
GCC bugs and provides a table of all of the ones that have been fixed
in that particular release (breaking them down into categories);
besides making GCC developers feel good, it can also help users decide
when to upgrade, because they can look at the list of bugs that have
been fixed in the categories that they care about and see how
important those bugs are to them.

Of course, it helps that GCC has several people who try to make sure
that their bug database is as up to date as possible and organized in
such a way as to make it easy to figure out this information.  Whereas
you're the only person seriously looking at the GDB bug database, and
you're also focused (perhaps more focused) on regression testing.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 14:30:26 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

>> So I think the testsuite regression=>PR+description transition
>> should involve some more steps - the corresponding PR may be much
>> broader than the particular testsuite regression, and some of those
>> broader areas may involve situations where GDB has improved rather
>> than regressed.

> My first impulse is to pop open a more narrow, more accurate PR
> for "print (ClassWithEnum::PrivEnum) 42".  What do you think?

I'll go and do that.

> I agree with you; there is a step where we have to translate
> PR gdb/NNNN into text for PROBLEMS.  The text in PROBLEMS has to
> be accurate, and I want it to actually cover all the regression
> problems that we know about.  And it's also better if it's narrow,
> because the more narrow it is, the more users can say "okay, THAT
> bug does not affect me, I can upgrade".

> (I think regressions are special compared to regular bugs because if
> someone is using gdb 5.3 or gdb 6.0, and they are considering
> upgrading to gdb 6.1, then the new regressions are the bugs that are
> most important to them).

Those paragraphs make sense to me.

I think one of the things that is bothering me is that we're
highlighting new bugs but not highlighting bugs that have been fixed.
Some of the latter is in NEWS, but NEWS is both at a higher level (it
doesn't mention specific PR numbers) and it tends to concentrate on
new features, which isn't quite the same thing.  For GCC releases,
Gerald Pfeifer (if I'm remembering correctly) goes through the list of
GCC bugs and provides a table of all of the ones that have been fixed
in that particular release (breaking them down into categories);
besides making GCC developers feel good, it can also help users decide
when to upgrade, because they can look at the list of bugs that have
been fixed in the categories that they care about and see how
important those bugs are to them.

Of course, it helps that GCC has several people who try to make sure
that their bug database is as up to date as possible and organized in
such a way as to make it easy to figure out this information.  Whereas
you're the only person seriously looking at the GDB bug database, and
you're also focused (perhaps more focused) on regression testing.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Wed, 17 Mar 2004 11:48:56 -0800
> 
> I think one of the things that is bothering me is that we're
> highlighting new bugs but not highlighting bugs that have been fixed.

Fixed bugs that we want to tell users about should be in NEWS.

> Some of the latter is in NEWS, but NEWS is both at a higher level (it
> doesn't mention specific PR numbers) and it tends to concentrate on
> new features, which isn't quite the same thing.

There's nothing to prevent us from adding fixed bugs to NEWS, I think.

However, if the number of bugs fixed between releases is very large,
it could make sense not to mention them at all.  One case in point is
Emacs: its NEWS contains only new and improved features, while the
fixed bugs are not mentioned at all, their number being too huge.

> For GCC releases,
> Gerald Pfeifer (if I'm remembering correctly) goes through the list of
> GCC bugs and provides a table of all of the ones that have been fixed
> in that particular release (breaking them down into categories);
> besides making GCC developers feel good, it can also help users decide
> when to upgrade, because they can look at the list of bugs that have
> been fixed in the categories that they care about and see how
> important those bugs are to them.

I sincerely doubt that the list of GCC fixed bugs helps anyone beyond
GCC developers and people with special interest in compiler
development, as most of them are worded in a way that leaves users
with a ``Huh?'' after-taste.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Wed, 17 Mar 2004 11:48:56 -0800
> 
> I think one of the things that is bothering me is that we're
> highlighting new bugs but not highlighting bugs that have been fixed.

Fixed bugs that we want to tell users about should be in NEWS.

> Some of the latter is in NEWS, but NEWS is both at a higher level (it
> doesn't mention specific PR numbers) and it tends to concentrate on
> new features, which isn't quite the same thing.

There's nothing to prevent us from adding fixed bugs to NEWS, I think.

However, if the number of bugs fixed between releases is very large,
it could make sense not to mention them at all.  One case in point is
Emacs: its NEWS contains only new and improved features, while the
fixed bugs are not mentioned at all, their number being too huge.

> For GCC releases,
> Gerald Pfeifer (if I'm remembering correctly) goes through the list of
> GCC bugs and provides a table of all of the ones that have been fixed
> in that particular release (breaking them down into categories);
> besides making GCC developers feel good, it can also help users decide
> when to upgrade, because they can look at the list of bugs that have
> been fixed in the categories that they care about and see how
> important those bugs are to them.

I sincerely doubt that the list of GCC fixed bugs helps anyone beyond
GCC developers and people with special interest in compiler
development, as most of them are worded in a way that leaves users
with a ``Huh?'' after-taste.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> I don't think it should retain regressions since 5.3, the file is 
> stating problems in this release, not the last one.

These are still problems in this release.  They haven't been fixed.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> I don't think it should retain regressions since 5.3, the file is 
> stating problems in this release, not the last one.

These are still problems in this release.  They haven't been fixed.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>I don't think it should retain regressions since 5.3, the file is 
>>> stating problems in this release, not the last one.
> 
> 
> These are still problems in this release.  They haven't been fixed.

There are problems in all the releases, we don't list them.

The objective here is to draw the users attention to places where gdb is 
both better and worse than the _last_ release (6.0).  Not a sorry list 
of problems dateing back to version 0.0.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>I don't think it should retain regressions since 5.3, the file is 
>>> stating problems in this release, not the last one.
> 
> 
> These are still problems in this release.  They haven't been fixed.

There are problems in all the releases, we don't list them.

The objective here is to draw the users attention to places where gdb is 
both better and worse than the _last_ release (6.0).  Not a sorry list 
of problems dateing back to version 0.0.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

dc> These aren't regressions since 5.3: I know the first one has been
dc> around for a while, and the second one says that it occurs in 5.3
dc> its summary line!  :-)

Urgl.  That will teach me to write documentation just before going to bed.

You are right, 'Regressions since gdb 5.3' is a terrible section heading.

gdb/1091 'Constructor breakpoints ignored' and gdb/1193, 'g++ 3.3
creates multiple constructors: gdb 5.3 can't set breakpoints', are
really a regression in gdb's behavior from gcc 2.95.3 to gcc 3.0, not
from one gdb version to another gdb version.

Perhaps 'Problems related to recent versions of gcc'?

And then we could add doco about gdb/1537, 'anonymous union at function
scope, gcc 3.4' and gdb/1540, 'gcc gcc-3_4-branch emits DW_OP_piece but
gdb does not support it'.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

dc> These aren't regressions since 5.3: I know the first one has been
dc> around for a while, and the second one says that it occurs in 5.3
dc> its summary line!  :-)

Urgl.  That will teach me to write documentation just before going to bed.

You are right, 'Regressions since gdb 5.3' is a terrible section heading.

gdb/1091 'Constructor breakpoints ignored' and gdb/1193, 'g++ 3.3
creates multiple constructors: gdb 5.3 can't set breakpoints', are
really a regression in gdb's behavior from gcc 2.95.3 to gcc 3.0, not
from one gdb version to another gdb version.

Perhaps 'Problems related to recent versions of gcc'?

And then we could add doco about gdb/1537, 'anonymous union at function
scope, gcc 3.4' and gdb/1540, 'gcc gcc-3_4-branch emits DW_OP_piece but
gdb does not support it'.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> There are problems in all the releases, we don't list them.

The title of the file is "Known problems in GDB 6.1".
Indeed, I would like it to actually list all the known problems.
We just don't have the resources to do this yet.

> The objective here is to draw the users attention to places where gdb is 
> both better and worse than the _last_ release (6.0).  Not a sorry list 
> of problems dateing back to version 0.0.

NEWS dates back to version 0.0, so I think that PROBLEMS should as well.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>There are problems in all the releases, we don't list them.
> 
> 
> The title of the file is "Known problems in GDB 6.1".
> Indeed, I would like it to actually list all the known problems.
> We just don't have the resources to do this yet.
> 
> 
>>> The objective here is to draw the users attention to places where gdb is 
>>> both better and worse than the _last_ release (6.0).  Not a sorry list 
>>> of problems dateing back to version 0.0.
> 
> 
> NEWS dates back to version 0.0, so I think that PROBLEMS should as well.

I don't.

NEWS contains a history of GDB, PROBLEMS does not.

PROBLEMS is there to identify late breaking screwups and other issues in 
just _this_ release.  It provides only immediate information, and should 
even be cleared out just after each release.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Wed, 17 Mar 2004 18:39:50 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> NEWS contains a history of GDB, PROBLEMS does not.
> 
> PROBLEMS is there to identify late breaking screwups and other issues in 
> just _this_ release.

Not necessarily.  It depends on what purpose we want PROBLEMS to
serve.

One way of looking at PROBLEMS is as a repository of bugs that the GDB
team already knows about, and that users therefore should not report
as new bugs.  PROBLEMS can also mention work-arounds, so that users
who bump into them can do whatever they need even though the bug isn't
fixed yet.

If viewed like that, it would make sense for PROBLEMS to include all
the bugs that are still not fixed, even if they date back to version
0.0.  Bugs that are solved should indeed be deleted from PROBLEMS.

(Btw, if GDB still has bugs known since v0.0, it would say something
quite unflattering about GDB maintenance, and that alone is IMHO a
reason good enough to keep old unsolved bugs on record.)

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>> Date: Wed, 17 Mar 2004 18:39:50 -0500
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>> NEWS contains a history of GDB, PROBLEMS does not.
>>> 
>>> PROBLEMS is there to identify late breaking screwups and other issues in 
>>> just _this_ release.
> 
> 
> Not necessarily.  It depends on what purpose we want PROBLEMS to
> serve.
> 
> One way of looking at PROBLEMS is as a repository of bugs that the GDB
> team already knows about, and that users therefore should not report
> as new bugs.

Er, we already have a repostory of known bugs, it's called the bug 
database.  Why duplicate the content and tracking effort?

>  PROBLEMS can also mention work-arounds, so that users
> who bump into them can do whatever they need even though the bug isn't
> fixed yet.

> If viewed like that, it would make sense for PROBLEMS to include all
> the bugs that are still not fixed, even if they date back to version
> 0.0.  Bugs that are solved should indeed be deleted from PROBLEMS.

PROBLEMS should draw the users attention to late breaking and immediate 
issues that will hurt them (gdb doesn't build, this broke going from the 
previous release).  A bug already present in the previous release 
_isn't_ new news.  This is why the PROBLEMS file is the last thing 
updated (well that and version.in).

At present the ANNOUNCEMENT that goes out with a GDB release:
http://sources.redhat.com/gdb/download/ANNOUNCEMENT
contains:
- the latest news
- the problems in _this_ release
Notice how both are lifted straight from the corresponding file, and 
more importantly, notice how the problems refers the user to the bug 
database.

Listing every single long standing nit in the PROBLEMS file just adds 
unnecessary noise.  If the user is looking for details, they can look in 
the bug database.

> (Btw, if GDB still has bugs known since v0.0, it would say something
> quite unflattering about GDB maintenance, and that alone is IMHO a
> reason good enough to keep old unsolved bugs on record.)

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 11:04:54 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Er, we already have a repostory of known bugs, it's called the bug 
> database.  Why duplicate the content and tracking effort?

As Michael points out, and I concur, many, if not most, bugs stored
in the bug database are of no interest to users.  They also don't
tell how to work around them.  This is IMHO valuable information for
any GDB user who bumps into a bug.

In addition, PROBLEMS is much more accessible than the bug database,
as it is on the user's local disk.

> PROBLEMS should draw the users attention to late breaking and immediate 
> issues that will hurt them (gdb doesn't build, this broke going from the 
> previous release).  A bug already present in the previous release 
> _isn't_ new news.

You assume that GDB users download and build every release.  This
isn't necessarily so: what about someone who is upgrading from
version 5.1.1 to v6.0?

> Listing every single long standing nit in the PROBLEMS file just adds 
> unnecessary noise.

I don't agree that it's noise.  If we put there only important
user-visible bugs, I think the signal to noise ratio would be high
enough to make the file useful.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 11:04:54 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Er, we already have a repostory of known bugs, it's called the bug 
> database.  Why duplicate the content and tracking effort?

As Michael points out, and I concur, many, if not most, bugs stored
in the bug database are of no interest to users.  They also don't
tell how to work around them.  This is IMHO valuable information for
any GDB user who bumps into a bug.

In addition, PROBLEMS is much more accessible than the bug database,
as it is on the user's local disk.

> PROBLEMS should draw the users attention to late breaking and immediate 
> issues that will hurt them (gdb doesn't build, this broke going from the 
> previous release).  A bug already present in the previous release 
> _isn't_ new news.

You assume that GDB users download and build every release.  This
isn't necessarily so: what about someone who is upgrading from
version 5.1.1 to v6.0?

> Listing every single long standing nit in the PROBLEMS file just adds 
> unnecessary noise.

I don't agree that it's noise.  If we put there only important
user-visible bugs, I think the signal to noise ratio would be high
enough to make the file useful.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>> Date: Wed, 17 Mar 2004 18:39:50 -0500
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>> NEWS contains a history of GDB, PROBLEMS does not.
>>> 
>>> PROBLEMS is there to identify late breaking screwups and other issues in 
>>> just _this_ release.
> 
> 
> Not necessarily.  It depends on what purpose we want PROBLEMS to
> serve.
> 
> One way of looking at PROBLEMS is as a repository of bugs that the GDB
> team already knows about, and that users therefore should not report
> as new bugs.

Er, we already have a repostory of known bugs, it's called the bug 
database.  Why duplicate the content and tracking effort?

>  PROBLEMS can also mention work-arounds, so that users
> who bump into them can do whatever they need even though the bug isn't
> fixed yet.

> If viewed like that, it would make sense for PROBLEMS to include all
> the bugs that are still not fixed, even if they date back to version
> 0.0.  Bugs that are solved should indeed be deleted from PROBLEMS.

PROBLEMS should draw the users attention to late breaking and immediate 
issues that will hurt them (gdb doesn't build, this broke going from the 
previous release).  A bug already present in the previous release 
_isn't_ new news.  This is why the PROBLEMS file is the last thing 
updated (well that and version.in).

At present the ANNOUNCEMENT that goes out with a GDB release:
http://sources.redhat.com/gdb/download/ANNOUNCEMENT
contains:
- the latest news
- the problems in _this_ release
Notice how both are lifted straight from the corresponding file, and 
more importantly, notice how the problems refers the user to the bug 
database.

Listing every single long standing nit in the PROBLEMS file just adds 
unnecessary noise.  If the user is looking for details, they can look in 
the bug database.

> (Btw, if GDB still has bugs known since v0.0, it would say something
> quite unflattering about GDB maintenance, and that alone is IMHO a
> reason good enough to keep old unsolved bugs on record.)

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Wed, 17 Mar 2004 18:39:50 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> NEWS contains a history of GDB, PROBLEMS does not.
> 
> PROBLEMS is there to identify late breaking screwups and other issues in 
> just _this_ release.

Not necessarily.  It depends on what purpose we want PROBLEMS to
serve.

One way of looking at PROBLEMS is as a repository of bugs that the GDB
team already knows about, and that users therefore should not report
as new bugs.  PROBLEMS can also mention work-arounds, so that users
who bump into them can do whatever they need even though the bug isn't
fixed yet.

If viewed like that, it would make sense for PROBLEMS to include all
the bugs that are still not fixed, even if they date back to version
0.0.  Bugs that are solved should indeed be deleted from PROBLEMS.

(Btw, if GDB still has bugs known since v0.0, it would say something
quite unflattering about GDB maintenance, and that alone is IMHO a
reason good enough to keep old unsolved bugs on record.)

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>There are problems in all the releases, we don't list them.
> 
> 
> The title of the file is "Known problems in GDB 6.1".
> Indeed, I would like it to actually list all the known problems.
> We just don't have the resources to do this yet.
> 
> 
>>> The objective here is to draw the users attention to places where gdb is 
>>> both better and worse than the _last_ release (6.0).  Not a sorry list 
>>> of problems dateing back to version 0.0.
> 
> 
> NEWS dates back to version 0.0, so I think that PROBLEMS should as well.

I don't.

NEWS contains a history of GDB, PROBLEMS does not.

PROBLEMS is there to identify late breaking screwups and other issues in 
just _this_ release.  It provides only immediate information, and should 
even be cleared out just after each release.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

> There are problems in all the releases, we don't list them.

The title of the file is "Known problems in GDB 6.1".
Indeed, I would like it to actually list all the known problems.
We just don't have the resources to do this yet.

> The objective here is to draw the users attention to places where gdb is 
> both better and worse than the _last_ release (6.0).  Not a sorry list 
> of problems dateing back to version 0.0.

NEWS dates back to version 0.0, so I think that PROBLEMS should as well.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

This test case works with gdb 6.0 and it does not work with gdb gdb-6_1-branch.

  # gdb 6.0, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  $26 = yellow
  PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

  # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  A syntax error in expression, near `42'.
  KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

Actually, the word 'variable' is funny, because ClassWithEnum::PrivEnum
is a type, not a variable.  But that's what the test script calls this
problem.  And it's definitely a regression.

mec> gdb/931: GDB could be more generous when reading types C++
mec> templates on input
mec> 
mec> When the user types a template, GDB frequently requires the type to be
mec> typed in a certain way (e.g. "const char*" as opposed to "const char *"
mec> or "char const *" or "char const*").

dc> This also has always been the case.  It is the case that GDB's
dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but
dc> GDB has always had a preferred form.

Yes, I know.  If a user has a gdb script which pre-sets a lot of
breakpoints with "break 'Foo<volatile char*>::foo", they have to change
their script with each release of gdb.  That's why I consider this a
regression, because it breaks user scripts.  The regression in the
test scripts is just an indicator that user scripts will break too.
But it was worth some more text here.

mec> gdb/1512: no canonical way to output names of C++ types
mec> 
mec> We currently don't have any canonical way to output names of C++ types.
mec> E.g. "const char *" versus "char const *"; more subtleties aries when
mec> dealing with templates.

dc> Again, this has always been the case - this isn't a regression.

This is more subtle.  gdb has scripted input, but how many people have
scripted output for gdb?

That is, when gdb changes its output from this:

  (gdb) ptype fvpchar
  type = class Foo<volatile char *> {

to this:

  (gdb) ptype fvpchar
  type = class Foo<char volatile *> {

Is that going to break a contract we have with the users?  Are there any
users that are going to be affected, such as front ends that are parsing
or gdb's output?

I'm inclined to say "yes", because we do consider the second form
a KFAIL.  If both output forms are okay then I think the test script
should test them both.  But I'm more flexible on this than I am on
*input* form, where anything that used to be accepted in 6.0 and
is no longer accepted in 6.1 is likely to break a user script.

Michael C

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

> This test case works with gdb 6.0 and it does not work with gdb
> gdb-6_1-branch.

>   # gdb 6.0, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   $26 = yellow
>   PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

>   # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   A syntax error in expression, near `42'.
>   KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

> Actually, the word 'variable' is funny, because
> ClassWithEnum::PrivEnum is a type, not a variable.  But that's what
> the test script calls this problem.  And it's definitely a
> regression.

There are some situations where the names of types that are nested
within either namespaces or other types have to be enclosed within
single quotes.  And yes, this is a regression (though there aren't
very many situations where pre-6.1 GDB's would know about the names of
nested types to begin with).  I should probably file a separate PR
about it; it's extremely misleading to use the summary for PR gdb/826
to refer to this, because not only is this an area where GDB's
behavior has significantly improved when referring to variables that
aren't types, but there are situations where the user will get a
better result if they don't use single quotes than when they do.

mec> gdb/931: GDB could be more generous when reading types C++
mec> templates on input
mec> 
mec> When the user types a template, GDB frequently requires the type to be
mec> typed in a certain way (e.g. "const char*" as opposed to "const char *"
mec> or "char const *" or "char const*").

dc> This also has always been the case.  It is the case that GDB's
dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but
dc> GDB has always had a preferred form.

> Yes, I know.  If a user has a gdb script which pre-sets a lot of
> breakpoints with "break 'Foo<volatile char*>::foo", they have to change
> their script with each release of gdb.  That's why I consider this a
> regression, because it breaks user scripts.  The regression in the
> test scripts is just an indicator that user scripts will break too.
> But it was worth some more text here.

I don't mind mentioning this or gdb/1512, but I think the description
should be clear about what has changed, and in particular that GDB has
shifted from one behavior to another, neither of which is ideal.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

> This test case works with gdb 6.0 and it does not work with gdb
> gdb-6_1-branch.

>   # gdb 6.0, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   $26 = yellow
>   PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

>   # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   A syntax error in expression, near `42'.
>   KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

> Actually, the word 'variable' is funny, because
> ClassWithEnum::PrivEnum is a type, not a variable.  But that's what
> the test script calls this problem.  And it's definitely a
> regression.

There are some situations where the names of types that are nested
within either namespaces or other types have to be enclosed within
single quotes.  And yes, this is a regression (though there aren't
very many situations where pre-6.1 GDB's would know about the names of
nested types to begin with).  I should probably file a separate PR
about it; it's extremely misleading to use the summary for PR gdb/826
to refer to this, because not only is this an area where GDB's
behavior has significantly improved when referring to variables that
aren't types, but there are situations where the user will get a
better result if they don't use single quotes than when they do.

mec> gdb/931: GDB could be more generous when reading types C++
mec> templates on input
mec> 
mec> When the user types a template, GDB frequently requires the type to be
mec> typed in a certain way (e.g. "const char*" as opposed to "const char *"
mec> or "char const *" or "char const*").

dc> This also has always been the case.  It is the case that GDB's
dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but
dc> GDB has always had a preferred form.

> Yes, I know.  If a user has a gdb script which pre-sets a lot of
> breakpoints with "break 'Foo<volatile char*>::foo", they have to change
> their script with each release of gdb.  That's why I consider this a
> regression, because it breaks user scripts.  The regression in the
> test scripts is just an indicator that user scripts will break too.
> But it was worth some more text here.

I don't mind mentioning this or gdb/1512, but I think the description
should be clear about what has changed, and in particular that GDB has
shifted from one behavior to another, neither of which is ideal.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

> This test case works with gdb 6.0 and it does not work with gdb
> gdb-6_1-branch.

>   # gdb 6.0, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   $26 = yellow
>   PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

>   # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   A syntax error in expression, near `42'.
>   KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

> Actually, the word 'variable' is funny, because
> ClassWithEnum::PrivEnum is a type, not a variable.  But that's what
> the test script calls this problem.  And it's definitely a
> regression.

I don't think that looking for KFAILs is a good way to identify
whether or not a specific PR is a regression.  In this particular
instance, if you go to your table comparing 6.0 suite HEAD to 6.1
suite HEAD and, for example, look at the third column (GCC 3.3.3,
DWARF-2), you'll see a whole bunch of FAIL=>PASS transitions.  And a
_lot_ of them have to do with this bug being fixed: this is fairly
obvious in situations where, with GCC 6.0, "print 'AAA::c'" passes but
"print AAA::c" fails, but there are also examples further down where
there is no test using single quotes and where, if you did use single
quotes, you'd get unexpected output.

So I think the testsuite regression=>PR+description transition should
involve some more steps - the corresponding PR may be much broader
than the particular testsuite regression, and some of those broader
areas may involve situations where GDB has improved rather than
regressed.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

> This test case works with gdb 6.0 and it does not work with gdb
> gdb-6_1-branch.

>   # gdb 6.0, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   $26 = yellow
>   PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

>   # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
>   (gdb) print (ClassWithEnum::PrivEnum) 42
>   A syntax error in expression, near `42'.
>   KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

> Actually, the word 'variable' is funny, because
> ClassWithEnum::PrivEnum is a type, not a variable.  But that's what
> the test script calls this problem.  And it's definitely a
> regression.

I don't think that looking for KFAILs is a good way to identify
whether or not a specific PR is a regression.  In this particular
instance, if you go to your table comparing 6.0 suite HEAD to 6.1
suite HEAD and, for example, look at the third column (GCC 3.3.3,
DWARF-2), you'll see a whole bunch of FAIL=>PASS transitions.  And a
_lot_ of them have to do with this bug being fixed: this is fairly
obvious in situations where, with GCC 6.0, "print 'AAA::c'" passes but
"print AAA::c" fails, but there are also examples further down where
there is no test using single quotes and where, if you did use single
quotes, you'd get unexpected output.

So I think the testsuite regression=>PR+description transition should
involve some more steps - the corresponding PR may be much broader
than the particular testsuite regression, and some of those broader
areas may involve situations where GDB has improved rather than
regressed.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes
mec> 
mec> When referring to a variable in C++ code that is inside a
mec> namespace, you have to put it inside single quotes.

dc> This is only true in rare circumstances, and it was always true in
dc> versions before 6.1!  So whatever it might be, it's not a regression.
dc> (Hmm: I should probably close that bug report, since it should largely
dc> be fixed by now.)

This test case works with gdb 6.0 and it does not work with gdb gdb-6_1-branch.

  # gdb 6.0, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  $26 = yellow
  PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42

  # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+
  (gdb) print (ClassWithEnum::PrivEnum) 42
  A syntax error in expression, near `42'.
  KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)

Actually, the word 'variable' is funny, because ClassWithEnum::PrivEnum
is a type, not a variable.  But that's what the test script calls this
problem.  And it's definitely a regression.

mec> gdb/931: GDB could be more generous when reading types C++
mec> templates on input
mec> 
mec> When the user types a template, GDB frequently requires the type to be
mec> typed in a certain way (e.g. "const char*" as opposed to "const char *"
mec> or "char const *" or "char const*").

dc> This also has always been the case.  It is the case that GDB's
dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but
dc> GDB has always had a preferred form.

Yes, I know.  If a user has a gdb script which pre-sets a lot of
breakpoints with "break 'Foo<volatile char*>::foo", they have to change
their script with each release of gdb.  That's why I consider this a
regression, because it breaks user scripts.  The regression in the
test scripts is just an indicator that user scripts will break too.
But it was worth some more text here.

mec> gdb/1512: no canonical way to output names of C++ types
mec> 
mec> We currently don't have any canonical way to output names of C++ types.
mec> E.g. "const char *" versus "char const *"; more subtleties aries when
mec> dealing with templates.

dc> Again, this has always been the case - this isn't a regression.

This is more subtle.  gdb has scripted input, but how many people have
scripted output for gdb?

That is, when gdb changes its output from this:

  (gdb) ptype fvpchar
  type = class Foo<volatile char *> {

to this:

  (gdb) ptype fvpchar
  type = class Foo<char volatile *> {

Is that going to break a contract we have with the users?  Are there any
users that are going to be affected, such as front ends that are parsing
or gdb's output?

I'm inclined to say "yes", because we do consider the second form
a KFAIL.  If both output forms are okay then I think the test script
should test them both.  But I'm more flexible on this than I am on
*input* form, where anything that used to be accepted in 6.0 and
is no longer accepted in 6.1 is likely to break a user script.

Michael C

[rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

Here is an update for PROBLEMS.

I added all the regressions that I know about from gdb 6.0 to gdb 6.1.
I also added some section headers, "Regressions since gdb 6.0"
and "Regressions since gdb 5.3".

I would like to commit this to both gdb HEAD and gdb gdb_6_1-branch.

Okay to commit to HEAD?
Okay to commit to the branch?

Michael C

2004-03-16  Michael Chastain  <mec.gnu@mindspring.com>

	* PROBLEMS: Add section headers, "Regressions since gdb 6.0"
	and "Regressions since gdb 5.3.".  Add all the regressions
	I know about since gdb 6.0.

Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.23
diff -u -c -3 -p -r1.23 PROBLEMS
*** PROBLEMS	29 Feb 2004 02:57:24 -0000	1.23
--- PROBLEMS	17 Mar 2004 01:50:08 -0000
*************** Fortunately the ARM target, in the GDB's
*** 23,28 ****
--- 23,52 ----
  updated so people encountering problems should consider downloading a
  more current GDB (http://www.gnu.org/software/gdb/current).
  
+ *** Regressions since gdb 6.0
+ 
+ gdb/826: variables in C++ namespaces have to be enclosed in quotes
+ 
+ When referring to a variable in C++ code that is inside a
+ namespace, you have to put it inside single quotes.
+ 
+ gdb/931: GDB could be more generous when reading types C++ templates on input
+ 
+ When the user types a template, GDB frequently requires the type to be
+ typed in a certain way (e.g. "const char*" as opposed to "const char *"
+ or "char const *" or "char const*").
+ 
+ gdb/1505: [regression] gdb prints a bad backtrace for a thread
+ 
+ When backtracing a thread, gdb doesn't stop until it hits garbage.
+ This is sensitive to the operating system and thread library.
+ 
+ gdb/1512: no canonical way to output names of C++ types
+ 
+ We currently don't have any canonical way to output names of C++ types.
+ E.g. "const char *" versus "char const *"; more subtleties aries when
+ dealing with templates.
+ 
  gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
  
  With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
*************** This applies only to classes where the c
*** 35,40 ****
--- 59,73 ----
  function, not to variables defined with types that are defined somewhere
  outside any function (which most types are).
  
+ gdb/1560: Control-C does not always interrupt GDB.
+ 
+ When GDB is busy processing a command which takes a long time to
+ complete, hitting Control-C does not have the expected effect.
+ The command execution is not aborted, and the "QUIT" message confirming
+ the abortion is displayed only after the command has been completed.
+ 
+ *** Regressions since gdb 5.3
+ 
  gdb/1091: Constructor breakpoints ignored
  gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
  
*************** implement virtual base classes.  gcc 2.x
*** 52,59 ****
  function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
  ABI for C++ which requires multiple object code functions.
  
- gdb/1560: Control-C does not always interrupt GDB.
- When GDB is busy processing a command which takes a long time to
- complete, hitting Control-C does not have the expected effect.
- The command execution is not aborted, and the "QUIT" message confirming
- the abortion is displayed only after the command has been completed.
--- 85,87 ----

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

> Here is an update for PROBLEMS.
> 
> I added all the regressions that I know about from gdb 6.0 to gdb 6.1.
> I also added some section headers, "Regressions since gdb 6.0"
> and "Regressions since gdb 5.3".

I don't think it should retain regressions since 5.3, the file is 
stating problems in this release, not the last one.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

> Here is an update for PROBLEMS.
> 
> I added all the regressions that I know about from gdb 6.0 to gdb 6.1.
> I also added some section headers, "Regressions since gdb 6.0"
> and "Regressions since gdb 5.3".

I don't think it should retain regressions since 5.3, the file is 
stating problems in this release, not the last one.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Tue, 16 Mar 2004 20:53:43 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

> + gdb/826: variables in C++ namespaces have to be enclosed in quotes
> + 
> + When referring to a variable in C++ code that is inside a
> + namespace, you have to put it inside single quotes.

This is only true in rare circumstances, and it was always true in
versions before 6.1!  So whatever it might be, it's not a regression.
(Hmm: I should probably close that bug report, since it should largely
be fixed by now.)

> + gdb/931: GDB could be more generous when reading types C++
>   templates on input

> + When the user types a template, GDB frequently requires the type to be
> + typed in a certain way (e.g. "const char*" as opposed to "const char *"
> + or "char const *" or "char const*").

This also has always been the case.  It is the case that GDB's
preferred form has, in some circumstances changed from 6.0 to 6.1, but
GDB has always had a preferred form.

> + gdb/1512: no canonical way to output names of C++ types
> + 
> + We currently don't have any canonical way to output names of C++ types.
> + E.g. "const char *" versus "char const *"; more subtleties aries when
> + dealing with templates.

Again, this has always been the case - this isn't a regression.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Tue, 16 Mar 2004 20:53:43 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

> + gdb/826: variables in C++ namespaces have to be enclosed in quotes
> + 
> + When referring to a variable in C++ code that is inside a
> + namespace, you have to put it inside single quotes.

This is only true in rare circumstances, and it was always true in
versions before 6.1!  So whatever it might be, it's not a regression.
(Hmm: I should probably close that bug report, since it should largely
be fixed by now.)

> + gdb/931: GDB could be more generous when reading types C++
>   templates on input

> + When the user types a template, GDB frequently requires the type to be
> + typed in a certain way (e.g. "const char*" as opposed to "const char *"
> + or "char const *" or "char const*").

This also has always been the case.  It is the case that GDB's
preferred form has, in some circumstances changed from 6.0 to 6.1, but
GDB has always had a preferred form.

> + gdb/1512: no canonical way to output names of C++ types
> + 
> + We currently don't have any canonical way to output names of C++ types.
> + E.g. "const char *" versus "char const *"; more subtleties aries when
> + dealing with templates.

Again, this has always been the case - this isn't a regression.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Tue, 16 Mar 2004 20:53:43 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> I would like to commit this to both gdb HEAD and gdb gdb_6_1-branch.
> 
> Okay to commit to HEAD?
> Okay to commit to the branch?

Okay with me, but...

> 	* PROBLEMS: Add section headers, "Regressions since gdb 6.0"
> 	and "Regressions since gdb 5.3.".  Add all the regressions
> 	I know about since gdb 6.0.

The last sentence should probably say "Add known regressions since
gdb 6.0."  ``regressions I know about'' is not something that should
be in a ChangeLog; it goes without saying that ``known'' means
``known to the person who makes the change.''

> + We currently don't have any canonical way to output names of C++ types.
> + E.g. "const char *" versus "char const *"; more subtleties aries when
                                                               ^^^^^
A typo.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Tue, 16 Mar 2004 20:53:43 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> I would like to commit this to both gdb HEAD and gdb gdb_6_1-branch.
> 
> Okay to commit to HEAD?
> Okay to commit to the branch?

Okay with me, but...

> 	* PROBLEMS: Add section headers, "Regressions since gdb 6.0"
> 	and "Regressions since gdb 5.3.".  Add all the regressions
> 	I know about since gdb 6.0.

The last sentence should probably say "Add known regressions since
gdb 6.0."  ``regressions I know about'' is not something that should
be in a ChangeLog; it goes without saying that ``known'' means
``known to the person who makes the change.''

> + We currently don't have any canonical way to output names of C++ types.
> + E.g. "const char *" versus "char const *"; more subtleties aries when
                                                               ^^^^^
A typo.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Tue, 16 Mar 2004 20:53:43 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

> Here is an update for PROBLEMS.

> + *** Regressions since gdb 5.3
> + 
>   gdb/1091: Constructor breakpoints ignored
>   gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints

These aren't regressions since 5.3: I know the first one has been
around for a while, and the second one says that it occurs in 5.3 in
its summary line! :-)

While we're updating PROBLEMS, is the list of targets that don't use
the new frame code accurate?  (Sparc, mips, ppc, arm.)  I thought that
SPARC at least was using the new frame code in 6.1?  Not that I follow
these things too closely...

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Tue, 16 Mar 2004 20:53:43 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said:

> Here is an update for PROBLEMS.

> + *** Regressions since gdb 5.3
> + 
>   gdb/1091: Constructor breakpoints ignored
>   gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints

These aren't regressions since 5.3: I know the first one has been
around for a while, and the second one says that it occurs in 5.3 in
its summary line! :-)

While we're updating PROBLEMS, is the list of targets that don't use
the new frame code accurate?  (Sparc, mips, ppc, arm.)  I thought that
SPARC at least was using the new frame code in 6.1?  Not that I follow
these things too closely...

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Wed, 17 Mar 2004 09:19:23 -0800
> 
> While we're updating PROBLEMS, is the list of targets that don't use
> the new frame code accurate?  (Sparc, mips, ppc, arm.)

Do users care?  What user-level effect will one see on those targets
that don't use the new frame code?

IMHO, if there are no user-level issues, we shouldn't mention this in
PROBLEMS.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Wed, 17 Mar 2004 09:19:23 -0800
> 
> While we're updating PROBLEMS, is the list of targets that don't use
> the new frame code accurate?  (Sparc, mips, ppc, arm.)

Do users care?  What user-level effect will one see on those targets
that don't use the new frame code?

IMHO, if there are no user-level issues, we shouldn't mention this in
PROBLEMS.

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>From: David Carlton <carlton@kealia.com>
>>> Date: Wed, 17 Mar 2004 09:19:23 -0800
>>> 
>>> While we're updating PROBLEMS, is the list of targets that don't use
>>> the new frame code accurate?  (Sparc, mips, ppc, arm.)
> 
> 
> Do users care?  What user-level effect will one see on those targets
> that don't use the new frame code?
> 
> IMHO, if there are no user-level issues, we shouldn't mention this in
> PROBLEMS.

- arches using the old frame stuff are typically in worse shape
- arches using the old frame stuff can't use CFI (i.e., can't use 
exploit GCC's frame debug info)

the second one in particular is of issue to users - it affects GDB's 
ability to do decent backtraces (especially through glibc).

Yes, the list needs updating, SPARC and ARM are done.  MIPS and PA are 
"done" (it lost the signal stuff).  For PPC, that will be 6.2, which 
leaves a few strays.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

>>From: David Carlton <carlton@kealia.com>
>>> Date: Wed, 17 Mar 2004 09:19:23 -0800
>>> 
>>> While we're updating PROBLEMS, is the list of targets that don't use
>>> the new frame code accurate?  (Sparc, mips, ppc, arm.)
> 
> 
> Do users care?  What user-level effect will one see on those targets
> that don't use the new frame code?
> 
> IMHO, if there are no user-level issues, we shouldn't mention this in
> PROBLEMS.

- arches using the old frame stuff are typically in worse shape
- arches using the old frame stuff can't use CFI (i.e., can't use 
exploit GCC's frame debug info)

the second one in particular is of issue to users - it affects GDB's 
ability to do decent backtraces (especially through glibc).

Yes, the list needs updating, SPARC and ARM are done.  MIPS and PA are 
"done" (it lost the signal stuff).  For PPC, that will be 6.2, which 
leaves a few strays.

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Wed, 17 Mar 2004 15:25:16 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> - arches using the old frame stuff are typically in worse shape

I don't think we can tell users their target is ``in worse shape''
without being specific.  It sounds like FUD, even though I realize it
isn't.  If we want to tell users their target suffers from problems,
we should make the effort of spelling out those problems in terms
users can understand and act upon.

> - arches using the old frame stuff can't use CFI (i.e., can't use 
> exploit GCC's frame debug info)
> 
> the second one in particular is of issue to users - it affects GDB's 
> ability to do decent backtraces (especially through glibc).

This is IMHO better than just ``in worse shape'', but it's still not
detailed enough.  I, for one, don't understand the real meaning of
``decent backtraces''.  What does it mean? do I get garbage in some or
all frames? does the backtrace stop short of showing be the whole
picture? which frames are susceptible and what can I do to alleviate
that (compilation options, perhaps)?  Etc., etc.

Also, are there actually targets that use the old frame stuff _and_
use glibc?  (It strikes me that the crazy techniques used by glibc are
as guilty for breaking GDB as the oldish targets.)

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Wed, 17 Mar 2004 15:25:16 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> - arches using the old frame stuff are typically in worse shape

I don't think we can tell users their target is ``in worse shape''
without being specific.  It sounds like FUD, even though I realize it
isn't.  If we want to tell users their target suffers from problems,
we should make the effort of spelling out those problems in terms
users can understand and act upon.

> - arches using the old frame stuff can't use CFI (i.e., can't use 
> exploit GCC's frame debug info)
> 
> the second one in particular is of issue to users - it affects GDB's 
> ability to do decent backtraces (especially through glibc).

This is IMHO better than just ``in worse shape'', but it's still not
detailed enough.  I, for one, don't understand the real meaning of
``decent backtraces''.  What does it mean? do I get garbage in some or
all frames? does the backtrace stop short of showing be the whole
picture? which frames are susceptible and what can I do to alleviate
that (compilation options, perhaps)?  Etc., etc.

Also, are there actually targets that use the old frame stuff _and_
use glibc?  (It strikes me that the crazy techniques used by glibc are
as guilty for breaking GDB as the oldish targets.)

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Daniel Jacobowitz]

On Thu, Mar 18, 2004 at 08:10:53AM +0200, Eli Zaretskii wrote:
> This is IMHO better than just ``in worse shape'', but it's still not
> detailed enough.  I, for one, don't understand the real meaning of
> ``decent backtraces''.  What does it mean? do I get garbage in some or
> all frames? does the backtrace stop short of showing be the whole
> picture? which frames are susceptible and what can I do to alleviate
> that (compilation options, perhaps)?  Etc., etc.

All of the above problems are likely.  Relevant compiler options tend
to vary by architecture.

> Also, are there actually targets that use the old frame stuff _and_
> use glibc?  (It strikes me that the crazy techniques used by glibc are
> as guilty for breaking GDB as the oldish targets.)

It actually has more to do with GCC than glibc, except for the
recurring problems with syscall unwinders - generic hunks of assembly
code that, in the new model, we can annotate with unwind information.
Yes, several glibc targets still use the old code, but the number's
shrunk drastically since 6.1.  IIRC the PPC target has been converted
in HEAD but not 6.1.  I think there's at least one more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Andrew Cagney]

> I think there's at least one more.

FYI: h8300, mcore, mn10300, ns32k, sh64, vax, xstormy16

but none of these are "mainstream".

Andrew

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Daniel Jacobowitz]

On Thu, Mar 18, 2004 at 02:24:56PM -0500, Andrew Cagney wrote:
> >I think there's at least one more.
> 
> FYI: h8300, mcore, mn10300, ns32k, sh64, vax, xstormy16
> 
> but none of these are "mainstream".

Thanks.  In that case, none other than PPC - since Eli's question was
specifically what used glibc.  I'm sure someone internally at some
company(ies) has mn10300 and sh64 glibc ports but they aren't in the
normal glibc tree.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Daniel Jacobowitz]

On Thu, Mar 18, 2004 at 08:10:53AM +0200, Eli Zaretskii wrote:
> This is IMHO better than just ``in worse shape'', but it's still not
> detailed enough.  I, for one, don't understand the real meaning of
> ``decent backtraces''.  What does it mean? do I get garbage in some or
> all frames? does the backtrace stop short of showing be the whole
> picture? which frames are susceptible and what can I do to alleviate
> that (compilation options, perhaps)?  Etc., etc.

All of the above problems are likely.  Relevant compiler options tend
to vary by architecture.

> Also, are there actually targets that use the old frame stuff _and_
> use glibc?  (It strikes me that the crazy techniques used by glibc are
> as guilty for breaking GDB as the oldish targets.)

It actually has more to do with GCC than glibc, except for the
recurring problems with syscall unwinders - generic hunks of assembly
code that, in the new model, we can annotate with unwind information.
Yes, several glibc targets still use the old code, but the number's
shrunk drastically since 6.1.  IIRC the PPC target has been converted
in HEAD but not 6.1.  I think there's at least one more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 11:36:55 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, Mar 18, 2004 at 08:10:53AM +0200, Eli Zaretskii wrote:
> > This is IMHO better than just ``in worse shape'', but it's still not
> > detailed enough.  I, for one, don't understand the real meaning of
> > ``decent backtraces''.  What does it mean? do I get garbage in some or
> > all frames? does the backtrace stop short of showing be the whole
> > picture? which frames are susceptible and what can I do to alleviate
> > that (compilation options, perhaps)?  Etc., etc.
> 
> All of the above problems are likely.

Well, in that case, I think we should mention them all.

> Relevant compiler options tend to vary by architecture.

Can we mention the options for at least a couple of the most popular
architectures that suffer from such problems?

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Eli Zaretskii]

> Date: Thu, 18 Mar 2004 11:36:55 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, Mar 18, 2004 at 08:10:53AM +0200, Eli Zaretskii wrote:
> > This is IMHO better than just ``in worse shape'', but it's still not
> > detailed enough.  I, for one, don't understand the real meaning of
> > ``decent backtraces''.  What does it mean? do I get garbage in some or
> > all frames? does the backtrace stop short of showing be the whole
> > picture? which frames are susceptible and what can I do to alleviate
> > that (compilation options, perhaps)?  Etc., etc.
> 
> All of the above problems are likely.

Well, in that case, I think we should mention them all.

> Relevant compiler options tend to vary by architecture.

Can we mention the options for at least a couple of the most popular
architectures that suffer from such problems?

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 21:05:00 +0200, "Eli Zaretskii" <eliz@elta.co.il> said:
>> From: David Carlton <carlton@kealia.com>
>> Date: Wed, 17 Mar 2004 09:19:23 -0800

>> While we're updating PROBLEMS, is the list of targets that don't use
>> the new frame code accurate?  (Sparc, mips, ppc, arm.)

> Do users care?  What user-level effect will one see on those targets
> that don't use the new frame code?

> IMHO, if there are no user-level issues, we shouldn't mention this
> in PROBLEMS.

Good point.

David Carlton
carlton@kealia.com

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0

[David Carlton]

On Wed, 17 Mar 2004 21:05:00 +0200, "Eli Zaretskii" <eliz@elta.co.il> said:
>> From: David Carlton <carlton@kealia.com>
>> Date: Wed, 17 Mar 2004 09:19:23 -0800

>> While we're updating PROBLEMS, is the list of targets that don't use
>> the new frame code accurate?  (Sparc, mips, ppc, arm.)

> Do users care?  What user-level effect will one see on those targets
> that don't use the new frame code?

> IMHO, if there are no user-level issues, we shouldn't mention this
> in PROBLEMS.

Good point.

David Carlton
carlton@kealia.com

[rfa/doco] PROBLEMS: add regressions since gdb 6.0

[Michael Elizabeth Chastain]

Here is an update for PROBLEMS.

I added all the regressions that I know about from gdb 6.0 to gdb 6.1.
I also added some section headers, "Regressions since gdb 6.0"
and "Regressions since gdb 5.3".

I would like to commit this to both gdb HEAD and gdb gdb_6_1-branch.

Okay to commit to HEAD?
Okay to commit to the branch?

Michael C

2004-03-16  Michael Chastain  <mec.gnu@mindspring.com>

	* PROBLEMS: Add section headers, "Regressions since gdb 6.0"
	and "Regressions since gdb 5.3.".  Add all the regressions
	I know about since gdb 6.0.

Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.23
diff -u -c -3 -p -r1.23 PROBLEMS
*** PROBLEMS	29 Feb 2004 02:57:24 -0000	1.23
--- PROBLEMS	17 Mar 2004 01:50:08 -0000
*************** Fortunately the ARM target, in the GDB's
*** 23,28 ****
--- 23,52 ----
  updated so people encountering problems should consider downloading a
  more current GDB (http://www.gnu.org/software/gdb/current).
  
+ *** Regressions since gdb 6.0
+ 
+ gdb/826: variables in C++ namespaces have to be enclosed in quotes
+ 
+ When referring to a variable in C++ code that is inside a
+ namespace, you have to put it inside single quotes.
+ 
+ gdb/931: GDB could be more generous when reading types C++ templates on input
+ 
+ When the user types a template, GDB frequently requires the type to be
+ typed in a certain way (e.g. "const char*" as opposed to "const char *"
+ or "char const *" or "char const*").
+ 
+ gdb/1505: [regression] gdb prints a bad backtrace for a thread
+ 
+ When backtracing a thread, gdb doesn't stop until it hits garbage.
+ This is sensitive to the operating system and thread library.
+ 
+ gdb/1512: no canonical way to output names of C++ types
+ 
+ We currently don't have any canonical way to output names of C++ types.
+ E.g. "const char *" versus "char const *"; more subtleties aries when
+ dealing with templates.
+ 
  gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
  
  With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
*************** This applies only to classes where the c
*** 35,40 ****
--- 59,73 ----
  function, not to variables defined with types that are defined somewhere
  outside any function (which most types are).
  
+ gdb/1560: Control-C does not always interrupt GDB.
+ 
+ When GDB is busy processing a command which takes a long time to
+ complete, hitting Control-C does not have the expected effect.
+ The command execution is not aborted, and the "QUIT" message confirming
+ the abortion is displayed only after the command has been completed.
+ 
+ *** Regressions since gdb 5.3
+ 
  gdb/1091: Constructor breakpoints ignored
  gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
  
*************** implement virtual base classes.  gcc 2.x
*** 52,59 ****
  function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
  ABI for C++ which requires multiple object code functions.
  
- gdb/1560: Control-C does not always interrupt GDB.
- When GDB is busy processing a command which takes a long time to
- complete, hitting Control-C does not have the expected effect.
- The command execution is not aborted, and the "QUIT" message confirming
- the abortion is displayed only after the command has been completed.
--- 85,87 ----