This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Code in can_use_hardware_watchpoint()
- To: jimb@cygnus.com
- Subject: Re: Code in can_use_hardware_watchpoint()
- From: "Jeffrey A. Law" <law@cygnus.com>
- Date: Mon, 16 Aug 1999 00:40:22 -0700
- Cc: gdb@sourceware.cygnus.com
- Newsgroups: cygnus.gdb
- Organization: Cygnus Support, Mountain View, CA
- References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
In article <np672gury4.fsf@zwingli.cygnus.com> you write:
>I'm not really familiar with this code, but:
>
>> One solution is to add an:
>>
>> else if (v->lval == lval_register)
>> return 0;
>
>I think this is the right thing.
>
>The value chain is supposed to be a list of all the values generated
>while evaluating the watchpoint's expression. (What if someone else
>generates a value in the mean time? Don't you think it's a bad idea
>to draft a list intended for storage management into use in expression
>analysis? Bleah.) If you find anything on there that could change,
>but can't be watched, you should return zero.
I agree with Jim (and I am somewhat familiar with the code, though most
of the details have become fuzzy over the years).
Basically we have to build a list of all the expressions/values which
are required to evaluate a watchpoint. If anything on that list of
values can not be watched with a hardware watchpoint, then we do not
allow hardware watchpoints to be used.
>But the fix seems so obvious there must be something else going on...
I don't think so. I think it's just a case we didn't properly think
through.
If the only value on the chain was a reg, then we'd be OK because we would
not have found a memory location. But if we try to watch p->q and P is in
a reg, then we'd lose.
At one time that code may have done an "else return 0;", but that may have
been kicking out too many things which it should have accepted.
jeff