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 Thu, Oct 6, 2011 at 2:55 PM, Doug Evans <dje@google.com> wrote: > > On Thu, Oct 6, 2011 at 1:25 PM, Pedro Alves <pedro@codesourcery.com> wrote: > > > > On Thursday 06 October 2011 21:08:08, Doug Evans wrote: > > > On Thu, Oct 6, 2011 at 12:56 PM, Pedro Alves <pedro@codesourcery.com> wrote: > > > > > > > > On Thursday 06 October 2011 12:22:24, Pedro Alves wrote: > > > > > On Wednesday 05 October 2011 19:27:05, Doug Evans wrote: > > > > > > 2011-10-05 ?Doug Evans ?<dje@google.com> > > > > > > > > > > > > ? ? ? ? * linux-thread-db.c (thread_db_new_objfile): Only try to load > > > > > > ? ? ? ? libthread_db when we load libpthread. > > > > > > > > > > Makes sense to me. > > > > > > > > > > > No regressions in amd64-linux, > > > > > > but I can imagine it misses some cases. > > > > > > > > > > Yeah. ?I think we'll no longer activate thread_db when debugging core > > > > > files of static executables (e.g., a core of gdb.threads/staticthreads). > > > > > It works with live debugging since we call check_for_thread_db > > > > > from linux_child_post_attach/linux_child_post_startup_inferior. > > > > > Maybe moving that to an inferior_created observer in > > > > > linux-thread-db.c would work. > > > > > > > > And all the talk about executables made me realize something else. ?:-) > > > > > > > > For static threaded executables, we'll want to check for thread > > > > db when the symbols of the main executable are (re)loaded too. > > > > I don't recall off hand if there's a flag in the objfile to > > > > know that it's from the main executable though. > > > > > > In what scenario? > > > [what would the user type?] > > > > (gdb) file wrong_executable > > (gdb) attach PID or core-file core.1234 > > whooops! > > (gdb) file right_executable > > What would the user expect to be able to do next? > I ask because I played with it, and things don't necessarily work, > e.g. if wrong_executable didn't have libpthread. > Perhaps more smarts could be added to file to make this work, or maybe > a new command could be added to (effectively) reattach so that the > initialization that attach does was redone (in case one is > uncomfortable with having file do that. ?Though I think commands > shouldn't try to do too much. ?Otherwise one could say "Why doesn't > attach automagically redo the "file" command since if the first "file" > wasn't done it would anyway?" ?Maybe attach should at least warn the > user though). > > Anyways, I think checking for the main symbol file is reasonable (even > if more work is needed), so how about this? > > 2011-10-06 ?Doug Evans ?<dje@google.com> > > ? ? ? ?* linux-thread-db.c (thread_db_new_objfile): Only try to load > ? ? ? ?libthread_db when we load libpthread or the main symbol file. > ? ? ? ?* objfiles.h (OBJF_MAINLINE): Define. > ? ? ? ?* symfile.c (symbol_file_add_with_addrs_or_offsets): Pass it to > ? ? ? ?allocate_objfile when appropriate. Blech, I forgot one bit of cleanup. Revised patch attached.
Attachment:
gdb-111006-libthread-db-3.patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |