Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: gdb-patches <gdb-patches@sourceware.org>
Cc: Luis Machado <lgustavo@codesourcery.com>, <bug-hurd@gnu.org>,
	Yue Lu	<hacklu.newborn@gmail.com>
Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd
Date: Tue, 03 Sep 2013 09:38:00 -0000	[thread overview]
Message-ID: <87txi2i6t6.fsf@kepler.schwinge.homeip.net> (raw)
In-Reply-To: <CAB8fV=jJ64i91VW52ZmdnEDZhd1ZGTAykDqoFyPJanCP=5beqA@mail.gmail.com>

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

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

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

  reply	other threads:[~2013-09-03  9:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAB8fV=jJ64i91VW52ZmdnEDZhd1ZGTAykDqoFyPJanCP=5beqA@mail.gmail.com>
2013-09-03  8:03 ` [PATCH 2/2] " Yue Lu
2013-09-03  9:38   ` Thomas Schwinge [this message]
2013-09-03 11:11     ` [PATCH 1/2] " Pedro Alves
2013-09-03 13:09       ` Thomas Schwinge
2013-09-04  1:47         ` Yue Lu
2013-09-04  1:38       ` Yue Lu
2013-09-05 10:54       ` Yue Lu
2013-09-05 19:29         ` Pedro Alves
2013-09-05 19:39           ` Joel Brobecker
2013-09-05 21:38           ` Thomas Schwinge
2013-09-08 13:35             ` Yue Lu
2013-09-09  9:58               ` Thomas Schwinge
2013-09-18 12:12                 ` Pedro Alves
2013-09-18 13:48                   ` Yue Lu
2013-09-18 14:52                     ` [Hurd/gnu-nat.c] Use ptid_t.lwpid to store, thread ids instead of ptid_t.tid. (was: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd) Pedro Alves
2013-09-18 14:57                     ` [PATCH 1/2] Port gdbserver to GNU/Hurd Pedro Alves
2013-09-22 12:58             ` Yue Lu
2013-09-06 18:53           ` Pedro Alves
2013-09-12  3:05             ` Yue Lu
2013-09-18 12:30               ` Pedro Alves
2013-09-18 12:37               ` Pedro Alves
2013-09-19  7:41                 ` Yue Lu
2013-09-19  8:30                   ` FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited) (was: [PATCH 1/2] Port gdbserver to GNU/Hurd) Thomas Schwinge
2013-09-19  8:44                     ` FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited) Pedro Alves
2013-09-09 10:21           ` [PATCH 1/2] Port gdbserver to GNU/Hurd Yue Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txi2i6t6.fsf@kepler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=bug-hurd@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=hacklu.newborn@gmail.com \
    --cc=lgustavo@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox