This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PR 8507 - Remote watchpoint limit really large
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: pedro at codesourcery dot com
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 29 Dec 2008 13:22:56 +0100 (CET)
- Subject: Re: PR 8507 - Remote watchpoint limit really large
- References: <200812290525.11823.pedro@codesourcery.com>
> From: Pedro Alves <pedro@codesourcery.com>
> 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