From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10419 invoked by alias); 3 Jun 2009 19:46:01 -0000 Received: (qmail 10395 invoked by uid 22791); 3 Jun 2009 19:45:57 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 19:45:47 +0000 Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id n53Jjit6020586 for ; Wed, 3 Jun 2009 12:45:44 -0700 Received: from pzk33 (pzk33.prod.google.com [10.243.19.161]) by spaceape13.eur.corp.google.com with ESMTP id n53Jhpgr009340 for ; Wed, 3 Jun 2009 12:45:42 -0700 Received: by pzk33 with SMTP id 33so251330pzk.23 for ; Wed, 03 Jun 2009 12:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.177.5 with SMTP id z5mr547328wfe.156.1244058342125; Wed, 03 Jun 2009 12:45:42 -0700 (PDT) In-Reply-To: References: <8ac60eac0905051749p3b5d14d9q8903b9de8e18137f@mail.gmail.com> Date: Wed, 03 Jun 2009 19:46:00 -0000 Message-ID: <8ac60eac0906031245v4db0ae38ubeee91d49611851f@mail.gmail.com> Subject: Re: [patch] Eliminate quadratic slow-down on number of solibs (part 2). From: Paul Pluzhnikov To: tromey@redhat.com Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00049.txt.bz2 On Fri, May 29, 2009 at 6:59 PM, Tom Tromey 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. =A0This 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=3D0xd57fe0) at ../../src/gdb/breakpoint.c:7754 7754 { (top) bt #0 breakpoint_re_set_objfile (objfile=3D0xd57fe0) at ../../src/gdb/breakpoint.c:7754 #1 0x00000000004e3487 in new_symfile_objfile (objfile=3D0xd57fe0, mainline=3D0, verbo=3D0) at ../../src/gdb/symfile.c:924 #2 0x00000000004e360e in symbol_file_add_with_addrs_or_offsets ( abfd=3D0xddc420, from_tty=3D0, addrs=3D0xddd700, offsets=3D0x0, num_offsets=3D0, mainline=3D0, flags=3D) at ../../src/gdb/symfile.c:1084 #3 0x00000000004e3ee5 in symbol_file_add_from_bfd (abfd=3D0xd57fe0, from_tty=3D0, addrs=3D0x0, mainline=3D0, flags=3D) at ../../src/gdb/symfile.c:1103 #4 0x00000000004e3812 in symbol_file_add_with_addrs_or_offsets ( abfd=3D, from_tty=3D0, addrs=3D0xa62410, offsets=3D0x0, num_offsets=3D0, mainline=3D0, flags=3D) at ../../src/gdb/symfile.c:1033 #5 0x00000000004e3ee5 in symbol_file_add_from_bfd (abfd=3D0xd57fe0, from_tty=3D0, addrs=3D0x0, mainline=3D0, flags=3D) at ../../src/gdb/symfile.c:1103 #6 0x0000000000462070 in symbol_add_stub (arg=3D) at ../../src/gdb/solib.c:470 #7 0x00000000004fdf8b in catch_errors ( func=3D0x461ff0 , func_args=3D0xae7a10, errstring=3D0x658e68 "Error while reading shared library symbols:\n", mask=3D) at ../../src/gdb/exceptions.c:510 #8 0x0000000000461dd1 in solib_read_symbols (so=3D0x0, from_tty=3D0) at ../../src/gdb/solib.c:496 #9 0x0000000000462623 in solib_add (pattern=3D0x0, from_tty=3D0, target=3D, readsyms=3D1) 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 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? =A0If not, wouldn't it also fix your > situation? At process startup, with the breakpoint on '_exit', you'll have: (top) p *b $11 =3D {next =3D 0x0, type =3D bp_breakpoint, enable_state =3D bp_enabled, disposition =3D disp_donttouch, number =3D 2, loc =3D 0x2c2f390, line_number =3D 29, source_file =3D 0x2596510 "../sysdeps/unix/sysv/linux/_exit.c", ... addr_string =3D 0x1ea9fc0 "_exit", language =3D language_cplus, ... (top) p *b.loc $12 =3D {next =3D 0x0, global_next =3D 0x0, loc_type =3D bp_loc_software_breakpoint, owner =3D 0x2c2f260, cond =3D 0x0, shlib_disabled =3D 1 '\001', enabled =3D 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=3D0, name=3D0x7fffffffcf40 "_exit", linkage_name=3D0x0, domain=3DVAR_DOMAIN) at ../../src/gdb/symtab.c:1525 #1 0x000000000058044a in lookup_symbol_file ( name=3D0x7fffffffcf40 "_exit", linkage_name=3D0x0, block=3D0x0, domain=3DVAR_DOMAIN, anonymous_namespace=3D0) at ../../src/gdb/cp-namespace.c:450 #2 0x0000000000580581 in cp_lookup_symbol_namespace ( namespace=3D0x7fffffffce70 "", name=3D0x7fffffffcf40 "_exit", linkage_name=3D0x0, block=3D0x0, domain=3DVAR_DOMAIN) at ../../src/gdb/cp-namespace.c:401 #3 0x000000000058076c in lookup_namespace_scope ( name=3D0x7fffffffcf40 "_exit", linkage_name=3D0x0, block=3D0x0, domain=3DVAR_DOMAIN, scope=3D0x65ead0 "", scope_len=3D) at ../../src/gdb/cp-namespace.c:357 #4 0x00000000004ddad3 in lookup_symbol_in_language ( name=3D0x7fffffffcf40 "_exit", block=3D0x0, domain=3DVAR_DOMAIN, lang=3Dlanguage_cplus, is_a_field_of_this=3D0x0) at ../../src/gdb/symtab.c:1345 #5 0x0000000000558f20 in find_imps (symtab=3D0x0, block=3D0x0, method=3D0x1ea9fc0 "_exit", syms=3D0x0, nsym=3D0x7fffffffd05c, ndebug=3D0x7fffffffd058) at ../../src/gdb/objc-lang.c:1319 #6 0x00000000004e702c in decode_objc (argptr=3D0x7fffffffd288, funfirstline=3D1, file_symtab=3D0x0, canonical=3D0x0, saved_arg=3D) at ../../src/gdb/linespec.c:1129 #7 0x00000000004e85f3 in decode_line_1 (argptr=3D0x7fffffffd288, funfirstline=3D1, default_symtab=3D0xd2a300, default_line=3D1347, canonical=3D0x0, not_found_ptr=3D0x7fffffffd29c) at ../../src/gdb/linespec.c:746 #8 0x00000000004b7e5c in breakpoint_re_set_one ( bint=3D) at ../../src/gdb/breakpoint.c:7620 #9 0x00000000004fdf8b in catch_errors ( func=3D0x4b7d00 , func_args=3D0x2c2f260, errstring=3D0x167bd20 "Error in re-setting breakpoint 2: ", mask=3D) at ../../src/gdb/exceptions.c:510 #10 0x00000000004bad10 in breakpoint_re_set_objfile ( objfile=3D0x2a2ca10) at ../../src/gdb/breakpoint.c:7767 isn't easy either :-( --=20 Paul Pluzhnikov