Re: Automating Qemu and GDB together

[Alex Bennée]

R. Diez <address@hidden> writes:

>> 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.

It could if it wanted to - for our purposes it's catching the times we
can't connect because GDB doesn't understand the guest.

>
> 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.

Well the problem is we have features for some of our guests that system
installed GDBs seem to dislike - either registers sizes they don't
understand or connection types they can't deal with. These are GDB bugs
and shouldn't cause our testing to fail so we skip the tests. This is
why configure takes a --gdb option so you can test with a hand-built
GDB.

You will note the SKIPPING message is echoes to sys.stderr for this
reason.

> 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.

Sure if you are willing to write the logic to deal with probing the GDB
capabilities and deal the full gdb version vs qemu guest matrix of
possibilities. Otherwise be content that the maintainer does keep an eye
on the logs on his local system configured with a reasonably recent
version of GDB for this very reason.

>
>
>> [...]
>> 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-)

Well I have already pointed out a number of ways you could sequence the
starting of QEMU and connection of GDB. Please don't expect QEMU to grow
another feature because they aren't acceptable to you.

>
>
>> 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


-- 
Alex Bennée