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

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]