Re: [GSoC2013] question about "improve the GDB port for GNU Hurd"

Hi, Thomas.

On Fri, May 10, 2013 at 6:35 PM, Thomas Schwinge
<[email protected]> wrote:
>> On Thu, May 2, 2013 at 7:51 PM, Thomas Schwinge <[email protected]> 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 (陆岳)