From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 713 invoked by alias); 16 Mar 2002 04:48:10 -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 472 invoked from network); 16 Mar 2002 04:48:02 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 16 Mar 2002 04:48:02 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 88F0F3D98; Fri, 15 Mar 2002 23:47:57 -0500 (EST) Message-ID: <3C92CE7D.5060300@cygnus.com> Date: Fri, 15 Mar 2002 20:48: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: Daniel Jacobowitz 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?] References: <20020313125034.B14483@nevyn.them.org> <20020313095415.B9484@lucon.org> <3C92B31A.3000702@cygnus.com> <20020315222045.A3612@nevyn.them.org> <3C92C275.5020304@cygnus.com> <20020315231605.A5470@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00259.txt.bz2 >> If you don't want thread-db trying to push its self on top of a core >> stratum, why not check for core and ignore the event? What about this? >> (GNU/Linux doesn't want the thread-db pushing its self on top of a CORE >> stratum but other OS's do (with an N:M thread:lwp mapping for instance). > > > I can't find the precise message any more, but I believe we'd decided > thread-db and core files was a bad idea without more work on thread-db. > In any case, Michael Snyder said to me: It isn't thread-db that needs the work, it is the target stack/stratum/sandwich :-) >>>> Umm... I had to think about this, but no. You can't debug a corefile >>>> until you kill or detach from the process that you're already >>>> debugging. >>>> When you kill or detach, that ought to take care of the unpush. Two reasons: Target stratum (thread, process, ...) is limited to only one instance as most of each target's state is in static data The target stratum is one dimentional (for want of a better phrase). It isn't possible to have: process: thread-db -> remote -> ... core: thread-db -> corefile -> ... > Maybe it should, but (probably because of when thread-db gets pushed?) > it definitely does not. Perhaps that is the real bug? > > Should thread_db_detach call unpush_target? Some targets seem to like > that model, some don't. The way we load our target in new_objfile_hook > always struck me as somewhat gross. I suspect, for the moment, it is the best thing we have. new_objfile_hook is the only ``new symbol file'' event available. Andrew