This is the mail archive of the 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]

Re: A patch for ia32 hardware watchpoint.

>>>>> "hjl" == H J Lu <> writes:
hjl> 2000-03-07  H.J. Lu  <>
hjl> 	* breakpoint.c (insert_breakpoints): Also pass b->number to
hjl> 	target_insert_watchpoint () if NEED_WATCHPOINT_NUMBER is
hjl> 	defined. Don't return error if errno is EBUSY.
hjl> 	(remove_breakpoint): Also pass b->number to
hjl> 	target_remove_watchpoint () if NEED_WATCHPOINT_NUMBER is
hjl> 	defined.
hjl> 	(delete_breakpoint): Call target_delete_watchpoint () for
hjl> 	watchpoint if NEED_WATCHPOINT_NUMBER is defined.

Having the API for target_{insert,remove}_watchpoint() change
depending on whether NEED_BREAKPOINT_NUMBER is defined seems dangerous
to me.  An extra parameter that is ignored by those targets that don't
care about it seems like a better option to me.

I was planning to propose that the breakpoint pointer itself be passed
to the target_{insert,remove}_{break,watch}point() functions, so this
is as good of time as any.  

The reason I want this is so that GDB's target code can record target-
specific info about the breakpoint.  For example, if the target gives
the break/watchpoint an ID, the insert function can record it in the
breakpoint so it is available for use in the delete function.  Right
now, my WDB target code inserts a record into a data structure which
maps WDB's breakpoint IDs with the thread+address when a breakpoint is 
inserted.  The remove code searches for any breakpoint that matches the
thread+address and removes that ID.  

This adds unnecessary complexity, and in the case where two break-
points are inserted at the same address you might end up removing a
different breakpoint than was inserted.  This isn't a problem now, but
I'd also like to be able to support smarter breakpoints.  For example,
breakpoints where the ignore count, or perhaps even some sort of
simple conditions are handled on the target.  In those cases, we'd want
to make sure to delete the same breakpoint that was inserted.

Ok, enough on that tangent.

Can you explain the reasoning about not returning error if errno is
EBUSY.  If there aren't enough watchpoint registers, shouldn't the
watchpoint create itself fail?  I thought TARGET_CAN_USE_HARDWARE_-
WATCHPOINT() was intended to prevent this.  It appears that you're
trying to handle oversubscription of watchpoint resources rather than
preventing such oversubscription in the first place.

Also, while many target vectors report error reasons through errno, 
it leaves a bad taste in my mouth.  Perhaps this is because we have
to map target errors into UNIX/POSIX errnos, and there isn't always
a clean mapping.


J.T. Conklin
RedBack Networks

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