[PATCH] breakpoint remove fail handle bug fix
Yao Qi
yao@codesourcery.com
Wed Apr 11 10:53:00 GMT 2012
Here are some my thoughts on this problem. I didn't read patch
carefully, so have no comments on it.
On 04/11/2012 05:07 PM, Hui Zhu wrote:
> This because is when GDB got fail when it remove the breakpoint, it give
> up the control of this breakpoint.
You are removing breakpoints when inferior is in background execution.
It is expected or reasonable that GBD is unable to remove breakpoint
instructions from inferior when it is running (due to ptrace limitation
IIRC).
> There are 2 issues about it:
> 1. When the GDB stop, this breakpoint is not be removed.
This is because breakpoint instances (not breakpoint instructions
written in inferior) was remove when inferior is running. When inferior
stops, breakpoint instructions are not removed from inferior, because
there is no breakpoint instances in GDB. Current policy in GDB is that
even we get something wrong in removing breakpoints, still remove them
from global list. See the comment in breakpoint.c:
if (remove_breakpoint (old_loc, mark_uninserted))
{
/* This is just about all we can do. We could keep
this location on the global list, and try to
remove it next time, but there's no particular
reason why we will succeed next time.
Note that at this point, old_loc->owner is still
valid, as delete_breakpoint frees the breakpoint
only after calling us. */
printf_filtered (_("warning: Error removing "
"breakpoint %d\n"),
old_loc->owner->number);
}
If we change the policy to "keep breakpoint instances if fail to remove
from inferior", this problem may be fixed.
> 2. If inferior is stoped by this breakpoint, adjust_pc_after_break
> didn't know this stop is beauce the breakpoint, so the pc address will
> not be adjust to the right value.
adjust_pc_after_break doesn't know because there is no breakpoint
instance in GDB.
--
Yao (é½å°§)
More information about the Gdb-patches
mailing list