Re: [RFA] Linux Checkpoint/Restart, take 2

[Daniel Jacobowitz <drow@false.org>]

On Fri, Dec 23, 2005 at 11:45:07AM -0800, Michael Snyder wrote:
> >The implementation is almost entirely contained in linux-nat.c and
> >linux-fork.c.  Maybe we should discuss the target vector interface to
> >this before it goes in?  For instance, there's no reason a Linux-hosted
> >gdbserver shouldn't be able to implement exactly the same thing.
> 
> No, and I fervently hope that other targets will implement something
> like it too (I may work on some of them).  However, the current patch
> is for native linux only, and does not *prevent* any other targets
> from implementing checkpoints.  That's why I defined all the commands
> in a linux-only module.
> 
> I'd like to check in what I have now, and do the target-vectorization
> as needed.  Having this implementation to play with will help us define
> what target vectors we need.

Well, OK.

> >I totally don't understand what the clobber_regs bits are for. You're
> >using fork as a backend; each saved fork had better have both its own
> >registers, right?  Is it just a GDB internal bookkeeping thing?  If so,
> >why do you need to do it for saved forks and not for the existing
> >follow-fork bits?
> 
> No, it actually was needed, and it's a little obscure, so I'll
> give you an explanation as a footnote, down below.   ;-)

Now I'm dying of curiousity.  No footnote?

> >Why have we got both "info checkpoints" and "info forks"?  Right now
> >they're aliases to each other and some of the fork commands redirect
> >you to info checkpoints.
> 
> Well, because sometimes you'll be using checkpoints, and sometimes
> you'll be debugging forks.  The underlying functionality is identical,
> but users aren't gonna know or care about that -- from their point
> of view, they are two entirely different tasks.

Hmm.  That does make some sense.

> >How do you feel about calling this "switch-fork"?  If I see a debugger
> >command named "fork", my first reaction is going to be that it's an
> >active command (creates a fork) instead of a passive one (focuses our
> >attention on a different one).
> 
> I see what you mean -- I was just basing it off of the "thread"
> command by analogy.  I'm not attached to it, though, and would be
> happy to hear what others think.

Me too.

> >Getting at the PC this way is probably going to bite you; the two that
> >jump out at me are you've bypassed ADDR_BITS_REMOVE, and you're forcing
> >unsigned (which is wrong for MIPS and might result in some strange
> >looking PCs).  No, I don't have a better idea.
> 
> OK, well... since I have a full-fledged copy of the regcache,
> there *must* be a legitimate way to do it.  If not, there should
> be, and maybe I'll have to add it.   ;-)

I think you've hit it on the head - there should be, and you may have
to add it.  This normally passes through gdbarch_read_pc, whose
interface is perhaps due for an overhaul to the modern age of regcaches
(and/or frames?).

-- 
Daniel Jacobowitz
CodeSourcery, LLC