Re: Automating Qemu and GDB together

[Alex Bennée]

R. Diez <address@hidden> writes:

>> [...]
>> 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.
>
> Could you point me to such a script?
>
> I guess this is not script "tests/guest-debug/run-test.py", because I
> did not see such a logic there.

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)

>
>
>> TCP will attempt to connect to a port for some seconds before timing
>> out if nothing is listening.
>
> That is not true: if there is no listening TCP socket, you get a
> "connection refused" straight away.

In one window:

  tcpdump -vvv -i lo port 1234

In another:

  gdb -ex "target remote localhost:1234"

And witness the time between first and last SYN packet:

  15:22:30.950322 IP (tos 0x0, ttl 64, id 51172, offset 0, flags [DF], proto 
TCP (6), length 60)
      localhost.36028 > localhost.1234: Flags [S], cksum 0xfe30 (incorrect -> 
0x2c04), seq 1594393824, win 65495, options [mss 65495,sackOK,TS val 2538411833 
ecr 0,nop,wscale
  7], length 0
  ...
  15:22:43.363782 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP 
(6), length 40)
    localhost.1234 > localhost.36058: Flags [R.], cksum 0xe134 (correct), seq 
0, ack 2320938134, win 0, length 0

>> Why not just script GDB to attempt to re-connect if it failed the first
>> time?
>
> That is easier said than done. 8-) GDB may or may not have been
> compiled with Python, which is not normally the case when building
> cross-compilation toolchains. In any case, I do not know Python yet (I
> remained in Perl). And GDB's default simple scripting language does
> not handle errors very well.
>
>
>>> 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.
>
> That is unfortunate. I would have hoped it would have waited at least
> for some GDB protocol handshake.

This could be improved, the logic for linux-user in gdbstub is:

    while (gdbserver_state.running_state == 0) {
        n = read(gdbserver_state.fd, buf, 256);
        if (n > 0) {
            int i;

            for (i = 0; i < n; i++) {
                gdb_read_byte(buf[i]);
            }
        } else {
            /* XXX: Connection closed.  Should probably wait for another
               connection before continuing.  */
            if (n == 0) {
                close(gdbserver_state.fd);
            }
            gdbserver_state.fd = -1;
            return sig;
        }
    }

For system emulation targets its a little more complex as we rely on the
chardev layer to handle things.

>
> Regards,
>   rdiez


-- 
Alex Bennée