Re: Automating Qemu and GDB together

[R. Diez]

> The test scripts themselves are separate - so
> tests/tcg/multiarch/gdb/sha1.py has this:
>
>    #
>    # This runs as the script it sourced (via -x, via run-test.py)
>    #
>    try:
>        inferior = gdb.selected_inferior()
>        arch = inferior.architecture()
>        print("ATTACHED: %s" % arch.name())
>    except (gdb.error, AttributeError):
>        print("SKIPPING (not connected)", file=sys.stderr)
>        exit(0)

OK thanks.

I am not versed in Python, but that code example looks like it is not retring if the socket is not available (or whatever other error). It just gives 
up. That is not good.

More worryingly, it does not signal an error [exit(0)]. I already noticed such pattern in 
"tests/guest-debug/run-test.py":

     # A negative result is the result of an internal gdb failure like
     # a crash. We force a return of 0 so we don't fail the test on
     # account of broken external tools.
     if result < 0:
         print("GDB crashed? SKIPPING")
         exit(0)

My bet is that sooner or later you will regret skipping tests like that. At the very 
least, such warnings ("GDB crashed?") should to go stderr.

But not making these tests fail will probably end up masking problems. Who is going to scan the log file for "SKIPPING" messages? If a tool is known 
to fail, it is best to make an exception for a particular tool in a particular target.


> [...]
> And witness the time between first and last SYN packet:
> [...]

Alright, I guess that GDB is retrying then. That would explain why this has not 
been a problem yet.

It is not a clean solution, as you should never rely on timing when automating tasks, but given the general state of software in this day and age, I 
guess I should call it a day. 8-)


> This could be improved, the logic for linux-user in gdbstub is:
> [...]

OK, thanks for the info. As a humble QEMU user, this goes over my head at the 
moment, but it is good to have it documented, if only in this mailing list.

Regards,
  rdiez