From: Yue Lu <hacklu.newborn@gmail.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: gdb@sourceware.org, bug-hurd@gnu.org
Subject: Re: [GSoC2013] question about "improve the GDB port for GNU Hurd"
Date: Thu, 23 May 2013 02:16:00 -0000 [thread overview]
Message-ID: <CAB8fV=gRLYkfUgw1y-buL9pH=-sBXEoqeKZuUDJxVt8-EfT8+g@mail.gmail.com> (raw)
In-Reply-To: <87a9o3nmw5.fsf@kepler.schwinge.homeip.net>
Hi, Thomas.
On Fri, May 10, 2013 at 6:35 PM, Thomas Schwinge
<thomas@codesourcery.com> wrote:
>> On Thu, May 2, 2013 at 7:51 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
>>
>> > You can clone hurd/web.git repository from Savannah, and check out the
>> > toolchain/logs/master branch (which I have as a Git submodule on
>> > toolchain/logs), and compare the
>> > gdb/coulomb.SCHWINGE/test/gdb/testsuite/gdb.*/*.sum files with those you
>> > got.
Sorry for the late response, few days ago, with one mistake operation,
I destroyed my hurd-box img file. The test result I have got before
are lost.
I have run gdb testsuit about ten times. And I found all the time I
have less fails than you have. And I picked one to do the diff with
your. (These one I have totally 511 fails as you have 561. )
(btw, I have used the newest GNU Hurd release yestoday, with gcc
4.7.3.; gdb version 7.6.50.20130522-cvs; and applied your patch in
the first email.)
$ grep ^FAIL ./gdb.*/gdb.sum > me.log
$ grep ^FAIL coulomb.SCHWINGE/test/gdb/testsuite./gdb.*/gdb.sum >thomas.log
for the better diff output, I have sorted the two log file.
$ diff me.log thomas.log
the diff result looks like this (with tiny modify):
> FAIL: gdb.ada/aliased_array.exp: print bt
> FAIL: gdb.ada/array_bounds.exp: print table'first
>...
you have 35 ada-related FAILs. but I have none. because I haven't
install gnat. when I try to apt-get install gnat. I found that will be
change my gcc from 4.7.3 to 4.6. So I cancel the install. I am not
sure about this.
> FAIL: gdb.arch/i386-float.exp: info float
> FAIL: gdb.base/default.exp: cd
> FAIL: gdb.base/long_long.exp: p/a *(int *)i
> FAIL: gdb.base/long_long.exp: p/a *(long *)l
> FAIL: gdb.base/long_long.exp: x/a
In all of my test, I never have see above fails.
< FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
callee caller dummy catcher sigtramp thrower main (GDB internal error)
< FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
caller dummy catcher sigtramp thrower main (GDB internal error)
< FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains
catcher sigtramp thrower main (GDB internal error)
---
> FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains callee caller dummy catcher sigtramp thrower main
> FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains caller dummy catcher sigtramp thrower main
> FAIL: gdb.base/savedregs.exp: Check main info frame; stack contains catcher sigtramp thrower main
The <gdb internals> says: "the gdb_test, gdb_test_multiple recognizes
internal errors and unexpected prompts." I don't know in your case why
it doesn't recognize.
> FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now, not changed
> FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: out of scope now
> FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: out of scope now, not changed
is these the one which can be "ignore" ? I remembered sometime I also
got one of these three.
> FAIL: gdb.python/py-events.exp: inferior 2
> FAIL: gdb.python/py-events.exp: Inferior 2 terminated. (the program is no longer running)
> FAIL: gdb.python/py-inferior.exp: test Inferior.threads
> FAIL: gdb.python/py-inferior.exp: test Inferior.threads 2
> FAIL: gdb.python/py-mi.exp: varobj update 1
> FAIL: gdb.python/py-mi.exp: varobj update 2
> FAIL: gdb.python/py-mi.exp: varobj update after choosing default
> FAIL: gdb.python/py-mi.exp: varobj update after choosing via expression
python-related tests just work fine on my box.
< FAIL: gdb.threads/wp-replication.exp: No hardware watchpoints available
This is the *only* fail which I have but you didn't have. And I have
the fail every time. it looks like the way I use kvm not correctly. I
run the kvm with this:
kvm -m 1500m -no-kvm-irqchip -drive file=hurd-7.0.qemu,cache=writeback
-vnc :1 -net nic,model=rtl8139 -net user,hostfwd=tcp::8888-:22 -cdrom
debian-7.0-hurd-i386-DVD-1.iso -monitor telnet::9999,server,nowait
--
Yue Lu (陆岳)
prev parent reply other threads:[~2013-05-23 2:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAB8fV=js9NvAp3Q079cNT=0=yoiLcjOWNQFyD4LhaScB=M4mSQ@mail.gmail.com>
2013-04-30 9:14 ` Thomas Schwinge
2013-05-01 12:26 ` 陆岳
2013-05-02 11:52 ` Thomas Schwinge
2013-05-02 12:50 ` 陆岳
2013-05-10 10:35 ` Thomas Schwinge
2013-05-10 14:31 ` Hacklu
2013-05-23 2:16 ` Yue Lu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB8fV=gRLYkfUgw1y-buL9pH=-sBXEoqeKZuUDJxVt8-EfT8+g@mail.gmail.com' \
--to=hacklu.newborn@gmail.com \
--cc=bug-hurd@gnu.org \
--cc=gdb@sourceware.org \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox