From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22034 invoked by alias); 13 Mar 2002 17:50:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21921 invoked from network); 13 Mar 2002 17:50:28 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Mar 2002 17:50:28 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16lCtW-0003nQ-00 for ; Wed, 13 Mar 2002 12:50:34 -0500 Date: Wed, 13 Mar 2002 09:50:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?] Message-ID: <20020313125034.B14483@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00195.txt.bz2 Does anyone have a comment on this patch? It fixes thread_db for statically linked binaries (which I broke), and I think it's legitimate. ----- Forwarded message from "H . J . Lu" ----- Date: Thu, 7 Mar 2002 15:08:04 -0800 From: "H . J . Lu" Subject: Re: Does gdb 5.2 work with statically linked thread application under Linux? To: GDB On Thu, Mar 07, 2002 at 05:02:07PM -0500, Daniel Jacobowitz wrote: > On Thu, Mar 07, 2002 at 01:39:28PM -0800, H . J . Lu wrote: > > On Thu, Mar 07, 2002 at 02:48:41AM -0500, Daniel Jacobowitz wrote: > > > On Wed, Mar 06, 2002 at 11:30:50PM -0800, H . J . Lu wrote: > > > > Does gdb 5.2 work with statically linked thread application under > > > > Linux? It doesn't work for me at all. It doesn't know any thread. > > > > I have a patch which works for gdb 5.1. Now it doesn't work for 5.2 > > > > anymore. > > > > > > My fault, I think. > > > > > > The problem is that in a dynamically linked binary > > > thread_db_new_objfile will be called for every library is loaded. At > > > this point current_target is "child", so target_has_execution is true. > > > But with a static binary, the first time the function is called objfile > > > is NULL, and the second time current_target is "exec" (which has > > > target_has_execution set false). > > > > > > Perhaps target_has_execution was not the right check after all, if > > > "exec" has it set false (which makes fairly little sense to me...) or > > > perhaps we need to call the hook again later. Michael, any idea? > > > > > > > What is the problem if "|| !target_has_execution" is removed? I removed > > it. Gdb now works on statically linked thread application as well as > > core file. Did I miss soemthing? > > Try running 'info threads' on the corefile of a multithreaded > application. Recent Linux kernels will allow them to dump core. > > I've also got a patch to put multiple threads into the corefile. > There's a sample corefile at: > http://crack.them.org/~drow/mtc2.tar.gz > > > Without !target_has_execution, we try to use lin-lwp on the coredump. > That works very badly. > This patch works for me. H.J. ---- 2002-03-07 H.J. Lu (hjl@gnu.org) * target.h (target_corefile_hook): New prototype. * target.c (target_corefile_hook): New. * corelow.c (core_open): Call target_corefile_hook if needed. * thread-db.c (thread_db_corefile): New. (thread_db_new_objfile): Don't check target_has_execution. (_initialize_thread_db): Set target_corefile_hook to thread_db_corefile. --- gdb/corelow.c.static Wed Mar 6 22:30:49 2002 +++ gdb/corelow.c Thu Mar 7 15:01:41 2002 @@ -303,6 +303,9 @@ core_open (char *filename, int from_tty) filename, bfd_errmsg (bfd_get_error ())); } + if (target_corefile_hook) + target_corefile_hook (); + /* Looks semi-reasonable. Toss the old core file and work on the new. */ discard_cleanups (old_chain); /* Don't free filename any more */ --- gdb/target.c.static Wed Mar 6 22:31:31 2002 +++ gdb/target.c Thu Mar 7 14:54:50 2002 @@ -38,6 +38,8 @@ extern int errno; +void (*target_corefile_hook) (void); + static void target_info (char *, int); static void cleanup_target (struct target_ops *); --- gdb/target.h.static Wed Mar 6 22:31:31 2002 +++ gdb/target.h Thu Mar 7 14:54:38 2002 @@ -985,6 +985,8 @@ extern char *normal_pid_to_str (ptid_t p extern void (*target_new_objfile_hook) (struct objfile *); +extern void (*target_corefile_hook) (void); + #ifndef target_pid_or_tid_to_str #define target_pid_or_tid_to_str(ID) \ target_pid_to_str (ID) --- gdb/thread-db.c.static Wed Mar 6 22:31:31 2002 +++ gdb/thread-db.c Thu Mar 7 14:59:09 2002 @@ -479,13 +479,25 @@ disable_thread_signals (void) } static void +thread_db_corefile (void) +{ + if (using_thread_db) + { + /* If the thread_db target is active, deactivate it now. */ + gdb_assert (proc_handle.pid == 0); + unpush_target (&thread_db_ops); + using_thread_db = 0; + } + + keep_thread_db = 0; +} + +static void thread_db_new_objfile (struct objfile *objfile) { td_err_e err; - /* Don't attempt to use thread_db on targets which can not run - (core files). */ - if (objfile == NULL || !target_has_execution) + if (objfile == NULL) { /* All symbols have been discarded. If the thread_db target is active, deactivate it now. */ @@ -1040,5 +1052,6 @@ _initialize_thread_db (void) /* Add ourselves to objfile event chain. */ target_new_objfile_chain = target_new_objfile_hook; target_new_objfile_hook = thread_db_new_objfile; + target_corefile_hook = thread_db_corefile; } } ----- End forwarded message ----- -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer