[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) |
Hi!
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
<http://news.gmane.org/find-root.php?message_id=%3CCAB8fV%3Djzv_rPHP3-HQVBA-pCNZNat6PNbh%2BOJEU7tZgQdKX3%2Bw%40mail.gmail.com%3E>.
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
<http://news.gmane.org/find-root.php?message_id=%3C87ppwqlgot.fsf%40kepler.schwinge.homeip.net%3E>
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.)
Grüße,
Thomas
pgpfPN5KOFL5m.pgp
Description: PGP signature
- [PATCH 2/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd,
Thomas Schwinge <=
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/03
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Pedro Alves, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Joel Brobecker, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Thomas Schwinge, 2013/09/05
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Yue Lu, 2013/09/08
- Re: [PATCH 1/2] Port gdbserver to GNU/Hurd, Thomas Schwinge, 2013/09/09