From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24592 invoked by alias); 16 Mar 2002 03:56:51 -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 24523 invoked from network); 16 Mar 2002 03:56:50 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 16 Mar 2002 03:56:50 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 639373D98; Fri, 15 Mar 2002 22:56:37 -0500 (EST) Message-ID: <3C92C275.5020304@cygnus.com> Date: Fri, 15 Mar 2002 19:56: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00256.txt.bz2 > 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? 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). > 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. 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 If I understand what you're saying correctly, yes. Unfortunatly it isn't implemented that way. Search for the words ``squashed sandwich'' in the mail archives :-) Andrew