GDB: Connection locks up when `continuing` on halted machine about renode

[pgielda]

This is actually expected behaviour - you're connecting to a stopped emulation ("emulation" is all the interconnected machines). Stopped emulation = no time flow = cores do not execute instructions.

[PiotrZierhoffer]

What you can do is to add an "autostart" parameter to the gdb command:

cpu StartGdbServer 3333 true

This is not encouraged for multicore devices though

[xobs]

When using something like openocd on real hardware, issuing a continue resumes the current core, and in fact openocd will print out an error if the core begins executing on its own. That's obviously not an issue here.

Is the right thing to do to define a gdb script that remaps continue to mon start; continue? Or does the autostart option automatically issue a start whenever gdb issues continue?

A separate issue was that I thought Renode had locked up completely, because I couldn't break into GDB at all, even if I disconnected and reconnected it.

[pgielda]

real hardware is always clocked. You could compare your case with a situation when you have a cpu that is clocked by an external oscillator and you've unsoldered it.

Having said that I think that what @PiotrZierhoffer suggested just forces this start so it should fix your problem.

[PiotrZierhoffer]

That's right, autostart causes the whole emulation to start.

And mon start or start in the Renode Monitor means "let's start the flow of virtual time"

[xobs]

Ah, I see.

Would it make sense, then, to print a warning out when a user issues continue via GDB and the emulation is stopped? Something like WARNING: Emulation is paused.

Also, shouldn't the GDB connection at least respond to interrupts, even if time is paused? It seems to me that ^C^CThe target is not responding to interrupt requests. is also a bug.

[pgielda]

I am pretty sure it could be improved to be more informative, sure.

[xobs]

It looks like cpu StartGdbServer 3333 true isn't a valid command, and when I change it to machine StartGdbServer 3333 true it doesn't change the behavior at all:

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
_start () at asm.S:27
27      in asm.S
(gdb) c
Continuing.
The target is not responding to interrupt requests.
Stop debugging it? (y or n)

[PiotrZierhoffer]

Sorry, it was supposed to be machine of course. The behaviour should have changed, I will investigate that

[PiotrZierhoffer]

I forgot that this "autostart" is not as "auto" as you'd like it to be.

It actually requires you to call mon halt, which, in fact, is similar to calling mon s (equivalent to mon start).

The reason for that is that this feature was part of a larger integration with Microchip's SoftConsole where we wanted to be able to autostart on first connection. It's not trivial to make the solution more general without over-complicating our state machine, because it has to address different scenarios, like user explicitly pausing time before first connection etc etc.

Defining a function for your use case would be the sensible option until we come up with a better approach. It will work well if you don't need to control time flow directly from Renode.

[xobs]

What is the correct way to single-step from the reset vector? Currently I do stepi from GDB, which locks up (as per the bug title), then alt-tab over to the Renode console and run start. How would I accomplish this without needing to go between two windows?

[PiotrZierhoffer]

If you're connected to Renode via GDB, then mon s followed by stepi should do the trick.

[xobs]

Won't mon s start execution? Or does it start execution and then immediately halt the CPU?

This issue is more for the time I've spent trying to figure out what's going wrong, and why my simulation isn't working. I just did it again -- attach gdb, run continue, and wait for the output.

I have a small patch inside the Gdb server that automatically starts the simulation when it's stopped and the user does a continue, but am I right in assuming this lockup is intentional, and such a patch wouldn't be accepted?

[PiotrZierhoffer]

mon s will start the time flow, but if gdb is connected, the CPU stays in single step mode until prodded with c.

Regarding the patch - the lockup is intentional, but since it's not clear to the users, we'll have to rethink it. We need to take multinode/multicore setups into account here, but also make the simplest case easy to use. I'll try to put that in the loop and discuss possible solutions with the team.