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

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 06 October 2011 23:05:45, Doug Evans wrote:

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

Well, at least things should work the same as before, which IMO
is good thing as it makes this change an optimization only.

> Blech, I forgot one bit of cleanup.
> Revised patch attached.

Still breaks activating thread_db when debugging cores of
static executables.

$ ./gdb -nx -q ./testsuite/gdb.threads/staticthreads 
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads...done.
(gdb) start
Temporary breakpoint 1 at 0x400548: file ../../../src/gdb/testsuite/gdb.threads/staticthreads.c, line 48.
Starting program: /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe038) at ../../../src/gdb/testsuite/gdb.threads/staticthreads.c:48
48      {
(gdb) gcore core.test
Saved corefile core.test

Before:

$ ./gdb -nx -q ./testsuite/gdb.threads/staticthreads -c ./core.test 
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads...done.
[New LWP 32418]
[Thread debugging using libthread_db enabled]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Core was generated by `/home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads'.
Program terminated with signal 5, Trace/breakpoint trap.
#0  main (argc=1, argv=0x7fffffffe038) at ../../../src/gdb/testsuite/gdb.threads/staticthreads.c:48
48      {
(gdb) 

After:

$ ./gdb -nx -q ./testsuite/gdb.threads/staticthreads -c ./core.test 
Reading symbols from /home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads...done.
[New LWP 32418]
Core was generated by `/home/pedro/gdb/baseline/build/gdb/testsuite/gdb.threads/staticthreads'.
Program terminated with signal 5, Trace/breakpoint trap.
#0  main (argc=1, argv=0x7fffffffe038) at ../../../src/gdb/testsuite/gdb.threads/staticthreads.c:48
48      {
(gdb) 

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.

-- 
Pedro Alves