(linux/threads) Interesting side-effect of "auto-solib-add 0"

[Joel Brobecker <brobecker@adacore.com>]

Hello,

One of our customers noticed that when you set auto-solib-add to off
and then start your program, GDB usually breaks down like so:

    (gdb) c
    Continuing.
    
    Program terminated with signal SIGTRAP, Trace/breakpoint trap.
    The program no longer exists.

This is on x86-linux.

The important clue here is that the program is using threads, and
that turning off auto-solib-add causes GDB to not push the thread
support module.

I did my analysis with a debugger derived from gdb-6.4. With the
current GDB from CVS, the errors are not so obvious - at least
I can't seem to reproduce them. But I did double-check that GDB
indeed doesn't start the thread module (by checking with another
debugger the value of "current_target") either.

 From what I can tell, the thread support is pushed by check_for_thread_db
which is called (through several calls) by solib_read_symbols, which
itself is called by solib_add:

    for (gdb = so_list_head; gdb; gdb = gdb->next)
      if (! pattern || re_exec (gdb->so_name))
        {
          any_matches = 1;
          if (readsyms && solib_read_symbols (gdb, from_tty))
            loaded_any_symbols = 1;
        }

The call to check_for_thread_db occurs through a hook:

        /* Call predecessor on chain, if any.  */
        if (remote_new_objfile_chain != 0 &&
            remote_desc == 0)
          remote_new_objfile_chain (objfile);

Which is set as follow in linux-thread-db.c:

        /* Add ourselves to objfile event chain.  */
        target_new_objfile_chain = deprecated_target_new_objfile_hook;
        deprecated_target_new_objfile_hook = thread_db_new_objfile;

and remote.c:

        /* Hook into new objfile notification.  */
        remote_new_objfile_chain = deprecated_target_new_objfile_hook;
        deprecated_target_new_objfile_hook  = remote_new_objfile;

(ugh! another candidate for a new observer???)

So basically, the linux thread layer hooks itself up to the objfile
creation callback. But unfortunately for us, the objfile for
libpthread.so does not get created since we turned auto-solib-add off,
the hook doesn't get called, and as a result, thread support stays off.

It seems to me that we should be able to fix this by adding an observer
of the `solib_loaded' event to replace the hook that linux-thread-db
installed. I actually gave it a try, using the sources from CVS, and
found out something surprising: Although the solib_loaded observer
I just created gets called as expected, the linux thread layers does
not detect that threads are in use:

        /* Now attempt to open a connection to the thread library.  */
        err = td_ta_new_p (&proc_handle, &thread_agent);
        switch (err)
          {
          case TD_NOLIBTHREAD:
            /* No thread library was detected.  */
            break;

For some reason that I cannot understand, "td_ta_new" doesn't detect
thread usage if this function is called from the observer.

I made another experiment: Still with the old hook deactivated, I added
the following loop at the end of "solib_add", which basically causes
a second round of notifications after solib_add had time to do its
thing:

        so = so_list_head;
        while (so != NULL)
          {
            observer_notify_solib_loaded (so);
            so = so->next;
          }

I first did a run with "auto-solib-add" activated (unchanged), and
linux-thread-db.c DID detect thread usage. I then turned off
auto-solib-add, and this time thread usages was NOT detected.

The only difference I can see between the two runs is that symbols
are read in one case, and not read in the other case. Is libthread_db.so
dependent on having the symbol table being loaded or something of that
sort? Any idea as to using the solib_loaded observer didn't work?

Thanks,
-- 
Joel