Re: Remote watchpoint support.

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> The second is the return value of 0 if the target stopped for another
>> reason.  I (now) know that this is the current behavior of the target_
>> stopped_data_address() macro, but it use the one address that I think
>> might be very important to watch on targets where the zero page isn't
>> unmapped (in which case a reference would cause a exception/trap).

Eli> I would actually be very happy if we could change the interface of
Eli> target_stopped_data_address so that zero would not be treated
Eli> specially.  One problem with the current design is that I cannot catch
Eli> NULL pointer dereferences on Windows, where the null page cannot be
Eli> unmapped from the address space of DJGPP programs.  This prevents me
Eli> from finding such bugs by setting a watchpoint at address 0.

Did I just hear an echo?  :-)  I'm glad you agree that this is a bug.

>> While it might not be possible to fix in GDB's internals for some
>> time

Eli> What would it take to change that?  Perhaps it would be a good
Eli> idea to have the list of the obstacles, in case someone might try
Eli> to negotiate them one by one.

I was being pessimistic, perhaps overly so, in my assessment of fixing
GDB to emphasize my point that we shouldn't constrain the remote debug
protocol around internal implementation details.  Given a bit of hard
work, many limitations within GDB can be easily fixed; but the remote
protocol has a permanence that makes it worth our while to get it right
the first time.  Otherwise we'll forever be saddled with supporting 
old stubs with the flawed implementation.

In this case, I don't think it would be that difficult to fix.  For a 
first cut, I'd change the macro to:

        target_stopped_data_address(&addr)

It would return 0 if GDB didn't stop because of a watchpoint, and 1
(and set addr) if it did.

I don't know if there are any other lurking problems for watching
address 0.  I'm sure they'd show up pretty soon.

        --jtc

-- 
J.T. Conklin
RedBack Networks