Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: tromey@redhat.com,  gdb-patches@sourceware.org
Subject: Re: [patch] Speed up find_pc_section
Date: Wed, 22 Jul 2009 18:10:00 -0000	[thread overview]
Message-ID: <200907221840.29588.pedro@codesourcery.com> (raw)
In-Reply-To: <8ac60eac0907221016j410f890ald54ac66c7c3291f9@mail.gmail.com>

On Wednesday 22 July 2009 18:16:06, Paul Pluzhnikov wrote:
> On Wed, Jul 22, 2009 at 9:32 AM, Pedro Alves<pedro@codesourcery.com> wrote:
> 
> > 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_objfile'
> kind of observer.

Would setting objfiles_updated_p from e.g., unlink_objfile work?
Both the map and unlink_objfile/free_objfile are private/implemented in
objfiles.c; if nothing else outside needs the observer, we can avoid
adding it.  Otherwise, a new observer is fine.  (the more transparent
the cache is, the better the design looks, IMHO)

> > 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.

I think so.

> 
> > Given the new_objfile observer, do we still need the exec_changed and
> > solib observers?
> 
> No, I've removed that (new patch attached).

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?  Why would you need to know about
solibs, if without the cache (that is, before the original patch)
we'd just iterate over the objfiles' sections?  That is, the lifetime
of the cache should be at most the same as of the objfiles'
sections, 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)?  allocate_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.

> > Please look around and check that objfile->section_offsets or
> > obj_section_offset isn't being used as an lvalue somewhere where
> > the map cache isn't being flushed.
> 
> I think new_objfile/remove_objfile will take care of any of these.

Okay then.

> Should I revert the find_pc_section patch, work up remove_objfile observer
> patch, then re-apply find_pc_section patch once it's in better shape?

It would be cleaner and easier to review, easier for you (I think),
and better for the archives in the future, IMHO.  But I don't mind
much if a new patch is cooked on top.

