Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Lancelot SIX <Lancelot.Six@amd.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp
Date: Tue, 17 Oct 2023 10:48:24 -0400	[thread overview]
Message-ID: <0a223be2-f3c8-4cf1-90ea-1084232622ea@simark.ca> (raw)
In-Reply-To: <60a7f9cd-3c64-4100-9334-5879db42a62a@amd.com>

On 10/17/23 10:41, Lancelot SIX wrote:
> 
>> On 10/17/23 07:16, Lancelot Six wrote:
>>> The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
>>> command, but this is incorrect.  If "continue" is given an argument, it
>>> sets the ignore count of the breakpoint the thread stopped at.
>>>
>>> For this testcase it does not really matter since the breakpoint is not
>>> meant to be hit anymore, so whatever the ignore count is won't influence
>>> the outcome of the test.  It is worth fixing nevertheless.
>>>
>>> While at changing it, switch to using "continue&" to consume the GDB
>>> prompt right away.  This makes the following pattern matching more
>>> reliable.
>>
>> I don't understand the "more reliable" part, can you explain?
>>
>> Simon
> 
> There will be a "(gdb) " prompt appearing at some point after a "continue", but in non-stop we don't really control when it appears (if I understand correctly).  It seems that other non-stop tests use the "&" variant and consume the prompt immediately.
> 
> With this, before the next command is issued, we know that 1) we got a prompt and 2) we have seen the process we just released finish.
> 
> Overall, I am mostly trying to follow patterns I caught in other non-stop tests.

Ah, I missed that we were in non-stop.

If we run a single thread at a time, I think it will be reliable to use
the sync variant of continue.  Using the async variant is useful when
you resume multiple threads and expect multiple events (like breakpoint
hits) which can happen in any order.  At least that's my understanding.

Simon

  reply	other threads:[~2023-10-17 14:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17 11:16 Lancelot Six
2023-10-17 11:21 ` Lancelot SIX
2023-10-17 14:25 ` Simon Marchi
2023-10-17 14:41   ` Lancelot SIX
2023-10-17 14:48     ` Simon Marchi [this message]
2023-10-18  8:32       ` Lancelot SIX
2023-10-18 10:24 ` [PATCH v2] " Lancelot Six
2023-10-18 20:26   ` Simon Marchi
2023-10-18 20:32     ` Lancelot SIX

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=0a223be2-f3c8-4cf1-90ea-1084232622ea@simark.ca \
    --to=simark@simark.ca \
    --cc=Lancelot.Six@amd.com \
    --cc=gdb-patches@sourceware.org \
    /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