From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20393 invoked by alias); 22 Jan 2009 22:33:35 -0000 Received: (qmail 20384 invoked by uid 22791); 22 Jan 2009 22:33:33 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_93,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Jan 2009 22:33:28 +0000 Received: (qmail 23878 invoked from network); 22 Jan 2009 22:33:26 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Jan 2009 22:33:26 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Submit process record and replay third time, 3/9 Date: Thu, 22 Jan 2009 22:33:00 -0000 User-Agent: KMail/1.9.10 Cc: teawater References: <200901221324.02225.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901222234.25828.pedro@codesourcery.com> 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: 2009-01/txt/msg00457.txt.bz2 On Thursday 22 January 2009 15:23:48, teawater wrote: > > 2.1) Related to coupling as well. =A0You've added record.c to the list = of files that are > > built on all hosts, but I don't think that record.c is currently builda= ble on all > > hosts. =A0E.g., you're using sigaction unconditionally. =A0I didn't spo= t any call to > > a function defined in a *-nat.c file in this patch, but if you have any= , you'll need > > to either remove/rewrite it (ideal, I expect), or build record.c on nat= ive > > linux hosts only. >=20 > OK. I will put it close to linux-record.c. =A0Wish it can be back in the = future. I think you're confused. You've added linux-record.c in configure.tgt. Th= ose files will also be built in a cross configuration --- say, if you build a Windows= hosted, linux targeted gdb. Files that are only to be built when you're building a= native debugger are added to NATDEPFILES in the various .mt files under src/gdb/co= nfig/. Now, if you added record.o to the relevant linux NATDEPFILES, you'd still b= e breaking all other hosts, because you have references to functions and variables def= ined in record.c throughout gdb's core. Since other hosts wouldn't include the rec= ord.o object, they'd fail to link. Here's what I propose you try as first step: remove all references to recor= d.o from Makefile.in and configure.tgt. Try building. You'll get link errors.= Now, come up with interfaces between the core and record.c that would preserve a= ll functionality if record.o isn't included in the link; but that will still l= ink a gdb executable, if record.o isn't linked in. --=20 Pedro Alves