This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [4/9] associate bpstat with location
On Saturday 08 September 2007 16:15:35 Eli Zaretskii wrote:
> > The reason why the assumption is valid is because the only way to have
> > several bpstats refer to one breakpoint is when breakpoint has two
> > locations, and both locations have the same address. That makes no sense --
> > there's no per-location data that can make those locations different
> > in behaviour, and so having two locations with same address would
> > be a bug.
>
> If this can happen only as a result of a bug, perhaps a gdb_assert is
> in order.
Yes, except there's no convenient place where assert can be placed.
To assert this assumption you have to actually walk though all bpstats
and check for duplication locations, and that's too much work.
> > > > case bp_access_watchpoint:
> > > > if (bs->old_val != NULL)
> > > > {
> > > > - annotate_watchpoint (bs->breakpoint_at->number);
> > > > + annotate_watchpoint (b->number);
> > >
> > > Watchpoints also? Did you make corresponding changes in the code that
> > > sets watchpoints?
> >
> > No. This patch is not supposed to have any change in behaviour whatsoever,
> > it merely moves a data member.
>
> Does that mean that the display of watchpoints for "info watch" will
> be now different from "info break"?
*This* patch does not change input of "info break". In fact, it does not change
any observable behaviour.
As for future patches, the basically have two output changes:
1. Printing of multiple locations, if any
2. Printing of "(p)"
Neither of those output changes are applicable to watchpoints. (1) is not
applicable because watchpoints can't have multiple locations, in the same
way breakpoints do. (2) is not applicable because gdb will never try to
set bp_shlib_disabled state for a watchpoint, neither in the current code, nor
after my patches.
- Volodya