From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27263 invoked by alias); 27 Nov 2012 15:54:59 -0000 Received: (qmail 27239 invoked by uid 22791); 27 Nov 2012 15:54:57 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 15:54:52 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 27 Nov 2012 07:54:51 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by AZSMGA002.ch.intel.com with ESMTP; 27 Nov 2012 07:54:49 -0800 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Nov 2012 15:54:48 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX151.ger.corp.intel.com ([169.254.4.21]) with mapi id 14.01.0355.002; Tue, 27 Nov 2012 15:54:47 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: Jan Kratochvil , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: RE: [patch v4 13/13] btrace, x86: restrict to Atom Date: Tue, 27 Nov 2012 15:54:00 -0000 Message-ID: References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <1354013351-14791-14-git-send-email-markus.t.metzger@intel.com> <20121127130500.GA22431@host2.jankratochvil.net> <20121127142904.GA30650@host2.jankratochvil.net> <50B4E122.80906@redhat.com> In-Reply-To: <50B4E122.80906@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: 2012-11/txt/msg00748.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Tuesday, November 27, 2012 4:50 PM > To: Metzger, Markus T > Cc: Jan Kratochvil; gdb-patches@sourceware.org; markus.t.metzger@gmail.co= m; tromey@redhat.com; kettenis@gnu.org > Subject: Re: [patch v4 13/13] btrace, x86: restrict to Atom >=20 > On 11/27/2012 03:13 PM, Metzger, Markus T wrote: > >> -----Original Message----- > >> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > >> Sent: Tuesday, November 27, 2012 3:29 PM > >> To: Metzger, Markus T > >> Cc: gdb-patches@sourceware.org; markus.t.metzger@gmail.com; palves@red= hat.com; tromey@redhat.com; kettenis@gnu.org > >> Subject: Re: [patch v4 13/13] btrace, x86: restrict to Atom > >> > >> On Tue, 27 Nov 2012 15:03:48 +0100, Metzger, Markus T wrote: > >>>> There is i386-nat.c for the common functions between these two files. > >>> > >>> Is it OK put Linux specific code into i386-nat.c? > >> > >> True it is not so clear, it would be OK as long as the linux_supports_= btrace() > >> call is moved out of it, as otherwise it just checks the CPU hardware = feature. > >> > >> But as you use it also in gdbserver I see now it can be moved to > >> common/linux-btrace.[ch] with appropriate #ifdef __i386__ and __x86_64= __. > >> common/ currently does not have any per-file arch/target configury lik= e gdb/ > >> and gdbserver/ have, one day it will probably have it but not now. > > > > I can do this. It should also simplify some of the code if I can do the= check there. > > > > Can I expect that others will be OK with this, as well? >=20 > Well, I don't agree with _that_ reasoning. We don't have _any_ configury= in common/, > because common/ is not a library. The configury is in gdb/ and gdb/gdbse= rver/. I don't > see any issue preventing splitting architecture specific code to separate= files, as we do > in gdb/ and gdbserver/. It's just that the source file is named common/f= oo.c rather than > foo.c. That said, btrace is inherently x86-specific, right? Is there any= other > architecture that does something of the sort? If not, then I agree with > assuming x86 in the file, and #ifdef where necessary to distinguish 32-bi= t/64-bit. Btrace is x86 specific. I don't know whether other architectures have simil= ar features. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Peter Gleissner, Christian Lamprechter, Hannes Schwadere= r, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052