From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5474 invoked by alias); 18 Jun 2014 18:01:51 -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 5431 invoked by uid 89); 18 Jun 2014 18:01:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Jun 2014 18:01:49 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5II1lLN003039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Jun 2014 14:01:47 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5II1jF4026563; Wed, 18 Jun 2014 14:01:46 -0400 Message-ID: <53A1D408.5020001@redhat.com> Date: Wed, 18 Jun 2014 18:01:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mark Kettenis , palves@redhat.com CC: gbenson@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH 0/4 v2] Refactor shared code in i386-{nat,low}.[ch] References: <1403104976-2492-1-git-send-email-gbenson@redhat.com> <201406181606.s5IG6Mud000672@glazunov.sibelius.xs4all.nl> <53A1B9E8.5010504@redhat.com> <201406181748.s5IHmM3H005254@glazunov.sibelius.xs4all.nl> In-Reply-To: <201406181748.s5IHmM3H005254@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00685.txt.bz2 On 06/18/2014 06:48 PM, Mark Kettenis wrote: >> Date: Wed, 18 Jun 2014 17:10:16 +0100 >> From: Pedro Alves >> >> On 06/18/2014 05:06 PM, Mark Kettenis wrote: >> >>> What is the whole point about this excercise? >> >> Reduce duplication and thus reduce maintenance burden. The same code is >> implemented twice, both in GDB and in GDBserver. >> We've had to patch both sides of the fence several times in the >> past years. If we had already had this, it would have saved effort. >> Can't rewrite history now, but we can avoid similar duplicate effort >> in the future. This specific bit is mentioned explicitly in: >> >> https://sourceware.org/gdb/wiki/Common#Arch-specific_bits_of_the_target_backends > > But common code lives in common/, and this diff moves things into > nat/. How does that unduplicate things? Well, nat/ is a shared subdirectory, just like common/. Both GDB and GDBserver compile things from nat/, just like from common/. Roughly: gdb/i386-nat.c + gdb/gdbserver/i386-low.c -> gdb/nat/i386-dregs.c The little that remains in gdb/i386-nat.c and gdb/gdbserver/i386-low.c is bits that glue GDB and GDBserver target_ops vectors to the shared i386-dregs.c. (The "common" moniker was a not-to-great idea that we're moving away from. "common" suggests that what we put there is necessarily "common" between more than one thing, instead of suggesting what the code is supposed to do. If some change in GDB or GDBserver makes it so that some code in common/ is no longer used in one of GDB or GDBserver's, then what to do? Thus, "nat/" -- it holds native target specific code. From GDBserver's perspective, it's target backends are native targets. This was all previously discussed before, months ago, but we haven't updated the wiki yet. We should.) -- Pedro Alves