public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH] testsuite, mi: avoid a clang bug in 'user-selected-context-sync.exp'
Date: Mon, 29 Mar 2021 10:36:27 -0400	[thread overview]
Message-ID: <0f65522b-5985-b00c-0bf1-af8300099bff@polymtl.ca> (raw)
In-Reply-To: <1617026615-4257-1-git-send-email-tankut.baris.aktemur@intel.com>

On 2021-03-29 10:03 a.m., Tankut Baris Aktemur via Gdb-patches wrote:> This test causes several timeouts for Clang, taking too long time to
> finish.  The reason is, for an infinite loop of the form
> 
>    while(1); /* suppose this is line 30.  */
> 
> Clang generates code that looks like
> 
>    0x00000000004004d4 <+4>:     jmp    0x4004d9 <loop+9>
>    0x00000000004004d9 <+9>:     jmp    0x4004d9 <loop+9>
> 
> So, the real loop is the instruction at address 0x4004d9.  But a
> breakpoint that's defined at the loop line (assume line 30 in this
> case) is inserted at address 0x4004d4.
> 
>   (gdb) break 30
>   Breakpoint 1 at 0x4004d4: file test.c, line 30.
> 
> Therefore, continuing a thread that was spinning on the loop does not hit
> the breakpoint.  The bug is reported at
> 
>   https://bugs.llvm.org/show_bug.cgi?id=49614
> 
> Tweak the infinite loop to spin on a variable to avoid this bug.  The
> test is unrelated to the bug.
> 
> gdb/testsuite/ChangeLog:
> 2021-03-29  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>
> 
> 	* gdb.mi/user-selected-context-sync.exp: Spin on a variable in
> 	the infinite loop to avoid a Clang bug.
> ---
>  gdb/testsuite/gdb.mi/user-selected-context-sync.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.mi/user-selected-context-sync.c b/gdb/testsuite/gdb.mi/user-selected-context-sync.c
> index 500a118a2dc..0f8a966f69d 100644
> --- a/gdb/testsuite/gdb.mi/user-selected-context-sync.c
> +++ b/gdb/testsuite/gdb.mi/user-selected-context-sync.c
> @@ -27,7 +27,8 @@ static pthread_barrier_t barrier;
>  static void
>  child_sub_function (void)
>  {
> -  while (1); /* thread loop line */
> +  int spin = 1;
> +  while (spin); /* thread loop line */
>  }
>  
>  static void *
> @@ -57,7 +58,8 @@ main (void)
>  
>    pthread_barrier_wait (&barrier);
>  
> -  while (1); /* main break line */
> +  int spin = 1;
> +  while (spin); /* main break line */
>  
>    return 0;
>  }
> 

Thanks, this is OK.  Maybe just add a comment in the code, otherwise
someone might be tempted to "optimize" it.  If they see the comment,
they'll be able to "git blame" and get the full story.

Simon

      reply	other threads:[~2021-03-29 14:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 14:03 Tankut Baris Aktemur
2021-03-29 14:36 ` Simon Marchi [this message]

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=0f65522b-5985-b00c-0bf1-af8300099bff@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=tankut.baris.aktemur@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).