This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: pending breakpoints change breakpoint number
- From: Jim Ingham <jingham at apple dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 5 May 2004 09:32:31 -0700
- Subject: Re: pending breakpoints change breakpoint number
- References: <6F7D1639-8F41-11D8-8CF3-000A958F4C44@apple.com> <4098FFA7.90803@gnu.org>
Andrew,
Yes, the one symbolic->many actual breakpoints is something I am
interested in working on. It is high on my "list of tasks I keep
trying to get into the next release". Sadly, it didn't make it into
the current release, so it will be a little while (certainly not till
after WWDC in July) before I can get to this.
I still think the notification is necessary, and is a fairly small
change. I am sure the Eclipse folks are also going to run into this
like the Xcode folks did. And if we also include the address(s) the
breakpoint resolved to (and maybe the symbol name - which would be
useful for file:line breakpoints in template functions), then the
notification will be useful even after we fix the M:N problem. It
means that a GUI which displays the addresses of breakpoints as part of
its breakpoint display can keep these up to date without needing an
extra round trip to gdb...
I fixed it in our sources so that I only change the breakpoint number
when we set more than one breakpoint. That was a simple change since
you already have the pending breakpoint in create_breakpoints, though
it is admittedly a bit of a hack. Still it actually fixes most cases
and seems to me better than the current state of things. But this
isn't nearly as important as the notification.
Jim
On May 5, 2004, at 7:52 AM, Andrew Cagney wrote:
Hi, all...
I have been looking at the pending breakpoint changes (to merge them
into the Apple gdb). Overall it is nicer than the future-break
version that we had, so that is great.
However, one thing really bugs me about it. That is that it changes
the breakpoint number out from under me when it manages to resolve
the breakpoint.
This is pretty annoying to a human user, since if I want to do
anything to the breakpoint, I have to go find it's number again from
info break. But it is very bad for a gui that is trying to run gdb
from, say, the MI. The GUI has to use the breakpoint number to do
things like disable the breakpoint, delete it, etc. So if the number
switches out from under it, the gui can no longer operate on the
breakpoint. Very bad...
So there are two things that need to be addressed here.
First off, if we are going to change the breakpoint number, clearly
need a breakpoint_resolved event/hook/observer thingie that we can
use to tell the GUI that breakpoint 2 resolved to breakpoint 5, and
the GUI needs to change accordingly. This is pretty easy. If it
were a gdb_event, the addition to gdb-events.sh would look like:
The breakpoint number changing is a known bug in the current
implementation. It was concluded that fixing it (a non-trivial task)
was closely tied to fixing things like M:N breakpoints (one breakpoint
with multiple locations) and hence should be made part of that task
(painful but working pending breakpoints were considered better than
no pending breakpoints).
Seems that the N:M breakpoints have fallen by the wayside. Interested
in working on that? Daniel can give you a status report of where
things are at.
Andrew
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer