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

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

[Thomas Schwinge]

[-- Attachment #1.1: Type: text/plain, Size: 1747 bytes --]

Hi!

On Tue, 30 Apr 2013 00:54:26 +0800, 陆岳 <hacklu.newborn@gmail.com> wrote:
> I am interested in participating GsoC 2013 with GNU Hurd for improve
> the GDB Port for GNU Hurd.

Thanks for your interest!

> Write this email I mainly to identify which work should I do in this
> project. just Port gdbserver or something else?

Well, as I said in the announcement email,
<http://sourceware.org/ml/gdb/2013-04/msg00015.html>, and as reflected on
the project idea page,
<http://www.gnu.org/software/hurd/community/gsoc/project_ideas/gdb.html>,
that is basically up for negotiation with the community, the mentor, and
the student.

> Last  may I introduce myself, my name is Yue Lu who is a second-year
> MS student in CS from Tongji University in China. I have worked as a
> FTE  in a company which produce embed-device.
> What's plus, I had experience with linux kernel programming. And I
> know GDB was use ptrace  to commutate with linux kernel.
> Sadly say, I have't enough knowledge about Hurd, but I have great
> enthusiasm to learn that.

Then I suggest you turn that enthusiasm into productivity ;-) -- install
a GNU/Hurd system,
<http://www.gnu.org/software/hurd/hurd/running/debian.html>, maybe start
with a KVM/QEMU/VirtualBox image, and do a first run of the GDB testsuite
(please locally apply the attached patch to disable some testcases that
currently cause issues as described).
<http://www.gnu.org/software/hurd/open_issues/gdb.html> can help with how
to configure GDB, and so on.  In parallel, please get an understanding
how, roughly, the Hurd port of GDB works and interacts with the Hurd
system.

Of course, we're happy to help and answer specific questions.


Grüße,
 Thomas



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: disable-some.patch --]
[-- Type: text/x-diff, Size: 1548 bytes --]

diff --git gdb/testsuite/gdb.base/readline.exp gdb/testsuite/gdb.base/readline.exp
index 2acc664..538dcc6 100644
--- gdb/testsuite/gdb.base/readline.exp
+++ gdb/testsuite/gdb.base/readline.exp
@@ -17,6 +17,9 @@
 
 # This file is part of the gdb testsuite.
 
+untested "<http://www.gnu.org/software/hurd/open_issues/term_blocking.html>"
+return -1
+
 #
 # Tests for readline operations.
 #
diff --git gdb/testsuite/gdb.base/sigall.exp gdb/testsuite/gdb.base/sigall.exp
index 4bd0427..b49fe5b 100644
--- gdb/testsuite/gdb.base/sigall.exp
+++ gdb/testsuite/gdb.base/sigall.exp
@@ -13,6 +13,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+untested "takes ages: nearly all FAIL with timeout"
+return -1
+
 if [target_info exists gdb,nosignals] {
     verbose "Skipping sigall.exp because of nosignals."
     continue
diff --git gdb/testsuite/gdb.python/py-inferior.exp gdb/testsuite/gdb.python/py-inferior.exp
index ceb0da7..ba98aa8 100644
--- gdb/testsuite/gdb.python/py-inferior.exp
+++ gdb/testsuite/gdb.python/py-inferior.exp
@@ -66,6 +66,9 @@ gdb_breakpoint check_threads
 gdb_continue_to_breakpoint "cont to check_threads" ".*pthread_barrier_wait.*"
 gdb_test "python print (len (i0.threads ()))" "\r\n9" "test Inferior.threads 2"
 
+untested "the following tests get the system into an unresponsive state"
+return -1
+
 # Proceed to the next test.
 
 gdb_breakpoint [gdb_get_line_number "Break here."]

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

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

[陆岳]

Dear Thomas Schwinge:

so thanks for your reply!

I have already played something with Hurd. I run the Hurd under
kvm(thanks braunr who tell me use kvm instead of qemu). With the help
of IRC #hurd, I successfully build my GDB from source under Hurd.
Sadly say,even apply the patch in your email ,I got a lot of fails in
the gdb testcase.
there are about _605_ fails.
(something like below:)
FAIL: gdb.base/interrupt.exp: call function when asleep (wrong output)
FAIL: gdb.base/interrupt.exp: call function a second time
FAIL: gdb.base/interrupt.exp: Send Control-C, second time
FAIL: gdb.base/interrupt.exp: send end of file
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)

 In parallel, I tried to read the <The GNU Mach Reference Manual>,<The
