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.newb...@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
pgp9h6kGyWOP0.pgp
Description: PGP signature