This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Cached function lookup
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- To: Klee Dienes <kdienes at apple dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 06 Feb 2002 14:00:15 -0500
- Subject: Re: [RFA] Cached function lookup
- References: <8A9ABA76-1A1B-11D6-BA6D-0030653FA4C6@apple.com>
Klee Dienes <email@example.com> writes:
> (This is basically the same patch I sent last week, just updated
> to the latest source base.)
> This patch allows functions in the target used by GDB ("malloc",
> "scm_lookup_cstr", and later a ton of Objective-C functions) to have
> their values cached and re-used unless the symbol table has changed
> in-between calls. This is a performance win overall, and a particular
> win when dispatching Objective-C method calls and looking up
> Objective-C type information from the runtime.
> 2002-02-04 Klee Dienes <firstname.lastname@example.org>
> * breakpoint.c (breakpoint_re_set, breakpoint_re_set_all,
> breakpoint_update): Instead of re-parsing all deferred
> every time breakpoint_re_set is called, increment a generation
> number. When breakpoints need to be up-to-date, call
> breakpoint_update. This prevents unnecessary re-parsing of
> breakpoint information (and massive future-break spam) when
> multiple shared libraries are loaded at the same time.
Let me see if I understand the situation:
The inferior hits a shlib event breakpoint, indicating that it's
loaded or unloaded some stuff. GDB scans the dynamic linker's table,
and discovers that several new shared libraries have been loaded.
As the code currently stands, GDB will recompute its breakpoints'
addresses after each solib's symbols are read. Your change makes GDB
delay this until it's about to insert the breakpoints.
Is that correct?