-- 
Pedro Alves


  parent reply	other threads:[~2009-07-22 17:40 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-17  7:34 Paul Pluzhnikov
2009-07-17 15:59 ` Paul Pluzhnikov
2009-07-17 16:27 ` Tom Tromey
2009-07-17 17:19   ` Paul Pluzhnikov
2009-07-21 17:57     ` Tom Tromey
2009-07-21 20:51       ` Paul Pluzhnikov
2009-07-21 21:03         ` Tom Tromey
2009-07-22 15:23         ` Pedro Alves
2009-07-22 16:33           ` Tom Tromey
2009-07-22 17:02             ` Paul Pluzhnikov
2009-07-22 17:02               ` Pedro Alves
2009-07-22 17:16                 ` Paul Pluzhnikov
2009-07-22 18:08                   ` Paul Pluzhnikov
2009-07-22 18:10                   ` Pedro Alves [this message]
2009-07-22 18:12                   ` Paul Pluzhnikov
2009-07-22 19:19                     ` Pedro Alves
2009-07-22 19:34                       ` Paul Pluzhnikov
2009-07-22 19:54                         ` Pedro Alves
2009-08-17 21:15                         ` [commit] Fix reread_symbols crash (Re: [patch] Speed up find_pc_section) Ulrich Weigand
2009-08-04 14:22         ` [patch] Speed up find_pc_section Tom Tromey
2009-08-04 15:06           ` Paul Pluzhnikov
2009-08-04 15:38             ` Tom Tromey
     [not found]               ` <8ac60eac0908042358q4d2061d2md3c49cf4aab26398@mail.gmail.com>
     [not found]                 ` <m34osmi5jx.fsf@fleche.redhat.com>
     [not found]                   ` <8ac60eac0908050940we3dc478rd182f4367a650f1b@mail.gmail.com>
     [not found]                     ` <8ac60eac0908052259l7b1c21d1t212991886a5f8b18@mail.gmail.com>
     [not found]                       ` <m3eirofxwh.fsf@fleche.redhat.com>
     [not found]                         ` <8ac60eac0908070030g7500a5ack3fcc81862e2a5b0a@mail.gmail.com>
2009-08-07 23:30                           ` Paul Pluzhnikov
2009-08-09 21:37                             ` Paul Pluzhnikov
2009-08-10 18:09                               ` Tom Tromey
2009-08-10 20:39                                 ` Paul Pluzhnikov
2009-08-17 19:45                               ` Ulrich Weigand
2009-08-17 19:57                                 ` Ulrich Weigand
2009-08-17 22:55                                   ` Paul Pluzhnikov
2009-08-18 13:48                                     ` Ulrich Weigand
2009-08-20 18:03                                       ` Paul Pluzhnikov
2009-08-20 18:39                                         ` Ulrich Weigand
2009-08-20 21:06                                           ` Paul Pluzhnikov
2009-08-20 22:34                                             ` Daniel Jacobowitz
2009-08-21 12:36                                             ` Ulrich Weigand
2009-08-23 23:25                                               ` Paul Pluzhnikov
2009-08-26  7:21                                                 ` Paul Pluzhnikov
2009-08-26 14:37                                                   ` Jan Kratochvil
2009-08-26 14:38                                                     ` Paul Pluzhnikov
2009-08-26 15:17                                                       ` Paul Pluzhnikov
2009-08-26 23:45                                                       ` Jan Kratochvil
2009-08-27  2:56                                                         ` Paul Pluzhnikov
2009-09-02 17:02                                                   ` Paul Pluzhnikov
2009-09-08 18:37                                                     ` What should we do re: "[patch] Speed up find_pc_section" Joel Brobecker
2009-09-08 20:16                                                       ` Paul Pluzhnikov
2009-09-08 21:17                                                         ` Joel Brobecker
2009-09-09  5:58                                                   ` [patch] Speed up find_pc_section Joel Brobecker
2009-09-09  7:56                                                     ` Tristan Gingold
2009-09-09 15:04                                                       ` Joel Brobecker
2009-09-11  7:44                                                         ` Tristan Gingold
2009-09-10 17:36                                                     ` Paul Pluzhnikov
2009-09-10 18:30                                                       ` Joel Brobecker
2009-09-11  1:30                                                         ` Paul Pluzhnikov
2009-09-11  6:51                                                           ` Pierre Muller
2009-09-11  7:29                                                             ` Paul Pluzhnikov
2009-09-11  7:40                                                               ` Mark Kettenis
2009-09-11  7:51                                                                 ` Paul Pluzhnikov
2009-09-11  7:41                                                               ` Pierre Muller
2009-09-11  8:03                                                                 ` Paul Pluzhnikov
2009-09-11  8:41                                                                   ` Pierre Muller
2009-09-11 17:47                                                                     ` Paul Pluzhnikov
2009-09-11 21:15                                                                       ` Joel Brobecker
2009-09-13 21:47                                                                         ` Paul Pluzhnikov
2009-09-14 16:43                                                                           ` Ulrich Weigand
2009-09-14 17:19                                                                             ` Paul Pluzhnikov
2009-09-14 17:36                                                                               ` Joel Brobecker
2009-09-14 18:10                                                                                 ` Paul Pluzhnikov
2009-09-14 18:21                                                                                   ` Joel Brobecker
2009-09-11 20:51                                                               ` Tom Tromey
2009-09-11 21:04                                                                 ` Paul Pluzhnikov
2009-09-11 21:14                                                                   ` Tom Tromey
2009-09-11  7:53                                                       ` Tristan Gingold
2009-09-11  8:33                                                         ` Paul Pluzhnikov
2009-09-11  8:39                                                           ` Tristan Gingold
2009-09-11 16:23                                                             ` Paul Pluzhnikov
2009-09-09  5:39                                                 ` Joel Brobecker
2009-09-10 16:18                                                   ` Paul Pluzhnikov
2009-09-11 21:06                                                     ` Joel Brobecker
2009-09-14 16:41                                                     ` Ulrich Weigand
2009-08-18 18:18                                     ` Michael Snyder
2009-07-17 18:56 ` Paul Pluzhnikov
2009-07-21  3:34   ` Paul Pluzhnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200907221840.29588.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ppluzhnikov@google.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox