From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17627 invoked by alias); 3 Dec 2012 16:24:16 -0000 Received: (qmail 17615 invoked by uid 22791); 3 Dec 2012 16:24:14 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 16:24:09 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2012 08:24:08 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2012 08:24:07 -0800 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Dec 2012 16:23:06 +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; Mon, 3 Dec 2012 16:23:06 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "jan.kratochvil@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" Subject: RE: [patch v4 06/13] linux, i386, amd64: enable btrace for 32bit and 64bit linux native Date: Mon, 03 Dec 2012 16:24:00 -0000 Message-ID: References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <1354013351-14791-7-git-send-email-markus.t.metzger@intel.com> <50B65A72.40301@redhat.com> In-Reply-To: <50B65A72.40301@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-12/txt/msg00031.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Wednesday, November 28, 2012 7:40 PM Thanks for your review. [...] > > + tinfo->ptr_bits =3D gdbarch_ptr_bit (gdbarch); >=20 > It seems like this is something that should always be able > to compute on demand, without needing to store it once > per thread. This seems to have the same issue I pointed out > in a previous patch, with assuming TINFO is the same thread > as the current thread/inferior, and therefore that > target_gdbarch is appropriate for TINFO. I moved the initialization of ptr_bits to the respective btrace_enable func= tion, which is more natural, and which also allows me to use target_thread_= architecture instead of target_gdbarch. I use this field in gdb/common/linux-btrace.c, which is shared by gdb and g= dbserver. I have not found a way to compute this value where I need it othe= r than via conditional compilation. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052