This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Linux Checkpoint/Restart, take 2
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