R. Diez <[email protected]> writes:
>> 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? If you can connect to the QMP port is ready. If you can't it isn't. >> 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. Sure - for our test script it's not a problem because it gracefully handles a failed connection which can occur for a number of other mundane reasons. >> 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? TCP will attempt to connect to a port for some seconds before timing out if nothing is listening. > 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. Why not just script GDB to attempt to re-connect if it failed the first time? > 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? Yes. > > >> [...] >> 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 -- Alex Bennée
