From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18811 invoked by alias); 25 Mar 2013 16:14:02 -0000 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 Received: (qmail 18677 invoked by uid 89); 25 Mar 2013 16:13:55 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 16:13:55 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 25 Mar 2013 09:13:52 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 25 Mar 2013 09:13:25 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.244]) by IRSMSX104.ger.corp.intel.com ([169.254.5.19]) with mapi id 14.01.0355.002; Mon, 25 Mar 2013 16:13:11 +0000 From: "Metzger, Markus T" To: Pedro Alves , GDB Patches Subject: RE: "set record instruction-history" ? Date: Mon, 25 Mar 2013 17:25:00 -0000 Message-ID: References: <51507403.6030208@redhat.com> In-Reply-To: <51507403.6030208@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-03/txt/msg00939.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Monday, March 25, 2013 4:58 PM > To: GDB Patches; Metzger, Markus T > Subject: "set record instruction-history" ? >=20 > Hi Markus, >=20 > I'm going through all "uinteger" commands in the tree, and > finding several cases of commands that actually shouldn't > be "uinteger", but "zuinteger". >=20 > "record instruction-history"'s implementation looks odd enough that > I don't understand what's going on. The docs don't mention anything > about 0 being special or meaning "unlimited", but I take it that's > the intent? >=20 > What's the intent of: >=20 > /* The "record instruction-history" command. */ >=20 > static void > cmd_record_insn_history (char *arg, int from_tty) > { > int flags, size; >=20 > require_record_target (); >=20 > flags =3D get_insn_history_modifiers (&arg); >=20 > /* We use a signed size to also indicate the direction. Make sure th= at > unlimited remains unlimited. */ > size =3D (int) record_insn_history_size; > if (size < 0) > size =3D INT_MAX; >=20 > these last three lines here, though? This odd code makes sure that very large values don't wrap around to very s= mall values when we convert from unsigned int to signed it. This would change t= he meaning of those values. I do not expect the trace to be near as big as INT_MAX so INT_MAX and anyth= ing bigger than INT_MAX essentially means unlimited. > One can't set this option to negative values: >=20 > (gdb) set record instruction-history-size -2 > integer -2 out of range >=20 > The fact that it maps all negatives to INT_MAX is odd, > and needing to set the option to high-enough unsigned 32-bit > integers that trigger that bit of code looks quite > non-user-friendly, even if it didn't always map to INT_MAX: >=20 > (gdb) set record instruction-history-size 0xffffff00 > (gdb) show record instruction-history-size > Number of instructions to print in "record instruction-history" is 4294= 967040. >=20 > (and exposes 32-bitness to the user, that I'd rather not) Given that the trace can't get bigger than INT_MAX, the user would still get what he asked for - all the trace. I don't really expect such hi= gh numbers. I'd rather expect users to set it to unlimited if they get above 100 or so. How should I correct it? 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