This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Jul 22, 2009 at 10:16 AM, Paul Pluzhnikov<ppluzhnikov@google.com> 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. 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<pedro@codesourcery.com> wrote: >> 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? 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)? ?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. 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. ?But 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, -- Paul Pluzhnikov 2009-07-22 Paul Pluzhnikov <ppluzhnikov@google.com> * objfiles.c (allocate_objfile): Must rebuild section map. (free_objfile, objfile_relocate): Likewise. (set_objfiles_updated_on_solib_activity): Remove. (_initialize_objfiles): Adjust.
Attachment:
gdb-find_pc_section-20090722-3.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |