From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13658 invoked by alias); 4 Sep 2013 01:38:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13645 invoked by uid 89); 4 Sep 2013 01:38:53 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 04 Sep 2013 01:38:53 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-la0-f45.google.com Received: by mail-la0-f45.google.com with SMTP id eh20so5412635lab.32 for ; Tue, 03 Sep 2013 18:38:49 -0700 (PDT) X-Received: by 10.152.19.1 with SMTP id a1mr196558lae.8.1378258729056; Tue, 03 Sep 2013 18:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.130.194 with HTTP; Tue, 3 Sep 2013 18:38:34 -0700 (PDT) In-Reply-To: <5225C3C6.8090101@redhat.com> References: <87txi2i6t6.fsf@kepler.schwinge.homeip.net> <5225C3C6.8090101@redhat.com> From: Yue Lu Date: Wed, 04 Sep 2013 01:38:00 -0000 Message-ID: Subject: Re: [PATCH 1/2] Port gdbserver to GNU/Hurd To: Pedro Alves Cc: Thomas Schwinge , gdb-patches , Luis Machado , bug-hurd@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00119.txt.bz2 Thanks for your review! On Tue, Sep 3, 2013 at 7:11 PM, Pedro Alves 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 GDBserve= r'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 file= s. > 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, a= nd > 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 > --=20 Yue Lu (=E9=99=86=E5=B2=B3)