Forcing lldb to refresh process state

Hi,
Is there any way to force lldb to refresh it’s internal record of debuggee process state (as if it had just received a stop event)? I want to send a custom command to remote gdb process stub (via process plugin packet send). This works, but if the command alters debuggee state, lldb won’t know about it.

No, there hasn't been a need for this.

What commands are you planning to send? Or equivalently, how much state are you expecting to change?

Jim

I'm trying to reverse-step. So I think I'd need to refresh all thread states?

If you do a reverse step it actually should send a process resumed and a process stopped event.

It does send ‘$T05…’ in response, but it looks like lldb does not analyze responses to manually sent packets.

You need to send some sort of continue through the GDB remote interface. The only way to get a $T packet back is in response to a “?” packet or to a “vCont” or other continue or step packet.

Perhaps a manual packet that tells your remote server that the next “s” packet is a reverse step, then run the lldb command “si”.

It would be simpler, from a packet log analysis standpoint, if you weren’t stopped at a breakpoint location when you did this.

There is a standard for reverse stepping where the GDB remote protocol was extended to do the reverse stepping. See:

Look for "reverse" in the text. They added "bc" for reverse continue and "bs" for reverse step. We should be using these if possible.

Yeah, this `bs` + `stepi` dance is the only workaround I found so far.

This isn’t a work around right? You should be triggering your reverse step or reverse continue using a “process reverse-continue” or “thread reverse-step” right? If you do this, everything will just work. There should be no way this happens automagically without user interaction. Am I missing something?

Wait a second... As far as I know, LLDB itself does not support
reverse-debugging (unless I missed something in a major way). So there is
no "process reverse-continue" command, is there?

I am not talking about adding proper reverse-debugging to lldb. All I want
to do is to hack together a script that emulates "process reverse-continue"
in cases when remote target happens to support it. I'm sending commands
directly to remote gdb via `process plugin packet send bs`, but that leaves
lldb out of the loop because it does not analyze the response packet.

Not sure why we wouldn’t add it? It would be easy. The default implementation would return an unsupported error, and the ProcessGDBRemote would just pass the packets down.

Anything that internally calls lldb_private::Process::Flush() should do the trick as long as it actually causes it to get called. So:

target modules add
target modules load
target symbols add

They flush the process state because if you add a module or symbols or move a module around in memory we need to redo all stack traces. So you will need to do one of these as a work around and the command must succeed. I would suggest using:

(lldb) target modules add …

where … is the path of a shared library or executable that isn’t in your target.