From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: Faster stepping amidst breakpoints
Date: Mon, 14 Feb 2011 10:50:00 -0000 [thread overview]
Message-ID: <20110214104955.GA1853@adacore.com> (raw)
In-Reply-To: <20110214032733.GV2384@adacore.com>
> Maxim Grigoriev actually noticed a regression, and I also noticed
> something on VxWorks.
The problem on VxWorks is more or less my own fault - I'm doing
something pretty shady: Inserting a breakpoint on VxWorks is done
via a WTX request which returns an "eventpoint ID". To remove that
breakpoint, we use the associated routine with the eventpoint ID
of our breakpoint. As a result, I need to keep a mapping between
breakpoint location and evenpoints IDs. I was more or less using
the bp_location address as the key to my mapping (this is the shady
part), hoping that it would never be reallocated. Unfortunately, this
is not true at all, or at least not anymore: See breakpoint_re_set_one,
which calls update_breakpoint_locations... The approach seems to be:
unless all locations, recompute new locations, and then purge the old
locations (update_global_location_list).
The reason why this works with the current default is that the
breakpoints get removed before they are re-set, and so the map
gets emptied before the new locations are created.
I'm thinking of adding a target_private_data field in struct
bp_target_info. I think we can get away with memory management
by allocating the private data at breakpoint insertion, and
deallocating it at removal. That way, I get rid of the map
entirely.
--
Joel
next prev parent reply other threads:[~2011-02-14 10:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-22 15:06 Maxim Grigoriev
2011-01-24 8:04 ` Daniel Jacobowitz
2011-01-24 21:08 ` Maxim Grigoriev
2011-01-31 7:47 ` Joel Brobecker
2011-01-31 15:39 ` Daniel Jacobowitz
2011-02-01 3:23 ` Joel Brobecker
2011-02-01 18:44 ` Michael Snyder
2011-02-03 4:55 ` Joel Brobecker
2011-02-02 17:10 ` Daniel Jacobowitz
2011-02-03 4:46 ` Joel Brobecker
2011-02-13 15:17 ` Mark Kettenis
2011-02-14 3:27 ` Joel Brobecker
2011-02-14 10:50 ` Joel Brobecker [this message]
2011-02-01 15:12 ` Pedro Alves
2011-02-03 22:54 ` Maxim Grigoriev
2011-02-04 16:06 ` Tom Tromey
2011-02-04 19:32 ` Maxim Grigoriev
2011-02-04 16:33 ` Daniel Jacobowitz
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=20110214104955.GA1853@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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