* Re: gdb 5.3 versus gdb HEAD%200302015
@ 2003-02-17 16:44 Michael Elizabeth Chastain
2003-02-17 16:50 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-17 16:44 UTC (permalink / raw)
To: drow, gdb
> Nope, there was no PR, just a patch when I noticed it. Besides, didn't
> we want to only use PRs in the GDB database? This would be an
> external/closed.
Works for me. Heck, I think I argued for that position anyways!
Unfortunately gdb_mi_test does not have a multi-armed form so
I have to use a blunt setup_kfail.
I'll go file an external/closed PR for this and then point the
test case at it.
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 16:44 gdb 5.3 versus gdb HEAD%200302015 Michael Elizabeth Chastain
@ 2003-02-17 16:50 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-02-17 16:50 UTC (permalink / raw)
To: gdb
On Mon, Feb 17, 2003 at 10:44:03AM -0600, Michael Elizabeth Chastain wrote:
> > Nope, there was no PR, just a patch when I noticed it. Besides, didn't
> > we want to only use PRs in the GDB database? This would be an
> > external/closed.
>
> Works for me. Heck, I think I argued for that position anyways!
>
> Unfortunately gdb_mi_test does not have a multi-armed form so
> I have to use a blunt setup_kfail.
>
> I'll go file an external/closed PR for this and then point the
> test case at it.
If you use a setup_kfail, won't it start showing up as a KPASS for all
of us with fixed GCCs?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 15:32 Michael Elizabeth Chastain
2003-02-17 15:39 ` Daniel Jacobowitz
2003-02-17 17:03 ` David Carlton
@ 2003-02-18 14:59 ` Michal Ludvig
2 siblings, 0 replies; 11+ messages in thread
From: Michal Ludvig @ 2003-02-18 14:59 UTC (permalink / raw)
To: Michael Elizabeth Chastain, gdb
Michael Elizabeth Chastain wrote:
> . x86-64 regressions
>
> Michal Ludvig reported that native x86_64-unknown-linux-gnu
> regressed significantly from gdb 5.3 to gdb 2003-02-01-cvs. He has
> been actively working on bringing this target back up to 5.3
> quality. I don't know if he's finished yet.
It's better, but still not as good as 5.3. There is a problem with
functions called from the (gdb) command line that make GDB crash.
Because it's happening in Andrew's patch, I've sent him some more info
so that he could look where was the problem.
Michal Ludvig
--
* SuSE CR, s.r.o * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 17:08 Michael Elizabeth Chastain
@ 2003-02-17 17:13 ` David Carlton
0 siblings, 0 replies; 11+ messages in thread
From: David Carlton @ 2003-02-17 17:13 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: gdb
On Mon, 17 Feb 2003 11:08:34 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
>> I'm curious: what shows up in gdb.log when you get FAIL here?
> print pEe->D::vg()^M
> $12 = 202^M
> (gdb) FAIL: gdb.c++/virtfunc.exp: print pEe->D::vg()
> This happens with gcc 2.95.3, both dwarf-2 and stabs+.
> It's a different bug than the bug you PR'd. With gcc v3,
> I get "Attempt to take address of value not located in memory."
> With gcc v2, I get the wrong answer (the right answer is 102).
> It looks like gdb is ignoring the 'D::' qualifier and calling
> E::vg instead of D::vg.
Interesting: it does indeed look like a different bug. So:
>> Certainly you should feel free to add more KFAIL branches to that test
>> if you wish; just send them all to the same PR.
> In this case I think it should be a different KFAIL arm
> pointing to a different PR.
I guess that makes sense.
David Carlton
carlton@math.stanford.edu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
@ 2003-02-17 17:08 Michael Elizabeth Chastain
2003-02-17 17:13 ` David Carlton
0 siblings, 1 reply; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-17 17:08 UTC (permalink / raw)
To: carlton; +Cc: gdb
> I'm curious: what shows up in gdb.log when you get FAIL here?
print pEe->D::vg()^M
$12 = 202^M
(gdb) FAIL: gdb.c++/virtfunc.exp: print pEe->D::vg()
This happens with gcc 2.95.3, both dwarf-2 and stabs+.
It's a different bug than the bug you PR'd. With gcc v3,
I get "Attempt to take address of value not located in memory."
With gcc v2, I get the wrong answer (the right answer is 102).
It looks like gdb is ignoring the 'D::' qualifier and calling
E::vg instead of D::vg.
> Certainly you should feel free to add more KFAIL branches to that test
> if you wish; just send them all to the same PR.
In this case I think it should be a different KFAIL arm
pointing to a different PR.
I will do this tonight unless you beat me to it.
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 15:32 Michael Elizabeth Chastain
2003-02-17 15:39 ` Daniel Jacobowitz
@ 2003-02-17 17:03 ` David Carlton
2003-02-18 14:59 ` Michal Ludvig
2 siblings, 0 replies; 11+ messages in thread
From: David Carlton @ 2003-02-17 17:03 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: gdb
On Sun, 16 Feb 2003 21:32:34 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
> . gdb.c++/virtfunc.exp: print pEe->D::vg()
> XFAIL -> FAIL
> XFAIL -> KFAIL
> Needs investigation.
> Probably gdb stayed the same and the test suite improved.
I'm curious: what shows up in gdb.log when you get FAIL here? I just
KFAILed the output I saw; I have no reason to believe that there
aren't other valid outputs that would manifest the same bug, however.
Certainly you should feel free to add more KFAIL branches to that test
if you wish; just send them all to the same PR.
David Carlton
carlton@math.stanford.edu
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
@ 2003-02-17 17:02 Michael Elizabeth Chastain
0 siblings, 0 replies; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-17 17:02 UTC (permalink / raw)
To: drow, gdb
> If you use a setup_kfail, won't it start showing up as a KPASS for all
> of us with fixed GCCs?
Argh. You are right. I'll have to go with send_gdb/gdb_expect.
I've never done that in an MI context before. Time to study the
mi_support.exp.
(I have an afternoon date so this is my last message until this evening).
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 16:32 Michael Elizabeth Chastain
@ 2003-02-17 16:35 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-02-17 16:35 UTC (permalink / raw)
To: gdb
On Mon, Feb 17, 2003 at 10:32:30AM -0600, Michael Elizabeth Chastain wrote:
> drow> Ooh ooh. I got this one. The test is new in HEAD (wasn't in 5.3);
> drow> it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any. I
> drow> checked the patch in the day after 3.2.2.
>
> Beautiful, I'll just slip a URL to this message into my tracking
> document. That takes care of the 5.4/6.0 angle.
>
> My results are:
>
> PASS for all stabs+
> PASS for dwarf-2, gcc gcc-3_3-branch and gcc HEAD
> FAIL for dwarf-2, gcc 2.95.3 and gcc 3.2-7-rh and gcc 3.2.2
>
> Which matches your report.
>
> I dropped coverage of gcc gcc-3_2-branch, but I might bring it back,
> because I see that people are still checking into that branch.
>
> The real question: is there a gcc PR for this. If there is a gcc PR,
> then I can add an XFAIL arm to the test with the gcc PR number.
Nope, there was no PR, just a patch when I noticed it. Besides, didn't
we want to only use PRs in the GDB database? This would be an
external/closed.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
@ 2003-02-17 16:32 Michael Elizabeth Chastain
2003-02-17 16:35 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-17 16:32 UTC (permalink / raw)
To: drow, gdb
drow> Ooh ooh. I got this one. The test is new in HEAD (wasn't in 5.3);
drow> it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any. I
drow> checked the patch in the day after 3.2.2.
Beautiful, I'll just slip a URL to this message into my tracking
document. That takes care of the 5.4/6.0 angle.
My results are:
PASS for all stabs+
PASS for dwarf-2, gcc gcc-3_3-branch and gcc HEAD
FAIL for dwarf-2, gcc 2.95.3 and gcc 3.2-7-rh and gcc 3.2.2
Which matches your report.
I dropped coverage of gcc gcc-3_2-branch, but I might bring it back,
because I see that people are still checking into that branch.
The real question: is there a gcc PR for this. If there is a gcc PR,
then I can add an XFAIL arm to the test with the gcc PR number.
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb 5.3 versus gdb HEAD%200302015
2003-02-17 15:32 Michael Elizabeth Chastain
@ 2003-02-17 15:39 ` Daniel Jacobowitz
2003-02-17 17:03 ` David Carlton
2003-02-18 14:59 ` Michal Ludvig
2 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2003-02-17 15:39 UTC (permalink / raw)
To: gdb
On Sun, Feb 16, 2003 at 09:32:34PM -0600, Michael Elizabeth Chastain wrote:
> . gdb.mi/gdb701.exp: create fooPtr
>
> Needs investigation.
Ooh ooh. I got this one. The test is new in HEAD (wasn't in 5.3);
it's a GCC bug; it will be fixed in 3.3, 3.4, and 3.2.3 if any. I
checked the patch in the day after 3.2.2.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* gdb 5.3 versus gdb HEAD%200302015
@ 2003-02-17 15:32 Michael Elizabeth Chastain
2003-02-17 15:39 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Michael Elizabeth Chastain @ 2003-02-17 15:32 UTC (permalink / raw)
To: gdb
Here's a list of all the issues that I've heard about that affect the
next release of gdb, 5.4/6.0. Many of these need more investigation,
but I think I have enough info here to take up some bandwidth.
Michael C
. MI issues
Andrew C attempted to obsolete annotation level 2 and got a lot of
push-back from gdb front end writers who say that MI is not good
enough for them to switch at all. I don't know what our goal is for
MI in the next release, so i can't say how much of this work needs
to be done by the next release.
. build issues
Andrew C says that there are several high priority PR's about build
issues.
. gcc 3.3 and gcc 3.4 emit bad C++ stabs
pr gdb/1026: ...
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1026
pr gcc/9NNN: ...
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&cmd=view&pr=9NNN
Daniel J says this is a bug in gcc and I agree. I isolated the
patch that caused the problem. It looks easy to fix; so easy that I
wrote a fix. I reached out to gcc people on 2003-02-16 and am
waiting for a reply.
. x86-64 regressions
Michal Ludvig reported that native x86_64-unknown-linux-gnu
regressed significantly from gdb 5.3 to gdb 2003-02-01-cvs. He has
been actively working on bringing this target back up to 5.3
quality. I don't know if he's finished yet.
. jmisc2.exp regression
pr gdb/1039: regression: cannot set breakpoint on jmisc.main(java.lang.String[])
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1039
. gdb.mi/gdb701.exp: create fooPtr
Needs investigation.
. gdb test suite regressions
The test suite found three issues above: the gcc C++ bad stabs,
the jmisc2.exp regressions, and gdb701.exp FAILs.
Details below for all the test result changes between gcc 5.3 and
gcc HEAD%20030215. The tables are directly from:
http://www.shout.net/~mec/sunday/2003-02-15/Compare-by-gdb.html
. gdb.base/constvars.exp: ptype crass
null -> PASS
null -> XFAIL
This is a new test.
This test does 'ptype' on a structure with a 'char * const ptr'
member. With gdb 5.3 and dwarf-2, gdb prints the structure member
as 'char * constptr' with the single word 'constptr' -- obviously
incorrect. With gdb 5.3 and stabs+, gdb prints the structure
member as 'char *ptr', dropping the const.
With gdb HEAD%20030215 and dwarf-2, gdb prints 'char * const ptr',
which is correct. With gdb HEAD%20030215 and stabs+, gdb prints
'char *ptr', the same bad behavior as gdb 5.3.
. gdb.base/constvars.exp: ptype crisp
null -> PASS
null -> XFAIL
This is a new test.
This test does 'ptype' on a structure with a 'char * const *ptr'
member. gdb 5.3 and gdb HEAD%20030215 have the same behavior,
modulo whitespace changes. They both respond correctly with gcc
2.95.3 dwarf-2, gcc 3.X dwarf-2, and gcc 3.X stabs+; and they both
respond incorrectly with gcc 2.95.3 stabs+: 'char **' instead of
'char * const *'.
. gdb.base/ending-run.exp: continue after exit
null -> UNSUPPORTED
This is a new test which is working properly.
Some configurations (I don't know which ones) can land in a DLD
function after leaving main(). These configurations run this
particular test. Other configurations return UNSUPPORTED for this
test.
gdb's behavior is fine. I find the UNSUPPORTED a bit gratuitous.
Perhaps the test script should do nothing rather than generate an
UNSUPPORTED.
. gdb.c++/annota2.exp: annotate-quit
pr gdb/544: gdb.c++/annota2.exp: annotate-quit test sometimes fails
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=544
Fluctuation in test result probably due to a signal handling race
in the command loop.
This was in gdb 5.3 and previous gdb releases. There was a brief
time around 200302012 when the new interpreter loop fixed it, but
that code broke ^Z handling. The fix for ^Z brought this bug back
again.
. gdb.c++/casts.exp: cast base class pointer to derived class pointer
gdb.c++/casts.exp: cast base class pointer to derived class pointer
null -> FAIL
stabs+ with gcc gcc-3_3-branch, gcc HEAD
This is a high-priority bug. It might be in either gdb or gcc.
gcc changed its stabs+ output, and gdb does not handle the new
output. pr gdb/1026.
. gdb.c++/classes.exp: ptype struct default_public_struct
UNRESOLVED -> XFAIL
This is an artifact of a cascade problem in with anon-union.exp,
the previous test script. The prime problem is a gcc internal
compiler error with anon-union.c (pr gcc/9039). gdb HEAD%20030215
stifles the cascade although the prime problem continues.
. gdb.c++/local.exp: Local out of scope
null -> PASS
null -> KFAIL
pr gdb/825: gdb gets scope of class local to a function wrong
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=825
This is a new test. Both gdb 5.3 and gdb HEAD%20030215 have this bug.
With gdb HEAD%20030215, this test PASSed with gcc v3 dwarf-2 and
KFAILed with gcc v2 dwarf-2, gcc v2 stabs+, and gcc v3 stabs+.
. gdb.c++/pr-574.exp: PR gdb/574
null -> FAIL
stabs+ with gcc gcc-3_3-branch, gcc HEAD
. gdb.c++/pr-1023.exp: break myClass::performBlocking
null -> PASS
null -> KFAIL
This is a new test.
This is a simple symbol lookup test. With gdb HEAD%20030215,
it KFAILed with gcc 2.95.3 -gstabs+ and PASSed with gcc 2.95.3
-gdwarf-2 and all gcc v3. gdb 5.3 showed the same behavior,
so it is not a regression. It is a serious bug though.
. gdb.c++/virtfunc.exp: print pEe->D::vg()
XFAIL -> FAIL
XFAIL -> KFAIL
Needs investigation.
Probably gdb stayed the same and the test suite improved.
. gdb.java/jmisc2.exp: setting breakpoint at jmisc.main(java.lang.String[])
null -> FAIL
gdb.java/jmisc2.exp: p *args
gdb.java/jmisc2.exp: p args
PASS -> FAIL
pr gdb/1039: regression: cannot set breakpoint on jmisc.main(java.lang.String[])
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=1039
This is a regression in gdb. The test script is unable to set a
breakpoint on the main function (this action does not ordinarily
PASS, hence the null -> FAIL transition). The other FAILs
cascade from there.
This happened with all gcc v3 (gcc v2 did not include gjc).
This occurred some time between 2003-02-01 and 2003-02-05.
. gdb.mi/gdb701.exp: create fooPtr
null -> FAIL
dwarf-2 with gcc 2.95.3, 3.2-7-rh, 3.2.1, 3.2.2-20030203, gcc-3_2-branch
New test.
PR gdb/701 was lost from gnats.
The PR has been recovered now -- so needs more investigation.
Unable to tell if the bug was in 5.3 and in what configurations.
. gdb.mi/gdb792.exp: list children of class C
null -> FAIL
stabs+ with gcc gcc-3_3-branch, gcc HEAD
. gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
pr gdb/568: GDB confused by messily-exiting multi-threaded programs
http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=568
This test has bad results randomly in both 5.3 and HEAD%20030215.
Jim B thinks that this test may depend on a race condition:
http://sources.redhat.com/ml/gdb-testers/2002-q4/msg00010.html
. gdb.threads/schedlock.exp: *
This test was broken in 5.3. It's improved in HEAD%20030205 but
it still is not useful to analyze.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-02-18 14:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-17 16:44 gdb 5.3 versus gdb HEAD%200302015 Michael Elizabeth Chastain
2003-02-17 16:50 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2003-02-17 17:08 Michael Elizabeth Chastain
2003-02-17 17:13 ` David Carlton
2003-02-17 17:02 Michael Elizabeth Chastain
2003-02-17 16:32 Michael Elizabeth Chastain
2003-02-17 16:35 ` Daniel Jacobowitz
2003-02-17 15:32 Michael Elizabeth Chastain
2003-02-17 15:39 ` Daniel Jacobowitz
2003-02-17 17:03 ` David Carlton
2003-02-18 14:59 ` Michal Ludvig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).