From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org,
Wainer dos Santos Moschetta <wainersm@redhat.com>,
Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>,
Cleber Rosa <crosa@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v1 6/6] tests/acceptance: pick a random gdb port for reverse debugging
Date: Thu, 22 Oct 2020 14:07:20 +0100 [thread overview]
Message-ID: <87a6wev27r.fsf@linaro.org> (raw)
In-Reply-To: <8682564e-6ea1-d8eb-dc12-bf0a926c156b@amsat.org>
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> On 10/22/20 7:20 AM, Thomas Huth wrote:
>> On 21/10/2020 18.31, Alex Bennée wrote:
>>> Currently the test randomly fails if you are using a shared machine
>>> due to contention on the well known port 1234. We can ameliorate this
>>> a bit by picking a random non-ephemeral port although it doesn't
>>> totally avoid the problem. While we could use a totally unique socket
>>> address for debugging it's impossible to probe for gdb support of the
>>> feature which makes this a sub-optimal but less fiddly option.
>>>
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>> tests/acceptance/reverse_debugging.py | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> Certainly better than before!
>
> I'd prefer another chardev that tcp, but as you said this is
> already an improvement, so:
We've supported sockets gdb and softmmu emulation for some time:
-gdb unix:path=gdb.sock,server
the trouble is detecting if the host installed gdb is going to connect
before we try and fail after launching the VM. I think we might get away
with a version probe:
> luispm: I want to know ahead of time for my scripts if gdb can do a
"target remote gdb.sock"
<luispm> ajb-linaro, I don't think so. My guess is that GDB will
always attempt to stablish a connection if the socket is valid.
<luispm> ajb-linaro, Can you check the validity of the file before
invoking GDB?
<luispm> ajb-linaro, No concept of "is this particular remote target
available?".
> luispm: it's not that - I know the socket will exist but the older
gdb just bombs out trying to read it.
<luispm> ajb-linaro, Not good.
<luispm> ajb-linaro, So is this a matter of an older GDB that doesn't
support using socket files and a newer one that does?
> luispm: I thought I might probe "help target remote" text but it's
unchanged between versions
> luispm: yes
<luispm> ajb-linaro, I think the code is probably hidden within the
"target remote" implementation.
> luispm: and most distro gdb's don't at the moment
> luispm: if I could work out the version it was added that might help
<luispm> ajb-linaro, I see some bits of it were reverted at some
point.
<luispm> ajb-linaro, Let me check.
<luispm> ajb-linaro, It looks like GDB 8.3 was the first stable to get
it.
> luispm: thanks - I'll see if I can script that up
<luispm> ajb-linaro, Looks like they initially went with an explicit
prefix of "unix:" before the socket. But then dropped that in
favor of autodetecting the socket file.
<luispm> ajb-linaro, The only thing I get for a GDB that doesn't
support socket connections if
"/run/user/1000/at-spi2-QTZBS0/socket: No such device or address."
<luispm> *is*
<luispm> This is 8.1 in Ubuntu 18.04.
<luispm> master GDB says "Remote communication error. Target
disconnected.: Connection reset by peer."
>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>
>>
>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>>
--
Alex Bennée
next prev parent reply other threads:[~2020-10-22 13:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-21 16:31 [PATCH v1 0/6] testing/next (gitdm, acceptance, docker, gitlab) Alex Bennée
2020-10-21 16:31 ` [PATCH v1 1/6] Adding ani's email as an individual contributor Alex Bennée
2020-10-21 16:31 ` [PATCH v1 2/6] contrib/gitdm: Add more individual contributors Alex Bennée
2020-10-21 17:16 ` Philippe Mathieu-Daudé
2020-10-21 16:31 ` [PATCH v1 3/6] tests/docker/dockerfiles/centos: Use SDL2 instead of SDL1 Alex Bennée
2020-10-21 17:17 ` Philippe Mathieu-Daudé
2020-10-21 16:31 ` [PATCH v1 4/6] gitlab: skip checkpatch.pl checks if no commit delta on branch Alex Bennée
2020-10-22 4:54 ` Thomas Huth
2020-10-22 11:08 ` Philippe Mathieu-Daudé
2020-10-21 16:31 ` [PATCH v1 5/6] scripts: fix error from checkpatch.pl when no commits are found Alex Bennée
2020-10-21 16:31 ` [PATCH v1 6/6] tests/acceptance: pick a random gdb port for reverse debugging Alex Bennée
2020-10-22 5:20 ` Thomas Huth
2020-10-22 11:07 ` Philippe Mathieu-Daudé
2020-10-22 13:07 ` Alex Bennée [this message]
2020-10-22 6:18 ` Pavel Dovgalyuk
2020-10-22 15:46 ` Cleber Rosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6wev27r.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=pavel.dovgaluk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).