This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] remote: Fix hw watchpoint address matching


On Tue, 6 Mar 2012, Pedro Alves wrote:

> >  Back to this change, was distracted by something else.
> 
> 
> So was I.  :-)

 And more so, I would imagine -- I'll be missing you and your expertise as 
a colleague, although I am happy we can still meet and work together from 
time to time here.

> >  Yes, this is about watchpoints, not breakpoints. ;)
> 
> 
> I fully understand that.  What I was saying is that if that is a concern,
> then breakpoints with bit #31 set are quite likely to suffer from exactly
> the same issue, with the remote possibly reporting the trapped address as
> truncated to 32 bits or as a properly sign-extended 64-bit value.  And I'd
> imagine the code that handles the low level traps/exceptions to handle
> both watchpoint and breakpoint addresses the same, and the stub code that
> marshals those breakpoint addresses to rsp to be just as susceptible to
> the issue as code that marshals watchpoint addresses.  Now, I'm not
> saying we should run to fix that...
> 
> I'm still curious why isn't bkpt_breakpoint_hit broken like I described
> above, when a breakpoint is subject to adjustment, such as
> that done by mips_breakpoint_from_pc.  I probably need to stare more
> at the code.  ;-)

 My understanding of how breakpoints work is the remote stub does nothing 
specific to report to GDB that it actually has hit a breakpoint.  All it 
does is it reports a(n unspecified) debug trap, no different to one 
reported for single-stepping for example.  Then GDB examines the value of 
the PC reported in the stop reply packet, or, in the absence of one, it 
retrieves the value of that register via an ordinary access, to see if it 
corresponds to a breakpoint address it knows.

 All of this goes through the regular register cache and any necessary 
sign- or zero-extension, as appropriate, is made for each architecture in 
a generic way by the backend involved.  As I don't remember offhand I'd 
have to wade through code to track where exactly it actually happens, but 
I am fairly sure it's there.  If that didn't work, then I would expect GDB 
to be completely unusable for the target affected and therefore easily 
noticed -- unlike this watchpoint corner case.

> >  Umm, there aren't that many comments of this kind there actually...
> 
> 
> We started enforcing that rule not too long ago.

 Good choice, though you can certainly understand the rule isn't obvious 
from code itself yet. ;)

> Anyway, thanks for the fixes, and congratulations on your new role.  :-)

 Thanks.

  Maciej


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]