Re: Automating Qemu and GDB together

[R. Diez]

> What is starting these two things in parallel?

My script does, and script tests/guest-debug/run-test.py does too. These scripts start QEMU in the background (otherwise the script would wait for 
Qemu to finish, which would never happen) and then the script starts GDB (but this time it waits for GDB to finish). These 2 programs (QEMU and GDB) 
start therefore in parallel.


> If you want something
> truly bullet proof, at least for system emulation, you should launch
> QEMU in the stopped state, connect to a QMP port, enable the gdbserver
> and then start the gdb process.

That has exactly the same problem: how do I know when QEMU is ready to accept a 
connection on the QMP port?


> Well it's done before the initial vCPU starts executing.

This still does not cut it. I have seen these kind of problems in the past: everything works well, until it does not. It is actually a race condition 
waiting to happen, if you think about it.


> If you are
> worried about it you could check for the existence of the socket before
> spawning gdb. The latest QEMU (5.0) now support unix socket connected
> for linux-user targets.

Unfortunately, I am using an older QEMU version.

But your suggestion is interesting. How would you check whether a listening TCP socket exists from a script? I guess that would only work on a local 
system. Is there a way that avoid parsing the output of some Linux command?

I am thinking about the following method, which would work even for remote hosts: the script loops around with a small pause between iterations, and 
in each iteration it tries to connect to the remote socket. If the connection fails, it does another iteration. If it succeeds, it closes the 
connection and starts GDB.

Do you know what happens if QEMU is waiting for the first GDB connection, and that socket connection does nothing but connect and disconnect? Will 
QEMU then start the emulator?


> [...]
> For the test cases I've never run into the problem of QEMU not being
> ready by the time python attempts to fork gdb.

My guess is that it is only luck. Or maybe something is actually checking and retrying a few times. But GDB does not document any retrying in its 
"remote" command.

Best regards,
  rdiez