Hurd Hacking Guide> and the GDB source code to figure out how GDB
works in Hurd and  interacts with the Hurd system.
To my knowledge, the GDB in Hurd allocate the port in the
debugged-program to receive events,and set the inf->trace on. Later
GDB go into the gun_wait() to  wait for something to happen in
debugged-program. And GDB use vm_write(),vm_read() to read and modify
debugged-program's memory.
But,I am still have some  confuses  about how the mach transport
message,how the virtual memory manage works.

I think the work of porting gdbserver is consist of three major components:
1. do the real work like operate the register,memory..(like set the
correct PC register,set breakpoint)
2. use the gdb protocol to communication with the GDB which run on
remote machine.
3. write document and do test

At final,I think I have the ability and the passion to finish the
porting of gdbserver to Hurd.
Since the Friday is the deadline to apply GSoC,  I want to know
whether there is more work I need to do for the  project "improve the
GDB Port for GNU Hurd". For instance  solving some FAIL testcases.


thanks and best regards.

On Tue, Apr 30, 2013 at 5:13 PM, Thomas Schwinge
<thomas@codesourcery.com> wrote:
> Hi!
>
> On Tue, 30 Apr 2013 00:54:26 +0800, 陆岳 <hacklu.newborn@gmail.com> wrote:
>> I am interested in participating GsoC 2013 with GNU Hurd for improve
>> the GDB Port for GNU Hurd.
>
> Thanks for your interest!
>
>> Write this email I mainly to identify which work should I do in this
>> project. just Port gdbserver or something else?
>
> Well, as I said in the announcement email,
> <http://sourceware.org/ml/gdb/2013-04/msg00015.html>, and as reflected on
> the project idea page,
> <http://www.gnu.org/software/hurd/community/gsoc/project_ideas/gdb.html>,
> that is basically up for negotiation with the community, the mentor, and
> the student.
>
>> Last  may I introduce myself, my name is Yue Lu who is a second-year
>> MS student in CS from Tongji University in China. I have worked as a
>> FTE  in a company which produce embed-device.
>> What's plus, I had experience with linux kernel programming. And I
>> know GDB was use ptrace  to commutate with linux kernel.
>> Sadly say, I have't enough knowledge about Hurd, but I have great
>> enthusiasm to learn that.
>
> Then I suggest you turn that enthusiasm into productivity ;-) -- install
> a GNU/Hurd system,
> <http://www.gnu.org/software/hurd/hurd/running/debian.html>, maybe start
> with a KVM/QEMU/VirtualBox image, and do a first run of the GDB testsuite
> (please locally apply the attached patch to disable some testcases that
> currently cause issues as described).
> <http://www.gnu.org/software/hurd/open_issues/gdb.html> can help with how
> to configure GDB, and so on.  In parallel, please get an understanding
> how, roughly, the Hurd port of GDB works and interacts with the Hurd
> system.
>
> Of course, we're happy to help and answer specific questions.
>
>
> Grüße,
>  Thomas
>
>



-- 
Yue Lu

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

[Thomas Schwinge]

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

Hi!

On Wed, 1 May 2013 20:25:56 +0800, 陆岳 <hacklu.newborn@gmail.com> wrote:
> I have already played something with Hurd. I run the Hurd under
> kvm(thanks braunr who tell me use kvm instead of qemu). With the help
> of IRC #hurd, I successfully build my GDB from source under Hurd.
> Sadly say,even apply the patch in your email ,I got a lot of fails in
> the gdb testcase.
> there are about _605_ fails.
> (something like below:)
> FAIL: gdb.base/interrupt.exp: call function when asleep (wrong output)
> FAIL: gdb.base/interrupt.exp: call function a second time
> FAIL: gdb.base/interrupt.exp: Send Control-C, second time
> FAIL: gdb.base/interrupt.exp: send end of file
> FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)

That is indeed about the number that currently is to be expected:

    $ grep ^FAIL toolchain/logs/gdb/coulomb.SCHWINGE/test/gdb/testsuite/gdb.*/*.sum | wc -l
    561

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.


>  In parallel, I tried to read the <The GNU Mach Reference Manual>,<The
> Hurd Hacking Guide> and the GDB source code to figure out how GDB
> works in Hurd and  interacts with the Hurd system.

Which are the handful of files in the GDB sources that are relevant
(only) for the native GNU Hurd support?

> To my knowledge, the GDB in Hurd allocate the port in the
> debugged-program to receive events,and set the inf->trace on. Later
> GDB go into the gun_wait() to  wait for something to happen in
> debugged-program. And GDB use vm_write(),vm_read() to read and modify
> debugged-program's memory.
> But,I am still have some  confuses  about how the mach transport
> message,how the virtual memory manage works.

Yes, this shows you actually did look at the sources, trying to figure
out how it works, and what you describe is correct in principle.
(Leaving out many details, of course.)  As you're still new to the Hurd's
architecture, based on Mach's RPC system, it is no wonder that the
message transport is still not completely clear to you -- that will get
better with time, as you learn more about it.


> I think the work of porting gdbserver is consist of three major components:
> 1. do the real work like operate the register,memory..(like set the
> correct PC register,set breakpoint)
> 2. use the gdb protocol to communication with the GDB which run on
> remote machine.
> 3. write document and do test

Right.  Step 1. could borrow a lot of code from the implementation of the
native GDB implementation for GNU Hurd (preferable in a way that does not
duplicate the code it, but instead shares it between the two: GDB native
port and gdbserver) as well as borrow a lot of code from the existing and
well-established Linux kernel ports of gdbserver (again, sharing the code
wherever possible).  Step 2. should already be completely covered by the
existing gdbserver implementations targeting the Linux kernel, which we
ought to reuse as much as possible.  Please next get an understanding
about the general architecture (of the source files) of gdbserver, and
what you'd need to add/change to support the GNU Hurd operating system.


> At final,I think I have the ability and the passion to finish the
> porting of gdbserver to Hurd.
> Since the Friday is the deadline to apply GSoC,  I want to know
> whether there is more work I need to do for the  project "improve the
> GDB Port for GNU Hurd". For instance  solving some FAIL testcases.

No, please use the knowledge you got by now to write your application,
and send it in, which needs to happen tomorrow.  Then, in the next
week(s), we can still continue refining it, and you could, for example,
prepare and send a first patch for GDB for the issue that you reported on
IRC: so that the configure process stops with an error if targeting GNU
Hurd and the MIG tool was not found.  (gdb/configure.ac is the file you
need to edit, and then regenerate gdb/configure.)


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

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

[陆岳]

Thank you for providing the requested information.

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.

I will do the compare after I have finished the application.

> Which are the handful of files in the GDB sources that are relevant
> (only) for the native GNU Hurd support?

To my knowledge now, there are at least gnu-nat.c, i386gnu-tdep.c,
gnu-nat.h and i386gnu-nat.c relating with GNU Hurd support.

> Yes, this shows you actually did look at the sources, trying to figure
> out how it works, and what you describe is correct in principle.
> (Leaving out many details, of course.)  As you're still new to the Hurd's
> architecture, based on Mach's RPC system, it is no wonder that the
> message transport is still not completely clear to you -- that will get
> better with time, as you learn more about it.

yeah, I will continue to learn more about GNU Hurd. By the way, Last
night I have found a useful document
in this ftp(ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/exception.doc)
which explained how the GDB take advantage of Mach's exception
facility.

> No, please use the knowledge you got by now to write your application,
> and send it in, which needs to happen tomorrow.  Then, in the next
> week(s), we can still continue refining it, and you could, for example,
> prepare and send a first patch for GDB for the issue that you reported on
> IRC: so that the configure process stops with an error if targeting GNU
> Hurd and the MIG tool was not found.  (gdb/configure.ac is the file you
> need to edit, and then regenerate gdb/configure.)

I will write my application right now. And the patch is on the way,
this afternoon I have already read some How-to about autoconf.

Best Regards.

-- 
Yue Lu (陆岳)

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

[Thomas Schwinge]

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

Hi!

In the last days, I've been and still am rather busy with other
commitments, and unfortunately have not yet been able to continue working
with you on your GSoC application as well as the GDB patch you sent.
Starting Tuesday next week, I should be able to spend more time on that.


On Thu, 2 May 2013 20:50:03 +0800, 陆岳 <hacklu.newborn@gmail.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.
> 
> I will do the compare after I have finished the application.

Yes, please have a look at that.  For example, do you get significantly
different test failures than I have, and how/why are they different?
Please be aware that the results from the GDB testsuite, especially when
run on GNU Hurd, are not completely "stable" (deterministic): as you can
see from the revisions of my test result files, some FAILs come and go
randomly, not related to any GDB code changes, or system environment
changes.  That is, for two GDB test runs you'll get some different
results.  (With time, you'll get used to quickly recognize and "ignore"
these...)  ;-|


Oh, and if you want to read more about GDB's architecture and provenance,
I can recommend Stan Shebs' chapter in »The Architecture of Open Source
Applications«, <http://www.aosabook.org/en/gdb.html>.


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

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

[Hacklu]

Hi.

在 2013-5-10，18:35，Thomas Schwinge <thomas@codesourcery.com> 写道：

> Hi!
> 
> In the last days, I've been and still am rather busy with other
> commitments, and unfortunately have not yet been able to continue working
> with you on your GSoC application as well as the GDB patch you sent.
> Starting Tuesday next week, I should be able to spend more time on that.

Ok,I will waiting for your review on that application.

> 
> On Thu, 2 May 2013 20:50:03 +0800, 陆岳 <hacklu.newborn@gmail.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.
>> 
>> I will do the compare after I have finished the application.
> 
> Yes, please have a look at that.  For example, do you get significantly
> different test failures than I have, and how/why are they different?
> Please be aware that the results from the GDB testsuite, especially when
> run on GNU Hurd, are not completely "stable" (deterministic): as you can
> see from the revisions of my test result files, some FAILs come and go
> randomly, not related to any GDB code changes, or system environment
> changes.  That is, for two GDB test runs you'll get some different
> results.  (With time, you'll get used to quickly recognize and "ignore"
> these...)  ;-|

Ah, I got it.
> 
> Oh, and if you want to read more about GDB's architecture and provenance,
> I can recommend Stan Shebs' chapter in »The Architecture of Open Source
> Applications«, <http://www.aosabook.org/en/gdb.html>.

That's just what I need. I am reading the <gdb internals> these days.
> 
> Grüße,
> Thomas


Yue Lu (陆岳)
From gdb-return-42126-listarch-gdb=sources.redhat.com@sourceware.org Mon May 13 14:46:03 2013
Return-Path: <gdb-return-42126-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 13651 invoked by alias); 13 May 2013 14:46:02 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 13574 invoked by uid 89); 13 May 2013 14:46:01 -0000
X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_TR autolearn=unavailable version=3.3.1
Received: from hop-nat-141.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 13 May 2013 14:46:01 +0000
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55])	by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DEjtkL022546	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO);	Mon, 13 May 2013 10:45:55 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 13 May 2013 10:45:49 -0400
Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188])	by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DEjl43005982;	Mon, 13 May 2013 10:45:47 -0400
Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043)	id F3E205AFE16; Mon, 13 May 2013 10:45:46 -0400 (EDT)
Received: from usendtaylorx2l (localhost [127.0.0.1])	by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id F09065AFDFA;	Mon, 13 May 2013 10:45:46 -0400 (EDT)
From: David Taylor <dtaylor@emc.com>
To: gcc@gcc.gnu.org, gdb@sourceware.org, binutils@soureware.org
Subject: stabs changes for 64 bit targets
Date: Mon, 13 May 2013 14:46:00 -0000
Message-ID: <18975.1368456346@usendtaylorx2l>
X-EMM-MHVC: 1
X-SW-Source: 2013-05/txt/msg00053.txt.bz2
Content-length: 2449

There are problems when using current STABS debug format for 64 bit
targets.

A STABS entry is 12 bytes:

    . e_strx (4 bytes)
    . e_type (1 byte)
    . e_other (1 byte)
    . e_desc (2 bytes)
    . e_value (4 bytes)

Unless you have an awfully lot of debug information, 4 bytes for a
string table index is fine.  But, for 64 bit targets, 4 bytes for an
address is not so good.

Initially we were using the x86-64 small memory model.  But we now have
a need to place some data symbols at higher addresses.  Doing so and
compiling with debugging turned on causes linkage problems -- with STABS
relocations.

So, we are now looking at 16 byte STABS entries -- increasing the size
of the e_value field from 4 bytes to 8 bytes and leaving the other 4
fields alone.

We want things to be backwards compatible and to have one tool chain
that is caplable of producing / consuming both formats.

We also want the changes to be implemented in such a way that they would
be considered for inclusion in future versions of GCC, BINUTILS, and
GDB.

To that end, our thinking is that:

. GCC would still produce STABS entries as now; but, would also support
a command line switch to tell the assembler that the larger STABS were
wanted.

. the new section would be named .stab2 instead of .stab

  [I wasn't sure what to name it; I didn't want to call it .stab64 as I
   could envision someone someday needing to increase the size of the
   string table.  I don't really care what it is called provided it is
   not .stab (backwards compatibility).]

. if both .stab and .stab2 are present in an executable, they would
  share the same string table (unless this proves to be a problem, in
  which case the .stab2 string table would be named either .stab2str or
  .stabstr2)

. GAS, based on a command line switch would produce either 12 byte or 16
  byte STABS.

. OBJDUMP / LD / GDB would look at the section name to determine how to
  read the STABS.

I am told that the GCC and BINUTILS changes are done except for the
addition of new tests to the testsuite.  The GDB changes have been
started.

Does this sound like a reasonable approach?  Is the new section name
okay?  Or do people have suggestions for a better name?  Anything left
out that needs to be done for the changes to be considered for
inclusion?

EMC has paperwork on file for copyright assignment of past and future
changes to GCC, BINUTILS, and GDB.

David
--
David Taylor
dtaylor@emc.com

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

[Yue Lu]

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 (陆岳)