Thanks for your review! On Tue, Sep 3, 2013 at 7:11 PM, Pedro Alves <pal...@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 (陆岳)
