This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Ignore breakpoints when reading memory.
- From: "Jim Blandy" <jimb at red-bean dot com>
- To: "Mark Kettenis" <mark dot kettenis at xs4all dot nl>
- Cc: vladimir at codesourcery dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 21 Jan 2008 09:19:35 -0800
- Subject: Re: [RFA] Ignore breakpoints when reading memory.
- References: <200712011419.45773.vladimir@codesourcery.com> <200712041811.lB4IBToM005652@brahms.sibelius.xs4all.nl>
On Dec 4, 2007 10:11 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Sat, 1 Dec 2007 14:19:45 +0300
> >
> > This commit prepares us for always-inserted-breakpoints mode.
> > If breakpoints are always inserted, then reading the code memory
> > will read the breakpoint instructions, not the original content.
> > This patch makes us try to restore the original comments using
> > the breakpoints table. OK?
>
> So now reading from target memory will need to traverse the complete
> list of inserted breakpoints. Did you do any benchmarking to see what
> the impact of this change is, especially when running on a somewhat
> slow machine?
I measured this on my laptop (not slow), by timing 'runtest break.exp
call-ar-st.exp' nine times. I got:
with patch:
user (+ 1.57 1.55 1.51 1.58 1.64 1.59 1.68 1.54 1.53) 14.19
without patch:
user (+ 1.55 1.61 1.54 1.52 1.58 1.60 1.55 1.58 1.61) 14.14
These times include the compilations, symbol table reading, and so on.
It would have been better to write a custom expect script, and
perhaps add a GDB maintenance command to print the current running
total for CPU time. But for what it is, the effect of the patch is in
the noise.