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

Ulrich Weigand
2009-06-22T17:10:24Z

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