From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17237 invoked by alias); 16 Mar 2002 02:51:13 -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 17163 invoked from network); 16 Mar 2002 02:51:10 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 16 Mar 2002 02:51:10 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C3E3C3D70; Fri, 15 Mar 2002 21:51:06 -0500 (EST) Message-ID: <3C92B31A.3000702@cygnus.com> Date: Fri, 15 Mar 2002 18:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: "H . J . Lu" Cc: gdb-patches@sources.redhat.com Subject: Re: [hjl@lucon.org: Re: Does gdb 5.2 work with statically linked thread application under Linux?] References: <20020313125034.B14483@nevyn.them.org> <20020313095415.B9484@lucon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00252.txt.bz2 > --- 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. > 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 :-( Andrew