Hi! On Wed, 1 May 2013 20:25:56 +0800, 陆岳 <hacklu.newb...@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
pgpbHQvzE58KM.pgp
Description: PGP signature
