From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13243 invoked by alias); 22 Jul 2009 18:11:08 -0000 Received: (qmail 13216 invoked by uid 22791); 22 Jul 2009 18:11:05 -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.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Jul 2009 18:10:56 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id n6MIApOe024513 for ; Wed, 22 Jul 2009 19:10:52 +0100 Received: from qw-out-2122.google.com (qwi5.prod.google.com [10.241.195.5]) by wpaz5.hot.corp.google.com with ESMTP id n6MIAnRs008595 for ; Wed, 22 Jul 2009 11:10:49 -0700 Received: by qw-out-2122.google.com with SMTP id 5so192656qwi.47 for ; Wed, 22 Jul 2009 11:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.14 with SMTP id z14mr244766qck.24.1248286249106; Wed, 22 Jul 2009 11:10:49 -0700 (PDT) In-Reply-To: <8ac60eac0907221016j410f890ald54ac66c7c3291f9@mail.gmail.com> References: <8ac60eac0907161724v40e5bd8bg7877d8901b8d7b6e@mail.gmail.com> <8ac60eac0907220849w3add6806h96e3df1d3257ac54@mail.gmail.com> <200907221732.46472.pedro@codesourcery.com> <8ac60eac0907221016j410f890ald54ac66c7c3291f9@mail.gmail.com> Date: Wed, 22 Jul 2009 18:12:00 -0000 Message-ID: <8ac60eac0907221110v6ac9bc32u4cb17765e2cb170e@mail.gmail.com> Subject: Re: [patch] Speed up find_pc_section From: Paul Pluzhnikov To: Pedro Alves Cc: tromey@redhat.com, gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary=00163646d5be74c422046f4f4a53 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-07/txt/msg00558.txt.bz2 --00163646d5be74c422046f4f4a53 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2718 On Wed, Jul 22, 2009 at 10:16 AM, Paul Pluzhnikov w= rote: > On Wed, Jul 22, 2009 at 9:32 AM, Pedro Alves wrot= e: > >> In the OBJF_USERLOADED case, you rebuild the map when you don't >> really need to. > > I think it's pretty clear that what I really need is a new 'remove_objfil= e' > kind of observer. I am not thinking clearly today :-( I don't need a new observer: free_objfile is in the same source, so I just need to set the flag there as well. >> You're also likely breaking xcoffsolib.c and the vmap code in exec.c, as >> it calls free_objfile without going through observers. > > This would be handled by the 'remove_objfile' observer, I think. > >> Given the new_objfile observer, do we still need the exec_changed and >> solib observers? > > No, I've removed that (new patch attached). I feel going in circles here. The exec_changed observer was to address reread_symbols, which doesn't create a new objfile. I believe that's still necessary. The solib_load/unload observers don't appear to be needed though: the load case will create a new objfile, the unload case (when !OBJF_USERLOADED) will do free_objfile). On Wed, Jul 22, 2009 at 10:40 AM, Pedro Alves wrote: >> I think it's pretty clear that what I really need is a new 'remove_objfi= le' >> kind of observer. > > Would setting objfiles_updated_p from e.g., unlink_objfile work? Exactly. Though I think free_objfile is a more logical place for it. > I think that the need for the solib load/unload observer > would go away too if the map is flushed on objfile > removal/freeing/unlinking as well? Yes. > Come to look at it deeper, what is happening with > symbol_file_add_with_addrs_or_offsets, if the objfile has only > minimal symbols (but still has sections)? =A0allocate_objfile is called, > which builds the section table, but, there's a path that does an > early return before calling the new_objfile observer, if there are > no symbols. That sounds like a bug: we created a new_objfile, but didn't notify observers. Eeasy enough to work around though: I'll set the flag in allocate_objfile as well. > It would be cleaner and easier to review, easier for you (I think), > and better for the archives in the future, IMHO. =A0But I don't mind > much if a new patch is cooked on top. Let's try for one more fix before reverting ... Re-tested on Linux/x86_64 with no new failures. Thanks, --=20 Paul Pluzhnikov 2009-07-22 Paul Pluzhnikov * objfiles.c (allocate_objfile): Must rebuild section map. (free_objfile, objfile_relocate): Likewise. (set_objfiles_updated_on_solib_activity): Remove. (_initialize_objfiles): Adjust. --00163646d5be74c422046f4f4a53 Content-Type: text/plain; charset=US-ASCII; name="gdb-find_pc_section-20090722-3.txt" Content-Disposition: attachment; filename="gdb-find_pc_section-20090722-3.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fxgd9tg81 Content-length: 2396 SW5kZXg6IG9iamZpbGVzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1Mg ZmlsZTogL2N2cy9zcmMvc3JjL2dkYi9vYmpmaWxlcy5jLHYKcmV0cmlldmlu ZyByZXZpc2lvbiAxLjg2CmRpZmYgLXUgLXAgLXUgLXIxLjg2IG9iamZpbGVz LmMKLS0tIG9iamZpbGVzLmMJMjEgSnVsIDIwMDkgMjA6NTQ6MzAgLTAwMDAJ MS44NgorKysgb2JqZmlsZXMuYwkyMiBKdWwgMjAwOSAxNzo1NTo0MSAtMDAw MApAQCAtMjM1LDYgKzIzNSw4IEBAIGFsbG9jYXRlX29iamZpbGUgKGJmZCAq YWJmZCwgaW50IGZsYWdzKQogICAvKiBTYXZlIHBhc3NlZCBpbiBmbGFnIGJp dHMuICovCiAgIG9iamZpbGUtPmZsYWdzIHw9IGZsYWdzOwogCisgIG9iamZp bGVzX3VwZGF0ZWRfcCA9IDE7ICAvKiBSZWJ1aWxkIHNlY3Rpb24gbWFwIG5l eHQgdGltZSB3ZSBuZWVkIGl0LiAgKi8KKwogICByZXR1cm4gKG9iamZpbGUp OwogfQogCkBAIC01MDEsNiArNTAzLDcgQEAgZnJlZV9vYmpmaWxlIChzdHJ1 Y3Qgb2JqZmlsZSAqb2JqZmlsZSkKICAgb2JzdGFja19mcmVlICgmb2JqZmls ZS0+b2JqZmlsZV9vYnN0YWNrLCAwKTsKICAgeGZyZWUgKG9iamZpbGUpOwog ICBvYmpmaWxlID0gTlVMTDsKKyAgb2JqZmlsZXNfdXBkYXRlZF9wID0gMTsg IC8qIFJlYnVpbGQgc2VjdGlvbiBtYXAgbmV4dCB0aW1lIHdlIG5lZWQgaXQu ICAqLwogfQogCiBzdGF0aWMgdm9pZApAQCAtNjgyLDYgKzY4NSw3IEBAIG9i amZpbGVfcmVsb2NhdGUgKHN0cnVjdCBvYmpmaWxlICpvYmpmaWwKIAogICAv KiBSZWxvY2F0ZSBicmVha3BvaW50cyBhcyBuZWNlc3NhcnksIGFmdGVyIHRo aW5ncyBhcmUgcmVsb2NhdGVkLiAqLwogICBicmVha3BvaW50X3JlX3NldCAo KTsKKyAgb2JqZmlsZXNfdXBkYXRlZF9wID0gMTsgIC8qIFJlYnVpbGQgc2Vj dGlvbiBtYXAgbmV4dCB0aW1lIHdlIG5lZWQgaXQuICAqLwogfQogDAogLyog TWFueSBwbGFjZXMgaW4gZ2RiIHdhbnQgdG8gdGVzdCBqdXN0IHRvIHNlZSBp ZiB3ZSBoYXZlIGFueSBwYXJ0aWFsCkBAIC05OTgsMTkgKzEwMDIsOCBAQCBz ZXRfb2JqZmlsZXNfdXBkYXRlZF9vbl9leGVfY2hhbmdlICh2b2lkCiAgIG9i amZpbGVzX3VwZGF0ZWRfcCA9IDE7ICAvKiBSZWJ1aWxkIHNlY3Rpb24gbWFw IG5leHQgdGltZSB3ZSBuZWVkIGl0LiAgKi8KIH0KIAotLyogU2V0IG9iamZp bGVzX3VwZGF0ZWRfcCBzbyBzZWN0aW9uIG1hcCB3aWxsIGJlIHJlYnVpbHQg bmV4dCB0aW1lIGl0Ci0gICBpcyB1c2VkLiAgQ2FsbGVkIGJ5IHNvbGliX2xv YWRlZC91bmxvYWRlZCBvYnNlcnZlci4gICovCi0KLXN0YXRpYyB2b2lkCi1z ZXRfb2JqZmlsZXNfdXBkYXRlZF9vbl9zb2xpYl9hY3Rpdml0eSAoc3RydWN0 IHNvX2xpc3QgKnNvX2xpc3QpCi17Ci0gIG9iamZpbGVzX3VwZGF0ZWRfcCA9 IDE7ICAvKiBSZWJ1aWxkIHNlY3Rpb24gbWFwIG5leHQgdGltZSB3ZSBuZWVk IGl0LiAgKi8KLX0KLQogdm9pZAogX2luaXRpYWxpemVfb2JqZmlsZXMgKHZv aWQpCiB7CiAgIG9ic2VydmVyX2F0dGFjaF9leGVjdXRhYmxlX2NoYW5nZWQg KHNldF9vYmpmaWxlc191cGRhdGVkX29uX2V4ZV9jaGFuZ2UpOwotICBvYnNl cnZlcl9hdHRhY2hfc29saWJfbG9hZGVkIChzZXRfb2JqZmlsZXNfdXBkYXRl ZF9vbl9zb2xpYl9hY3Rpdml0eSk7Ci0gIG9ic2VydmVyX2F0dGFjaF9zb2xp Yl91bmxvYWRlZCAoc2V0X29iamZpbGVzX3VwZGF0ZWRfb25fc29saWJfYWN0 aXZpdHkpOwogfQo= --00163646d5be74c422046f4f4a53--