From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24070 invoked by alias); 14 Apr 2011 08:05:37 -0000 Received: (qmail 24043 invoked by uid 22791); 14 Apr 2011 08:05:33 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_DB,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Apr 2011 08:05:28 +0000 Received: (qmail 12981 invoked from network); 14 Apr 2011 08:05:27 -0000 Received: from unknown (HELO ?192.168.0.102?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Apr 2011 08:05:27 -0000 Message-ID: <4DA6AAC1.7000802@codesourcery.com> Date: Thu, 14 Apr 2011 08:05:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Joel Brobecker CC: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [try 2nd, patch] Move common macros to i386-dbg-reg.h References: <4D57AB12.1050708@codesourcery.com> <4D79AD80.5050803@codesourcery.com> <4D9167CD.4070205@codesourcery.com> <4D9DC513.6040403@codesourcery.com> <201104071553.p37FrP3T016810@glazunov.sibelius.xs4all.nl> <4DA260EF.1000105@codesourcery.com> <20110413170500.GA11452@adacore.com> In-Reply-To: <20110413170500.GA11452@adacore.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg00202.txt.bz2 On 04/14/2011 01:05 AM, Joel Brobecker wrote: >> "a fully featured native GDB replacement or a lightweight remote >> protocol stub" is *not* related to this patch at all. I am unable to do >> such choice. This patch (and other patches of mine in this area) is to >> reduce source code duplication as much as possible. No matter what >> model we choose for gdbserver, this patch still makes sense, IMO. > > It does, but before we do so, I think it's important to know how > we are going to reduce this duplication. I haven't looked at the patch, In general, the "how" is reading the source code, and identifying the duplication between gdb and gdbserver. Once duplication is found, try to move them to common/ dir. Removing duplication in *-nat.c and *-low.c is a low-hang-fruit at that moment, and much duplications are from this. There are also some duplications in proc_service, and we can fix them without much effort. Of course, regcache and event-loop may have some duplications, but my first impression is that it is not easy to reduce duplications there. That is the same case to tracepoint.c as well. I am not familiar with them, so have no idea. > so I can't comment on it, but I think we just need a plan of what and > how we're going to avoid that. > I guess your last "that" means "duplication". I was keeping my eyes on how to _reduce_ duplication, instead of how to avoid. Think of it shortly, something comes up in my mind, 1. When adding a new port, common code, such as macros, register name, and accessing method can be moved to common/, and gdb/gdbserver code use it respectively. 2. When adding a new functionality/feature, evaluate whether this new feature can be done in both gdb and gdbserver. If yes, move common part to common/ dir, otherwise, implement this new feature in either gdb or gdbserver. These two rules apply to most of development works, and should be helpful on avoiding duplications to some extent. Finally, I don't think duplication can be avoided completely, so we need change/refactor code periodically or continuously, even sometimes changes are painful. :) -- Yao (齐尧)