From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5942 invoked by alias); 13 Sep 2006 00:27:24 -0000 Received: (qmail 5934 invoked by uid 22791); 13 Sep 2006 00:27:23 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Sep 2006 00:27:17 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 0C56748CC19 for ; Tue, 12 Sep 2006 20:27:15 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00562-01-2 for ; Tue, 12 Sep 2006 20:27:14 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 5275E48CBD6 for ; Tue, 12 Sep 2006 20:27:14 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2AB2047F00; Tue, 12 Sep 2006 17:27:13 -0700 (PDT) Date: Wed, 13 Sep 2006 00:27:00 -0000 From: Joel Brobecker To: gdb@sources.redhat.com Subject: (linux/threads) Interesting side-effect of "auto-solib-add 0" Message-ID: <20060913002712.GF24293@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00065.txt.bz2 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