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

Attachment: gdb-111006-libthread-db-2.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]