From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22887 invoked by alias); 7 Jan 2011 16:37:17 -0000 Received: (qmail 22712 invoked by uid 22791); 7 Jan 2011 16:37:13 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Jan 2011 16:37:08 +0000 Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p07Gb6c6015023 for ; Fri, 7 Jan 2011 08:37:06 -0800 Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by kpbe18.cbf.corp.google.com with ESMTP id p07GXm4K005301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 08:37:04 -0800 Received: by qyk27 with SMTP id 27so20550142qyk.15 for ; Fri, 07 Jan 2011 08:37:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.63.195 with SMTP id c3mr23917327qai.364.1294418224247; Fri, 07 Jan 2011 08:37:04 -0800 (PST) Received: by 10.220.118.80 with HTTP; Fri, 7 Jan 2011 08:37:04 -0800 (PST) In-Reply-To: <4D272FF6.3070402@codesourcery.com> References: <4D272FF6.3070402@codesourcery.com> Date: Fri, 07 Jan 2011 16:37:00 -0000 Message-ID: Subject: Re: duplicated code in gdb and gdbserver From: Doug Evans To: Yao Qi Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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-01/txt/msg00155.txt.bz2 On Fri, Jan 7, 2011 at 7:23 AM, Yao Qi wrote: > I noticed that sharing code of GDB and GDBServer is discussed in 2010 > GCC Summit. > http://sourceware.org/gdb/wiki/2010_GCC_Summit_BoF > > Looks like one conclusion is that "it is likely to be quite complex". =A0I > don't understand this point fully, so I had a try by myself to create a > new file linux-common.h in gdb/common/, move some duplicated macro > definitions from gdb/linux-nat.c and gdb/gdbserver/linux-low.c to > common/linux-common.h, and adjust *.h files include order. =A0Then, both > GDB and GDBServer can be build on x86. =A0Totally, it costs me nearly half > an hour to complete this experiment. > > Could anyone tell me which part of this work is "quite complex"? =A0Am I > missing something? > Regardless of this potential complexity I haven't met, it is worthwhile > moving obviously common/duplicated code into single file, isn't? > Comments are welcome. Complexity is in the eye of the beholder, so I'm sure there can be reasonable disagreements. There are no technical problems to solve, it's just code reorganization (albeit on a non-trivial scale). But for discussion's sake you need to dig deeper (IMO). An easy example is tracepoints. Why does tracepoint support only exist on gdbserver? There's no technical reason for that. The end result (of more code sharing) should include tracepoint support being available to both native gdb and gdbserver. Another is the management of threads, gdb and gdbserver handle them a little differently. Another example is individual target support. E.g., merging common bits of gdb's ${target}-nat.c files with gdbserver's ${target}-low.c files. A minor example is regcache.c. And so on. But for what it's worth, it's REAL NICE that the gdb community is at least not balking at the idea! What I'd like to see (repeated here for the list's sake, with apologies to the irc crowd :-)), is a publicly usable library (or collection of libraries) used by gdb and gdbserver. [I'd like to see more of the gnu tools made available as libraries, btw.]