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 Fri, Oct 7, 2011 at 4:09 AM, Pedro Alves <pedro@codesourcery.com> wrote: > Well, at least things should work the same as before, which IMO > is good thing as it makes this change an optimization only. That's the intent. >> Blech, I forgot one bit of cleanup. >> Revised patch attached. > > Still breaks activating thread_db when debugging cores of > static executables. Used wrong sandbox for the before case, sigh. [...] > Did you try this suggestion?: > >> 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. It turns out things work today accidentally. At least I doubt it's by design. :-) My previous patch didn't work because it skipped calling check_for_thread_db when the new_objfile observer was called for vsyscall (which incidentally is called by the inferior_created observer for vsyscall, heh). [Which explains why it didn't surprise me when my before-test failed, that's a pretty unexpected way to load libthread_db.] How about this. 2011-10-09 Doug Evans <dje@google.com> * linux-thread-db.c (thread_db_new_objfile): Only try to load libthread_db when we load libpthread. (thread_db_inferior_created): New function. (_initialize_thread_db): Attach inferior_created observer.
Attachment:
gdb-111009-libthread-db-4.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] |