From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11134 invoked by alias); 29 Dec 2008 12:26:09 -0000 Received: (qmail 11123 invoked by uid 22791); 29 Dec 2008 12:26:08 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Dec 2008 12:25:33 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id mBTCMvpl018149; Mon, 29 Dec 2008 13:22:57 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id mBTCMuZt004718; Mon, 29 Dec 2008 13:22:56 +0100 (CET) Date: Mon, 29 Dec 2008 12:26:00 -0000 Message-Id: <200812291222.mBTCMuZt004718@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: <200812290525.11823.pedro@codesourcery.com> (message from Pedro Alves on Mon, 29 Dec 2008 05:25:11 +0000) Subject: Re: PR 8507 - Remote watchpoint limit really large References: <200812290525.11823.pedro@codesourcery.com> 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: 2008-12/txt/msg00443.txt.bz2 > From: Pedro Alves > Date: Mon, 29 Dec 2008 05:25:11 +0000 > > PR 8507 is about this command: > > (gdb) help show remote hardware-watchpoint-limit > Show the maximum number of target hardware watchpoints. > Specify a negative limit for unlimited. > > And the fact that a negative value (default is -1), shows > through as a large positive value, which is somewhat confusing: > > (gdb) show remote hardware-watchpoint-limit > The maximum number of target hardware watchpoints is 4294967295. > > Notice that the "show" help explicitly mentioned "Specify a negative > limit for unlimited.". > > This patch fixes it to show: > > (gdb) set remote hardware-watchpoint-limit -1 > (gdb) show remote hardware-watchpoint-limit > The maximum number of target hardware watchpoints is unlimited. > > There's no current enum var_types for this integer usage, where > 0 really means zero, and negatives mean unlimited, so I've added one. Hmm, I'm not sure I like the name. How about var_zuinteger, for zeroable unsigned Integer? Interesting enough, the existing usage of var_zinteger in alpha-tdep.c and mips-tdep.c looks like it should really be var_zuinteger too. I bet there are more cases. I'm also not sure your implementation will actually work. Especially the statement: > + *(int *) c->var = UINT_MAX; looks very suspicious to me. I suspect you are having problems converting the variables set by this command from 'int' to 'unsigned int'. I actually think it would make sense to treat var_uinteger and var_zuinteger variables as 'int' ans set them to INT_MAX to mean unlimited. I don't think the loss of range is a big loss. For all practical purposes INT_MAX is just as much infinty as UINT_MAX. This would probably fix a few bugs as well, since eventually you're going to compare these to signed integers anyway, and having your "unsigned" integers in the range [0, INT_MAX] prevents a lot of accidents from happening there. (Do you fully understand the C rules for integer type promotion?). Mark