From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12506 invoked by alias); 21 May 2010 16:01:47 -0000 Received: (qmail 12273 invoked by uid 22791); 21 May 2010 16:01:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 May 2010 16:01:39 +0000 Received: (qmail 11506 invoked from network); 21 May 2010 16:01:38 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 May 2010 16:01:38 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Forbid run with a core file loaded Date: Fri, 21 May 2010 16:08:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; ) Cc: Mark Kettenis , jan.kratochvil@redhat.com References: <20100521134718.GA17157@host0.dyn.jankratochvil.net> <201005211605.01345.pedro@codesourcery.com> <201005211537.o4LFbiGi009032@glazunov.sibelius.xs4all.nl> In-Reply-To: <201005211537.o4LFbiGi009032@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201005211701.30388.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00495.txt.bz2 On Friday 21 May 2010 16:37:44, Mark Kettenis wrote: > > From: Pedro Alves > > Date: Fri, 21 May 2010 16:05:01 +0100 > > > > On Friday 21 May 2010 15:47:07, Mark Kettenis wrote: > > > I often start gdb and load a core file to investigate a problem. Then > > > I set a breakpoint at some point before the crash and run the program > > > again. This used to work just fine. > > > > If you're refering to getting back to debugging the core when > > the running program exits, it never worked correctly. You'd get a better > > experience if your core had no threads at all. If you didn't trip on an > > assertion, and weird problems for having gdb consult things in the process > > target, then the core target (which wouldn't make sense for the running > > program), then the exec target, when you'd get back to debugging > > the core, you'd find your threads had disapeared. That's just an example. > > Here are others . > > I don't think I go back again to the core file very often, but it > seems to work fine with gdb 6.3 for a single-threaded process. Yes, that's the case I said would most likely work for the basic things in the other mail. > > > For this to work correctly, we'd need to rethink the single target-stack, > > into maybe multiple target stacks, or something else radically different. > > Dunno. Isn't it enough to pop the core layer when you run? Errr, if you pop it, then what are you getting back to? I was talking about a design that allows correct debugging of the process, while still debugging the core. poping the core layer, clearing all current inferior state, and later reload the core works around it, of course... but that's not the same as leaving the core target on that stack, pushing the process statum, allowing debugging it, and once that is poped, assume the core target and its inferior are in a sane gdb internal state, which is what gdb assumes today. -- Pedro Alves