[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

From: Thomas Schwinge
Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd
Date: Tue, 3 Sep 2013 11:38:13 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


For context, Yue Lu is a student participating in this year's Google
Summer of Code program, to port gdbserver to GNU Hurd, and is both a GDB
as well as a GNU Hurd newbie.  (So, be gentle.)  ;-)

On Tue, 3 Sep 2013 16:00:32 +0800, Yue Lu <hacklu.newborn@gmail.com> wrote:
> This is my patch to port gdbserver to GNU/Hurd. Most of code are
> copied  from [gdb]/gdb/gnu-nat.c.

... and elsewhere.  Our strategy was to first get this into a basic
functional state:

> Now the gdbserver on GNU/Hurd can set breakpoint and check memory or
> register(but without float-register support).

So, this initial port just posted is a great milestone!  Especially so
given your previous lack of experience with both GDB and the Hurd -- both
of which are not always easy to grasp.

There are lots of things to be polished (Yue, don't worry -- this
entirely was to be expected), such as GDB coding standard, and changes
that are unrelated to your port, which all has to be cleared out before I
can commit this initial port to GDB upstream.

There is missing functionality, but we decided this can be enhanced piece
by piece once the initial port is accepted.

There is the issue of code sharing between GDB proper and gdbserver, a
strategy for which has been briefly discussed in
Likewise for code sharing between the new Hurd gdbserver port and the
existing x86 Linux kernel port.  Again I suggest this to be done *after*
the initial port is accepted: this will turn into a nice (and easily
reviewable) series of cleanup patches à la: remove from GDB proper
gdb/gnu-nat.c:[function] and from gdbserver
gdb/gdbserver/gnu-low.c:[function], and add
gdb/common/gnu-low.c:[function], and so on.  Likewise for build
infrastructure that can be shared.

Does this strategy generally make sense to you GDB maintainers?

For the curious, in
I describe the MIG usage in GDB.  (This message also states that ptrace
is a system call which it is not; it's a glibc library function using RPC
calls to implement its functionality.)


Attachment: pgpfPN5KOFL5m.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]