From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28681 invoked by alias); 4 Dec 2002 00:09:25 -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 28674 invoked from network); 4 Dec 2002 00:09:24 -0000 Received: from unknown (HELO rwcrmhc52.attbi.com) (216.148.227.88) by sources.redhat.com with SMTP; 4 Dec 2002 00:09:24 -0000 Received: from lucon.org (12-234-88-146.client.attbi.com[12.234.88.146]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <20021204000924052002cjk0e>; Wed, 4 Dec 2002 00:09:24 +0000 Received: by lucon.org (Postfix, from userid 1000) id 14EFB2C6AC; Tue, 3 Dec 2002 16:09:21 -0800 (PST) Date: Tue, 03 Dec 2002 16:09:00 -0000 From: "H. J. Lu" To: Andrew Cagney , Paul Mundt , gdb@sources.redhat.com Subject: Re: SIG32/SIGTRAP issues Message-ID: <20021203160921.B9042@lucon.org> References: <1038959780.11721.54.camel@Origin> <20021203232457.GA5980@nevyn.them.org> <3DED43BE.50401@redhat.com> <20021203235833.GA8335@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021203235833.GA8335@nevyn.them.org>; from drow@mvista.com on Tue, Dec 03, 2002 at 06:58:33PM -0500 X-SW-Source: 2002-12/txt/msg00063.txt.bz2 On Tue, Dec 03, 2002 at 06:58:33PM -0500, Daniel Jacobowitz wrote: > 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. > No, it is not perfect. H.J.