From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20316 invoked by alias); 3 Dec 2002 23:58:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20306 invoked from network); 3 Dec 2002 23:58:04 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 3 Dec 2002 23:58:04 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18JOo1-0006Jl-00; Tue, 03 Dec 2002 19:58:29 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18JMvx-0002BX-00; Tue, 03 Dec 2002 18:58:33 -0500 Date: Tue, 03 Dec 2002 15:58:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Paul Mundt , gdb@sources.redhat.com Subject: Re: SIG32/SIGTRAP issues Message-ID: <20021203235833.GA8335@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Paul Mundt , gdb@sources.redhat.com References: <1038959780.11721.54.camel@Origin> <20021203232457.GA5980@nevyn.them.org> <3DED43BE.50401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DED43BE.50401@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00061.txt.bz2 On Tue, Dec 03, 2002 at 06:52:30PM -0500, Andrew Cagney wrote: > > > >Funny, no one reports this for months and this is the third report I've > >seen in a week... At the bottom of this message is a workaround. I'm > >not proposing it be committed, since it's obviously pretty gross. The > >real issue is the concept of thread_stratum and core_stratum as > >separate from process_stratum. I don't think it's appropriate - if we > >are debugging a core and process at the same time this isn't how it > >should work. This ties in to all the make-targets-a-real-stack thing - > >I'm not entirely convinced on that score either. > > GDB Speak :-) `An inferior stack', separate to the stratum. Having > implemented the idea, I'm pretty much convinced it's the correct > approach (although, as you demonstrate, not absolutly necessary). Hrm, interesting. A stack doesn't seem logical for that, just support for multiple targets... pull one out when you want it. That could be adapted to solve this problem. Let's see the code :) === HJ, I'm pretty sure your patch won't work right in this case: # gdb static-app corefile (gdb) run There will be no new call to the objfile hook, and no new pushes, and thread-db won't load. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer