From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18555 invoked by alias); 27 Nov 2012 15:14:21 -0000 Received: (qmail 18431 invoked by uid 22791); 27 Nov 2012 15:14:20 -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 mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 15:14:10 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 27 Nov 2012 07:14:09 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by azsmga001.ch.intel.com with ESMTP; 27 Nov 2012 07:14:08 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX101.ger.corp.intel.com ([169.254.1.13]) with mapi id 14.01.0355.002; Tue, 27 Nov 2012 15:13:55 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "palves@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: RE: [patch v4 13/13] btrace, x86: restrict to Atom Date: Tue, 27 Nov 2012 15:14: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> In-Reply-To: <20121127142904.GA30650@host2.jankratochvil.net> 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/msg00742.txt.bz2 > -----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@redhat= .com; tromey@redhat.com; kettenis@gnu.org > Subject: Re: [patch v4 13/13] btrace, x86: restrict to Atom >=20 > 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? >=20 > True it is not so clear, it would be OK as long as the linux_supports_btr= ace() > call is moved out of it, as otherwise it just checks the CPU hardware fea= ture. >=20 > 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 like g= db/ > 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 che= ck there. Can I expect that others will be OK with this, as well? > > I took the __asm__ __volatile__ code from gdb/go32-nat.c. There's simil= ar > > inline assembly code in gdb/gdbserver/linux-tic6x-low.c for checking th= e cpu > > id on that architecture. >=20 > > > > The go32 code is also checking for features. I'm not sure whether this = can > > be done by parsing /proc/cpuinfo. >=20 > /proc/cpuinfo does contain this information: > cpu family : 6 > model : 42 >=20 > I preferred /proc/cpuinfo, for example in virtualization environments with > buggy emulations I find easier to fake /proc/cpuinfo than the cpuid > instruction data. >=20 > I find gdb/go32-nat.c and gdb/gdbserver/linux-tic6x-low.c not so relevant= key > as it has marginal market share compared to x86*. >=20 > But I am OK with the cpuid instruction when it is already in GDB. >=20 >=20 > > I think Marks point is that he does not want any such check in gdb but > > rather have the kernel handle it. He's right that the kernel should han= dle > > it. I just think that gdb needs to handle it, as well. >=20 > Not speaking for Mark but I also would like such check in Linux kernel > otherwise Linux kernel provides via SYS_perf_event_open invalid data. Agreed. > With Linux kernel trunk having such fix we can talk how to workaround old= er > kernels, I agree with you a workaround for older kernels should be there = as > you have implemented. But such workaround could be limited somehow, for > example either checking /proc/version whether we run on a buggy kernel or= for > example enabling the feature on any CPU model >=3D 90 as according to Int= el > numbering all those CPUs should have the feature either missing or correct > (but never buggy). >=20 > Maintaining the list of CPUs twice in both GDB and Linux kernel does not = seem > great to me. To me neither. Checking the kernel version sounds good. We would only need to do the cpuid= check for older kernels. I could add this once the kernel patch has been a= ccepted and merged. Is there already some code in gdb that parses the outpu= t of /proc/version? 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