Re: [patch] Eliminate quadratic slow-down on number of solibs (part 2).

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Fri, May 29, 2009 at 6:59 PM, Tom Tromey <tromey@redhat.com> wrote:

> Paul> It feels like a hack, but I don't see how to achieve the same
> Paul> result in a cleaner way :-(
>
> I think the idea is sound: defer some updates until after a batch of
> updates has gone through.
>
> The problem is the implementation -- adding a new global is ugly.
> But, it seems to me that it would not be too hard to add a new flag
> argument to the call chain here.  This would be a bit ad hoc, but so
> what?

The problem is that the call chain is deep:

Breakpoint 1, breakpoint_re_set_objfile (objfile=0xd57fe0) at
../../src/gdb/breakpoint.c:7754
7754    {
(top) bt
#0  breakpoint_re_set_objfile (objfile=0xd57fe0)
    at ../../src/gdb/breakpoint.c:7754
#1  0x00000000004e3487 in new_symfile_objfile (objfile=0xd57fe0,
    mainline=0, verbo=0) at ../../src/gdb/symfile.c:924
#2  0x00000000004e360e in symbol_file_add_with_addrs_or_offsets (
    abfd=0xddc420, from_tty=0, addrs=0xddd700, offsets=0x0,
    num_offsets=0, mainline=0, flags=<value optimized out>)
    at ../../src/gdb/symfile.c:1084
#3  0x00000000004e3ee5 in symbol_file_add_from_bfd (abfd=0xd57fe0,
    from_tty=0, addrs=0x0, mainline=0, flags=<value optimized out>)
    at ../../src/gdb/symfile.c:1103
#4  0x00000000004e3812 in symbol_file_add_with_addrs_or_offsets (
    abfd=<value optimized out>, from_tty=0, addrs=0xa62410,
    offsets=0x0, num_offsets=0, mainline=0,
    flags=<value optimized out>) at ../../src/gdb/symfile.c:1033
#5  0x00000000004e3ee5 in symbol_file_add_from_bfd (abfd=0xd57fe0,
    from_tty=0, addrs=0x0, mainline=0, flags=<value optimized out>)
    at ../../src/gdb/symfile.c:1103
#6  0x0000000000462070 in symbol_add_stub (arg=<value optimized out>)
    at ../../src/gdb/solib.c:470
#7  0x00000000004fdf8b in catch_errors (
    func=0x461ff0 <symbol_add_stub>, func_args=0xae7a10,
    errstring=0x658e68 "Error while reading shared library
symbols:\n", mask=<value optimized out>) at
../../src/gdb/exceptions.c:510
#8  0x0000000000461dd1 in solib_read_symbols (so=0x0, from_tty=0)
    at ../../src/gdb/solib.c:496
#9  0x0000000000462623 in solib_add (pattern=0x0, from_tty=0,
    target=<value optimized out>, readsyms=1)
    at ../../src/gdb/solib.c:752

We know we should defer breakpoint_re_set in frame #9.
We want to "telegraph" that message into frame #1.
But how?

On Fri, May 29, 2009 at 7:05 PM, Tom Tromey <tromey@redhat.com> wrote:

> Paul> The problem is that breakpoint_re_set does a bunch of unnecessary
> Paul> work, even when it knows which solib it should be dealing with.
>
> What happens if we change this?
>
> I'm wondering about something like updating only the pending
> breakpoints when we read a new objfile for an existing inferior.
> Would this break something?  If not, wouldn't it also fix your
> situation?

At process startup, with the breakpoint on '_exit', you'll have:

(top) p *b
$11 = {next = 0x0, type = bp_breakpoint, enable_state = bp_enabled,
  disposition = disp_donttouch, number = 2, loc = 0x2c2f390,
  line_number = 29,
  source_file = 0x2596510 "../sysdeps/unix/sysv/linux/_exit.c",
  ...
  addr_string = 0x1ea9fc0 "_exit", language = language_cplus,
...
(top) p *b.loc
$12 = {next = 0x0, global_next = 0x0,
  loc_type = bp_loc_software_breakpoint, owner = 0x2c2f260,
  cond = 0x0, shlib_disabled = 1 '\001', enabled = 1 '\001',
...

So the b->loc.shlib_disabled makes this breakpoint "pending".

Since any library could define _exit, we need to see if the current objfile
does (it will not). Repeat for next objfile, etc. until we reach all the
way to libc. To add insult to injury, current objfile is not propagated
into decode_line_1, so it does symbol lookup in all psymtabs, making this
quadratic on number of solibs. Propagating current objfile down another
10 levels of call stack:

#0  lookup_symbol_aux_psymtabs (block_index=0,
    name=0x7fffffffcf40 "_exit", linkage_name=0x0, domain=VAR_DOMAIN)
    at ../../src/gdb/symtab.c:1525
#1  0x000000000058044a in lookup_symbol_file (
    name=0x7fffffffcf40 "_exit", linkage_name=0x0, block=0x0,
    domain=VAR_DOMAIN, anonymous_namespace=0)
    at ../../src/gdb/cp-namespace.c:450
#2  0x0000000000580581 in cp_lookup_symbol_namespace (
    namespace=0x7fffffffce70 "", name=0x7fffffffcf40 "_exit",
    linkage_name=0x0, block=0x0, domain=VAR_DOMAIN)
    at ../../src/gdb/cp-namespace.c:401
#3  0x000000000058076c in lookup_namespace_scope (
    name=0x7fffffffcf40 "_exit", linkage_name=0x0, block=0x0,
    domain=VAR_DOMAIN, scope=0x65ead0 "",
    scope_len=<value optimized out>)
    at ../../src/gdb/cp-namespace.c:357
#4  0x00000000004ddad3 in lookup_symbol_in_language (
    name=0x7fffffffcf40 "_exit", block=0x0, domain=VAR_DOMAIN,
    lang=language_cplus, is_a_field_of_this=0x0)
    at ../../src/gdb/symtab.c:1345
#5  0x0000000000558f20 in find_imps (symtab=0x0, block=0x0,
    method=0x1ea9fc0 "_exit", syms=0x0, nsym=0x7fffffffd05c,
    ndebug=0x7fffffffd058) at ../../src/gdb/objc-lang.c:1319
#6  0x00000000004e702c in decode_objc (argptr=0x7fffffffd288,
    funfirstline=1, file_symtab=0x0, canonical=0x0,
    saved_arg=<value optimized out>) at ../../src/gdb/linespec.c:1129
#7  0x00000000004e85f3 in decode_line_1 (argptr=0x7fffffffd288,
    funfirstline=1, default_symtab=0xd2a300, default_line=1347,
    canonical=0x0, not_found_ptr=0x7fffffffd29c)
    at ../../src/gdb/linespec.c:746
#8  0x00000000004b7e5c in breakpoint_re_set_one (
    bint=<value optimized out>) at ../../src/gdb/breakpoint.c:7620
#9  0x00000000004fdf8b in catch_errors (
    func=0x4b7d00 <breakpoint_re_set_one>, func_args=0x2c2f260,
    errstring=0x167bd20 "Error in re-setting breakpoint 2: ",
    mask=<value optimized out>) at ../../src/gdb/exceptions.c:510
#10 0x00000000004bad10 in breakpoint_re_set_objfile (
    objfile=0x2a2ca10) at ../../src/gdb/breakpoint.c:7767

isn't easy either :-(

-- 
Paul Pluzhnikov