Re: [patch] Forbid run with a core file loaded

[Pedro Alves <pedro@codesourcery.com>]

On Friday 21 May 2010 16:37:44, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > 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 <http://sourceware.org/ml/gdb-patches/2008-08/msg00290.html>.
> 
> 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