public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb@sources.redhat.com
Subject: Keeping breakpoints inserted
Date: Thu, 29 Nov 2007 19:24:00 -0000	[thread overview]
Message-ID: <200711292224.23659.vladimir@codesourcery.com> (raw)


One of the infrastructure bits necessary for the non-stop threads
debugging is always-inserted-breakpoints mode. If GDB has stopped
one thread, and other threads are running, we want those other threads
to still hit breakpoints and watchpoints. However, current GDB removes
all breakpoints from the target before giving user a prompt, and this
has to change.

I've spend quite time examining breakpoint.c and infrun.c and 
cleaning/localizing the decisions as to when breakpoints are 
inserted/removed, and I believe I now have a fully workable plan 
to make breakpoints always inserted. We need to:

1. Generally, whenever a breakpoint is added, changed, or 
removed, immediately communicate this change to the target.

2. In order to do that, we need to have a single function called on each
breakpoint change. That function will be responsible to update 
bp_location_chain, using locations of existing breakpoint, removing
breakpoint locations that are no longer necessary, and inserting newly 
added locations. Since we can have several breakpoints at the same address, 
the function should take care not to remove location belonging to a 
deleted breakpoint, if there's location at the same address belonging 
to a still-present breakpoint.

Specifically, the function will walk over current bp_location_chain. 
For each location:

        - if no breakpoint has a location with the same address, 
	we remove the location from target
        - if no breakpoint has this bp_location* object, we free it.

All locations present in some breakpoint but not yet present in 
bp_location_chain are added to bp_location_chain and inserted to target.

3. The functions that read memory should be modified to restore memory 
content overwritten by breakpoints. I believe there's a 
single function that is in all memory-reading code paths, so this change is
easy.

4. infrun.c should be modified to avoid removing breakpoints when 
we stop -- most probably under control of a new variable.

5. Sometimes, infrun.c still need to remove breakpoints -- in particular 
when stepping over them. We'll implement smart code that allows to 
step over breakpoint without removing it -- Jim will separately post details
on this. For watchpoints, we still have to remove them when stepping 
over watchpoint (for the case of non-continuable non-steppable watchpoints).

6. It's possible that we get an error when inserting breakpoint. 
In present GDB, such an error will be printed when we try to resume
target, and the target won't be resumed. With always-inserted mode, 
the error will be printed when we add or change the breakpoint. However, 
resuming target with not-inserted breakpoint still seems  wrong behaviour, 
so we'll try to insert breakpoints again when resuming, and if that fails,
stop.

Anybody has comments on this approach?

- Volodya

             reply	other threads:[~2007-11-29 19:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 19:24 Vladimir Prus [this message]
2007-11-30  1:25 ` Michael Snyder
2007-11-30 10:11   ` Vladimir Prus
2007-11-30 21:03 ` Thiago Jung Bauermann
2007-11-30 21:41   ` Michael Snyder
2007-12-01  0:08     ` Jim Blandy
2007-12-01  1:43       ` Michael Snyder
2007-12-01 17:52         ` Jim Blandy
2007-12-02 18:38           ` Thiago Jung Bauermann
2007-12-03 18:14             ` Jim Blandy
2007-11-30 23:53   ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711292224.23659.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).