This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Only try to load libthread_db when we load libpthread.
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