From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22015 invoked by alias); 16 Mar 2002 04:16:01 -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 21950 invoked from network); 16 Mar 2002 04:15:53 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 16 Mar 2002 04:15:53 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16m5bx-0001ap-00; Fri, 15 Mar 2002 23:16:05 -0500 Date: Fri, 15 Mar 2002 20:16: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: <20020315231605.A5470@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> <20020315222045.A3612@nevyn.them.org> <3C92C275.5020304@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C92C275.5020304@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00258.txt.bz2 On Fri, Mar 15, 2002 at 10:56:37PM -0500, Andrew Cagney wrote: > >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. > > I'd expect the thread stratum to be unpushed at the same time as the > stratum below it is also unpushed. In the code above, nothing is being > unpushed so I can't see a reason to unpush the thread-db. > > A few lines below the call-out is an unpush() call. Shouldn't that > unpush any stratum directly dependant on it? It unpushes only core_ops. core_ops isn't pushed at this point, we weren't debugging a corefile before. > 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? > > (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: >>> 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. 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. > Most of GDB is almost entirely undocumented :-) However, the user guide > does describe the external interface to this feature: > http://sources.redhat.com/gdb/current/onlinedocs/gdb_16.html#SEC130 Yep, it's implementation details that worry me. > If I understand what you're saying correctly, yes. Unfortunatly it > isn't implemented that way. It should be pretty easy, I'd think - call unpush at the appropriate time in detach... > Search for the words ``squashed sandwich'' in the mail archives :-) No matches :P -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer