This is the mail archive of the gdb-patches@sources.redhat.com 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: RFC: Centralize DECR_PC_AFTER_BREAK handling from infrun


> Date: Sat, 17 Jan 2004 17:20:07 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> One case, HANDLE_NONSTEPPABLE_WATCHPOINTS and DECR_PC_AFTER_BREAK, is simply
> removed.  There are no targets using this combination, and if one is added,
> it's non-obvious whether a nonsteppable watchpoint really should be affected
> by DECR_PC_AFTER_BREAK.

Right, but since we don't really know what that feature was about, I'd
suggest to leave a comment in adjust_pc_after_break that mentions
HANDLE_NONSTEPPABLE_WATCHPOINTS and that its support, if needed,
should be added.

> 	* breakpoint.c (software_breakpoint_inserted_here_p): New function.
> 	(bpstat_stop_status): Don't decrement PC.
> 	* breakpoint.h (software_breakpoint_inserted_here_p): Add
> 	prototype.
> 	* infrun.c (adjust_pc_after_break): New function.
> 	(handle_inferior_event): Call it, early.  Remove later references
> 	to DECR_PC_AFTER_BREAK.
> 	(normal_stop): Add commentary.

What happens if a location has both software and hardware
breakpoints?  Does the code still DTRT?

> +  /* If we've hit a breakpoint, we'll be stopped with SIGTRAP.  */
> +  if (ecs->ws.kind != TARGET_WAITKIND_STOPPED)
> +    return;
> +
> +  if (ecs->ws.value.sig != TARGET_SIGNAL_TRAP)
> +    return;

The original code didn't check these conditions, right?  So why add
them here?  (Also, the comment doesn't seem to describe the two
tests, only the second one.)


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