RFC: Debugging interface (gdb)

Chris Jones jones.chris.g at gmail.com
Wed May 22 22:09:13 PDT 2013

On Wed, May 22, 2013 at 7:51 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> I'm pretty sure ptrace stepi will update the instructions-retired counter
> correctly. We'll see...

I'm uneasy about several interactions, but I share your "pretty sure"
sentiment ;).

> Handling the case where a signal needs to be delivered at that instruction
> sounds tricky.

AFAICT this is the same problem as knowing to context-switch at insn i
while stepping.

> No idea what to do for breakpoints. Theoretically, inserting int3
> breakpoints could cause divergence. Probably doesn't matter. Same is true
> for debug registers I suppose, but matters even less. I guess just using
> int3s is simple and gives you unlimited breakpoints --- and we don't have
> to worry about threads racing.

Yeah, I lean toward SW-only breakpoints too.  I haven't thought of
anything problematic yet, but I also haven't thought very hard yet.

> In my mind I would like gdb support to be good enough to be useful, but
> rather than making it really great it might be better to invest in stuff
> like checkpointing and then Chronicle/Chronomancer style
> recording/debugging of segments of the trace. My ultimate goal is to have
> something a lot better than anything gdb (even with reverse execution) can
> provide :-).

Yep, agreed again.  Before we can really do reverse-* anything, gdb or
chronicle/chronomancer, we're going to need some fancy new technology like
checkpointing.  So we can't really think of those things before the new
tech.  Down the road though, I could see gdb reverse-continue playing
really well with something like chronicle/chronomancer, to quickly zoom in
on the segment you want to hyper-record.  (Need a better name than that


> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq
> qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq
> qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q
> qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20130522/72630bce/attachment.html>

More information about the rr-dev mailing list