Re: Automating Qemu and GDB together

[Alex Bennée]

R. Diez <address@hidden> 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