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

[Yue Lu <hacklu dot newborn at gmail dot com>]

Thanks for your review!

On Tue, Sep 3, 2013 at 7:11 PM, Pedro Alves <palves@redhat.com> wrote:
>
> For new gdbserver ports, this path just seems to swim further away from
> a full sharing approach, by adding lots duplication as first step, and
> actually making it hard to see what exactly needed to be changed/adapted
> for gdbserver use, and puts the tree in a state where any further changes
> for the GNU/Hurd target will need to be considered twice going further,
> exactly what we're fighting against with the existing ports.  I think
> that strategy ultimately is slower to get at where we want to, and
> is actually more work than an alternative that does things the other
> way around.
>
> I checked out Yue's git branch, and diffed gdb/gnu-nat.c vs
> gdbserver/gnu-low.c, and gdb/i386gnu-nat.c vs gdbserver/gnu-i386-low.c.
> I didn't diff the rest of the files, as I assume they'll probably have
> even less divergence.  There are several spurious formatting differences,
> and some reordering of functions, but for the most port, the code is

The reason is, at first, I plan to write the new file, and then I
found one function can be re-use, so I copy it, it call another one,
so I copy the another one. One by one, so there are some reordering of
functions. The formatting differences comes with "indent program", I
found this from GNU_CODIND_STYLE
(http://www.gnu.org/prep/standards/standards.html ).

> mostly identical.  There's some expected necessary adjustment to GDBserver's
> interfaces, but it turns out it's not that much.  We've been converging
> gdb's and gdbserver's interfaces throughout the years, and it now shows.

I have found some interfaces which must be adjustment. Like use the
lwp as tid in structure ptid_t.

> So my idea would be, instead of adding the new files under gdbserver,
> to remove the spurious differences (formatting, reordering, etc.) that
> were introduced in the gdbserver copies of the files, eliminating the
> unnecessary divergence, and then fold back the resulting differences into
> the original gdb/gnu-nat.c etc. files, guarded by #ifdef GDBSERVER.  Some
> cleanups might have been identified and done in the gdbserver files, and
> it might make sense to do those as preparatory work, in the original files.
> This should result in smaller patches, and will actually avoid
> the need for most of the polishing Thomas mentioned, and as consequence
> review burden -- reviewing the new gnu-low.c etc., for GNU conventions,
> formatting, or even appropriate use of the Hurd's debug APIs etc., is
> just unnecessary that way, by design, and we'll be able to focus on the
> bits that are the real new code -- the glue between the target and gdb, and
> the target and gdbserver.
>
> The current state of the work isn't wasted at all!  And I don't
> think following this direction is that much work.  I'd do this my
> literally moving gdbserver/gnu-low.c on top of gdb/gnu-nat.c (etc.), and
> use git diff to guide me through, in identifying what would need to
> be restored, and guarded with #if[n]def GDBSERVER.  #ifdef GDBSERVER
> is how we've adapting shared code under gdb/common/ and gdb/nat/
> to work on both programs.  Medium/long term, core gdb and core
> gdbserver target interface differences should converge further, and
> the #ifdefs disappear, but for now that's a necessary evil.
>
> It's fine to leave bits of functionality disabled on gdbserver,
> wrapped in #ifndef GDBSERVER.  After that initial work is committed,
> we can then easily progress the gdbserver port by just looking for
> those #ifdefs.
>
> It's fine with me to leave the existing native files under gdb/ while
> doing this; it's probably easier that way.  Moving them under gdb/nat/
> can be left for a cleanup step further down the road.
>
> Could we try that approach?

Ok, I will try to move the gdbserver/gnu-low.c back into gdb/gnu-nat.c.

> --
> Pedro Alves
>



-- 
Yue Lu (éå)