robert at ocallahan.org
Thu Feb 23 19:26:53 UTC 2017
On Fri, Feb 24, 2017 at 2:24 AM, Juraj <juraj.orsulic at fer.hr> wrote:
> On Wed, Feb 22, 2017 at 9:01 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>> That could be implemented, but it would be quite a lot of work and
>> it's not a priority for me at this time, nor do I know of any other rr
>> contributors who are currently interested in it. If someone wanted to
>> take it on, I'd be happy to provide some guidance.
> Oh, darn. Well, it would be nice if it got added to the wishlist :)
> Perhaps I could open an issue on Github?
>> Is there a reason why you need to restart the debugging session from
>> scratch multiple times?
> Not a particularly smart reason, just that the application that I am
> trying to debug is quite complex (it's Google's Cartographer SLAM) and
> I'll need to get very deeply acquainted with the source code to find
> the issue. It's probably going to take a week or two. However, in the
> meantime, I have to take my laptop home with me and shut it down. This
> means that I have to wait for the execution to reach this point every
> time I get back to debugging this.
> Even if I suspended the laptop each time, or kept the rr debug server
> in a VM which I could suspend, detaching from the rr server causes it
> to shut down, which means I can't close my IDE. Is there a way to keep
> the rr server running after detaching?
I guess someone could implement a command to detach from the debug
server and let it wait for a reattach. That wouldn't be too hard. It
couldn't be the default but there could be a command-line option to
trigger that mode.
>> `rr gdbinit` outputs the script file and might be what you need here.
> Great! I got it working with CLion 2017.1. I had to remove the
> python-interactive version checking part because they currently have
> some problems with executing python-interactive.
Is that just a CLion issue or should we change rr somehow?
> One more other thing. I am trying to rewind to a certain event. When
> debugging from a standard gdb console, I can connect using target
> extended-remote, where the run command is supported, and I can rewind
> to the event by calling run <event>. However, CLion stubbornly wants
> to use the remote target (they don't have support for extended-remote
> yet), which doesn't have the run command. I was able to fool it by
> redirecting "target remote" to "target extended-temote" in my
> define target remote
> target extended-remote $arg0
> However, it senses that the program has been stopped when I call run
> <event> from the gdb console in the IDE, and terminates the gdb
> session. Since the rr server quits when the connection has been
> detached, this means that I can't use rewinding to event from inside
> CLion. Reverse execution using breakpoints works, but this means that
> I have to use e.g. conditional breakpoints to go back 50 iterations in
> a loop. It's much easier to just restart to the appropriate event.
> This is one piece I'm missing to be able to fully utilize rr in CLion
I think the right solution here might be a special rr command to go to
a specific event number by issuing a special command that sets a
breakpoint at that event number and then continuing in the correct
direction. I don't think that would be very hard to do at this point,
at least if you don't mind stopping if a regular breakpoint/watchpoint
is hit along the way, and you stay in the same process.
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
More information about the rr-dev