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 for invalid hw breakpoints


> Date: Thu, 1 Jun 2006 14:03:21 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> 
> -> Z2,11110000
> <- [empty: I don't support that.]
> tries to send: -> z2,11110000
> [internal error, I already know I don't support that!]
> 
> That could be changed in remote.c, but not removing what we didn't
> insert does seem cleaner.

Is it really clean for remote.c to throw an internal error?  I always
thought remote.c implemented an API similar to ptrace, so it should
behave like ptrace, i.e. return an error code, not throw exceptions.

More to the point, I don't like the solution: IMHO it assumes too much
about the procedure we use to insert high-level watchpoints.  The
assumption that we never insert target-side watchpoints past some
point in the value chain is not guaranteed to hold forever.

If solving this in remote.c seems unclean for some reason (I don't
think so, but that's me), how about adding to the watchpoint data
structure a flag for each low-level watchpoint we insert, and storing
there whether it was actually inserted?  The code that removes
watchpoints could then consult that flag and refrain from removing a
non-inserted watch.  Does this make sense?


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