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]

Re: [RFA] Only try to load libthread_db when we load libpthread.


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]