Re: Automating Qemu and GDB together

[Alex Bennée]

R. Diez <address@hidden> writes:

> First of all, thanks for your answer.
>
>> If you launch linux-user with -g 1234 or system emulation with the -S
>> flag the guest starts suspended until gdb attaches and continues the
>> target.
>
> Yes, that is the option I am using. But this is a different subject.
> If both GDB and Qemu start in parallel, GDB may try to connect before
> Qemu has opened its listening socket.

What is starting these two things 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.

>> The gdbstub should be ready pretty early on in start-up.
>
> "pretty early" is a very vague statement. It may hold true today,
> because GDB perhaps starts more slowly. But it may not hold tomorrow.
> GDB may get faster. Or GDB may be on disk cache and Qemu not yet. Or
> Qemu may start doing more and get slower.

Well it's done before the initial vCPU starts executing. 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.

> I guess Qemu has no scripting capabilities, has it? And no events that
> you could hook, something like "OnReady()". It is somewhat surprising.
> For example, GDB and OpenOCD both have scripting capabilities.

There is no scripting built-in to QEMU but it does have a control
interface called QMP which allows tools like libvirt to provision and
control a QEMU instance. You can wrap your scripting around QEMU.

>> We now have a script in tests/guest-debug/run-test.py which we use to run our
>> own test cases.
>
> That script makes no pause between launching Qemu and launching GDB.
>
> Perhaps it is not necessary after all. But that is strange. This kind
> of synchronisation problem is prevalent among servers and clients.

Sure - so deal with it at the level that is launching both QEMU and GDB.
For the test cases I've never run into the problem of QEMU not being
ready by the time python attempts to fork gdb.

-- 
Alex Bennée