[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automating Qemu and GDB together

From: R. Diez
Subject: Re: Automating Qemu and GDB together
Date: Wed, 13 May 2020 15:35:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]