Re: [rfc][patch] Eliminate quadratic slow-down on number of solibs.

["Ulrich Weigand" <uweigand@de.ibm.com>]

Paul Pluzhnikov wrote:

> 2009-05-12  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
> 	* breakpoint.h: Add breakpoint_re_set_objfile prototype.
> 
> 	* breakpoint.c (create_overlay_event_breakpoint): Renamed
> 	from create_overlay_event_breakpoint_1, old
> 	create_overlay_event_breakpoint deleted.
> 	(breakpoint_re_set_objfile): Don't rescan all objfiles
> 	unnecessarily.
> 	(breakpoint_re_set): New function.
> 
> 	* symfile.c (new_symfile_objfile): Call breakpoint_re_set_objfile
> 	instead of breakpoint_re_set.
> 
> 	* objfiles.c (objfile_relocate): Likewise.


Maybe I'm missing something here, but this seems to break overlay
support.  Assume that _ovly_debug_event is defined in objfile A,
and breakpoint_re_set_objfile is called for objfile B.  The logic
in breakpoint_re_set_one will unconditionally delete all instances
of bp_overlay_event breakpoints, including the one in objfile A,
because it assumes they will be reset later.

However, after your change only objfile B is scanned for that symbol;
as it is not found there, the overlay event breakpoint will simply
not be reset.


I guess the situation for Cell/B.E. applications with multiple SPU
contexts would be even worse.  In this case, we have multiple objfiles
each defining its own instance of _ovly_debug_event, and for proper
operation of overlay debugging each of those instances need to carry
a breakpoint.

Before your patch, breakpoint_re_set would first delete all instances
of the overlay event breakpoint, and subsequently reset them all.
After your patch, breakpoint_re_set_objfile will *still* delete *all*
instances, but will subsequently reset at most one of them  ...


How is this supposed to work?  If you're going to reset only breakpoints
from one objfile, maybe you should likewise *delete* only breakpoints
from that objfile?


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com