From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11582 invoked by alias); 16 Mar 2002 03:20:38 -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 11483 invoked from network); 16 Mar 2002 03:20:35 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 16 Mar 2002 03:20:35 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16m4kP-00010T-00; Fri, 15 Mar 2002 22:20:45 -0500 Date: Fri, 15 Mar 2002 19:20:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: "H . J . Lu" , gdb-patches@sources.redhat.com Subject: Re: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?] Message-ID: <20020315222045.A3612@nevyn.them.org> Mail-Followup-To: Andrew Cagney , "H . J . Lu" , gdb-patches@sources.redhat.com References: <20020313125034.B14483@nevyn.them.org> <20020313095415.B9484@lucon.org> <3C92B31A.3000702@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C92B31A.3000702@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00254.txt.bz2 On Fri, Mar 15, 2002 at 09:51:06PM -0500, Andrew Cagney wrote: > >--- 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/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) > > } > > > The below just feels wrong. The hook is pulling the thread stratum off > the stack when, as far as I can tell, there is no compelling reason for > doing this. > > ``hey'' something has happened. At this point, nothing has happened. What do you mean by "there is no compelling reason"? Or how should this be handled? The issue is that we do not want thread_db to be used at all for corefiles; we established that last time I touched this code, I just solved the problem wrong. Once again, it doesn't work as-is, and unpushing matches the way the code was trying to behave. > > 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; > >+} > > It is possible to have thread, process and core-file stratum > simultaneously. Changing the core-file shouldn't quietly zap the thread > stratum on top of the process stratum. > > I suspect the real problem here is a limitation in the current target > frame work - it doesn't accomodate having two instances of the thread > stratum active (one for the process and one for the core file) active at > the same time :-( The target stack is almost entirely undocumented, unfortunately. But from this it seems that changing targets should change the stack completely; be it a multi-arch thing or a local/remote thing (we've seen thread_db do the same thing in that case) or a local/core thing. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer