Bug 27369 - ARC: Stepping over atomic instruction sequences loops infinitely
Summary: ARC: Stepping over atomic instruction sequences loops infinitely
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: tdep (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 10.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-08 11:32 UTC by Shahab
Modified: 2021-11-22 07:39 UTC (History)
15 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: arc-snps-linux-uclibc
Build: x86_64-pc-linux-gnu
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shahab 2021-02-08 11:32:44 UTC
When stepping over thread-lock related codes (in uClibc), the inferior process
gets stuck and never manages to enter the critical section:

------8<-------
 1 size_t fwrite(const void * __restrict ptr, size_t size,
 2               size_t nmemb, register FILE * __restrict stream)
 3 {
 4     size_t retval;
 5     __STDIO_AUTO_THREADLOCK_VAR;
 6 
 7 >   __STDIO_AUTO_THREADLOCK(stream);
 8 
 9     retval = fwrite_unlocked(ptr, size, nmemb, stream);
10 
11     __STDIO_AUTO_THREADUNLOCK(stream);
12 
13     return retval;
14 }
------>8-------

Here, we are at line 7. Using the "next" command leads no where. However,
setting a breakpoint on line 9 and issuing "continue" works.

Looking at the assembly instructions reveals that we're dealing with the
critical section entry code [1] that should never be interrupted, in this
case by the debugger's implicit breakpoints:

------8<-------
  ...
1 add_s   r0,r13,0x38
2 mov_s   r3,1
3 llock   r2,[r0]        <-.
4 brne.nt r2,0,14     --.  |
5 scond   r3,[r0]       |  |
6 bne     -10         --|--'
7 brne_s  r2,0,84     <-'
  ...
------>8-------

Lines 3 until 5 (inclusive) are supposed to be executed atomically. Therefore,
GDB should never (implicitly) insert a breakpoint on lines 4 and 5, else the
program will try to acquire the lock again by jumping back to line 3 and
gets stuck in an infinite loop.

The solution is to make GDB aware of these patterns so it inserts breakpoints
after the sequence -- line 6 in this example.

[1]
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46
------8<-------
#define __arch_compare_and_exchange_val_32_acq(mem, newval, oldval)     \
  ({									\
	__typeof(oldval) prev;						\
									\
	__asm__ __volatile__(						\
	"1:	llock   %0, [%1]	\n"				\
	"	brne    %0, %2, 2f	\n"				\
	"	scond   %3, [%1]	\n"				\
	"	bnz     1b		\n"				\
	"2:				\n"				\
	: "=&r"(prev)							\
	: "r"(mem), "ir"(oldval),					\
	  "r"(newval) /* can't be "ir". scond can't take limm for "b" */\
	: "cc", "memory");						\
									\
	prev;								\
  })
------>8-------
Comment 1 Sourceware Commits 2021-02-08 12:03:51 UTC
The master branch has been updated by Shahab Vahedi <shahab@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9b3e4b5d74a8170a8f9f224c36c651661fc26954

commit 9b3e4b5d74a8170a8f9f224c36c651661fc26954
Author: Shahab Vahedi <shahab@synopsys.com>
Date:   Thu Oct 31 17:33:08 2019 +0100

    gdb: Do not interrupt atomic sequences for ARC
    
    When stepping over thread-lock related codes (in uClibc), the inferior process
    gets stuck and never manages to enter the critical section:
    
    ------8<-------
     1 size_t fwrite(const void * __restrict ptr, size_t size,
     2               size_t nmemb, register FILE * __restrict stream)
     3 {
     4     size_t retval;
     5     __STDIO_AUTO_THREADLOCK_VAR;
     6
     7 >   __STDIO_AUTO_THREADLOCK(stream);
     8
     9     retval = fwrite_unlocked(ptr, size, nmemb, stream);
    10
    11     __STDIO_AUTO_THREADUNLOCK(stream);
    12
    13     return retval;
    14 }
    ------>8-------
    
    Here, we are at line 7.  Using the "next" command leads no where.
    However, setting a breakpoint on line 9 and issuing "continue" works.
    
    Looking at the assembly instructions reveals that we're dealing with the
    critical section entry code [1] that should never be interrupted, in this
    case by the debugger's implicit breakpoints:
    
    ------8<-------
      ...
    1 add_s   r0,r13,0x38
    2 mov_s   r3,1
    3 llock   r2,[r0]        <-.
    4 brne.nt r2,0,14     --.  |
    5 scond   r3,[r0]       |  |
    6 bne     -10         --|--'
    7 brne_s  r2,0,84     <-'
      ...
    ------>8-------
    
    Lines 3 until 5 (inclusive) are supposed to be executed atomically.
    Therefore, GDB should never (implicitly) insert a breakpoint on lines
    4 and 5, else the program will try to acquire the lock again by jumping
    back to line 3 and gets stuck in an infinite loop.
    
    The solution is to make GDB aware of these patterns so it inserts
    breakpoints after the sequence -- line 6 in this example.
    
    [1]
    https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46
    ------8<-------
      ({                                                                    \
            __typeof(oldval) prev;                                          \
                                                                            \
            __asm__ __volatile__(                                           \
            "1:     llock   %0, [%1]        \n"                             \
            "       brne    %0, %2, 2f      \n"                             \
            "       scond   %3, [%1]        \n"                             \
            "       bnz     1b              \n"                             \
            "2:                             \n"                             \
            : "=&r"(prev)                                                   \
            : "r"(mem), "ir"(oldval),                                       \
              "r"(newval) /* can't be "ir". scond can't take limm for "b" */\
            : "cc", "memory");                                              \
                                                                            \
            prev;                                                           \
      })
    ------>8-------
    "llock" (Load Locked) loads the 32-bit word pointed by the source
    operand.  If the load is completed without any interruption or
    exception, the physical address is remembered, in Lock Physical Address
    (LPA), and the Lock Flag (LF) is set to 1.  LF is a non-architecturally
    visible flag and is cleared whenever an interrupt or exception takes
    place.  LF is also cleared (atomically) whenever another process writes
    to the LPA.
    
    "scond" (Store Conditional) will write to the destination address if
    and only if the LF is set to 1.  When finished, with or without a write,
    it atomically copies the LF value to ZF (Zero Flag).
    
    These two instructions together provide the mechanism for entering a
    critical section.  The code snippet above comes from uClibc:
    -----------------------
    
    v3 (after Tom's remarks[2]):
     handle_atomic_sequence()
      - no need to initialize the std::vector with "{}"
      - fix typo in comments: "conditial" -> "conditional"
      - add braces to the body of "if" condition because of the comment line
     arc_linux_software_single_step()
      - make the performance slightly more efficient by moving a few
        variables after the likely "return" point.
    
    v2 (after Simon's remarks[3]):
    - handle_atomic_sequence() gets a copy of an instruction instead of
      a reference.
    - handle_atomic_sequence() asserts if the given instruction is an llock.
    
    [2]
    https://sourceware.org/pipermail/gdb-patches/2021-February/175805.html
    
    [3]
    https://sourceware.org/pipermail/gdb-patches/2021-January/175487.html
    
    gdb/ChangeLog:
    
            PR tdep/27369
            * arc-linux-tdep.c (handle_atomic_sequence): New.
            (arc_linux_software_single_step): Call handle_atomic_sequence().
Comment 2 Sourceware Commits 2021-02-08 12:12:34 UTC
The gdb-10-branch branch has been updated by Shahab Vahedi <shahab@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d8979e81fdae49a0a3d5ba484ef870f54e2f750d

commit d8979e81fdae49a0a3d5ba484ef870f54e2f750d
Author: Shahab Vahedi <shahab@synopsys.com>
Date:   Thu Oct 31 17:33:08 2019 +0100

    gdb: Do not interrupt atomic sequences for ARC
    
    When stepping over thread-lock related codes (in uClibc), the inferior process
    gets stuck and never manages to enter the critical section:
    
    ------8<-------
     1 size_t fwrite(const void * __restrict ptr, size_t size,
     2               size_t nmemb, register FILE * __restrict stream)
     3 {
     4     size_t retval;
     5     __STDIO_AUTO_THREADLOCK_VAR;
     6
     7 >   __STDIO_AUTO_THREADLOCK(stream);
     8
     9     retval = fwrite_unlocked(ptr, size, nmemb, stream);
    10
    11     __STDIO_AUTO_THREADUNLOCK(stream);
    12
    13     return retval;
    14 }
    ------>8-------
    
    Here, we are at line 7.  Using the "next" command leads no where.
    However, setting a breakpoint on line 9 and issuing "continue" works.
    
    Looking at the assembly instructions reveals that we're dealing with the
    critical section entry code [1] that should never be interrupted, in this
    case by the debugger's implicit breakpoints:
    
    ------8<-------
      ...
    1 add_s   r0,r13,0x38
    2 mov_s   r3,1
    3 llock   r2,[r0]        <-.
    4 brne.nt r2,0,14     --.  |
    5 scond   r3,[r0]       |  |
    6 bne     -10         --|--'
    7 brne_s  r2,0,84     <-'
      ...
    ------>8-------
    
    Lines 3 until 5 (inclusive) are supposed to be executed atomically.
    Therefore, GDB should never (implicitly) insert a breakpoint on lines
    4 and 5, else the program will try to acquire the lock again by jumping
    back to line 3 and gets stuck in an infinite loop.
    
    The solution is to make GDB aware of these patterns so it inserts
    breakpoints after the sequence -- line 6 in this example.
    
    [1]
    https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46
    ------8<-------
      ({                                                                    \
            __typeof(oldval) prev;                                          \
                                                                            \
            __asm__ __volatile__(                                           \
            "1:     llock   %0, [%1]        \n"                             \
            "       brne    %0, %2, 2f      \n"                             \
            "       scond   %3, [%1]        \n"                             \
            "       bnz     1b              \n"                             \
            "2:                             \n"                             \
            : "=&r"(prev)                                                   \
            : "r"(mem), "ir"(oldval),                                       \
              "r"(newval) /* can't be "ir". scond can't take limm for "b" */\
            : "cc", "memory");                                              \
                                                                            \
            prev;                                                           \
      })
    ------>8-------
    "llock" (Load Locked) loads the 32-bit word pointed by the source
    operand.  If the load is completed without any interruption or
    exception, the physical address is remembered, in Lock Physical Address
    (LPA), and the Lock Flag (LF) is set to 1.  LF is a non-architecturally
    visible flag and is cleared whenever an interrupt or exception takes
    place.  LF is also cleared (atomically) whenever another process writes
    to the LPA.
    
    "scond" (Store Conditional) will write to the destination address if
    and only if the LF is set to 1.  When finished, with or without a write,
    it atomically copies the LF value to ZF (Zero Flag).
    
    These two instructions together provide the mechanism for entering a
    critical section.  The code snippet above comes from uClibc:
    -----------------------
    
    v3 (after Tom's remarks[2]):
     handle_atomic_sequence()
      - no need to initialize the std::vector with "{}"
      - fix typo in comments: "conditial" -> "conditional"
      - add braces to the body of "if" condition because of the comment line
     arc_linux_software_single_step()
      - make the performance slightly more efficient by moving a few
        variables after the likely "return" point.
    
    v2 (after Simon's remarks[3]):
    - handle_atomic_sequence() gets a copy of an instruction instead of
      a reference.
    - handle_atomic_sequence() asserts if the given instruction is an llock.
    
    [2]
    https://sourceware.org/pipermail/gdb-patches/2021-February/175805.html
    
    [3]
    https://sourceware.org/pipermail/gdb-patches/2021-January/175487.html
    
    gdb/ChangeLog:
    
            PR tdep/27369
            * arc-linux-tdep.c (handle_atomic_sequence): New.
            (arc_linux_software_single_step): Call handle_atomic_sequence().
Comment 3 Shahab 2021-02-08 12:32:42 UTC
This PR was solved on master with this commit:

| commit 9b3e4b5d74a8170a8f9f224c36c651661fc26954
| From: Shahab Vahedi <shahab@synopsys.com>
| Date: Thu, 31 Oct 2019 17:33:08 +0100
| Subject: gdb: Do not interrupt atomic sequences for ARC

The patch above was also pushed to gdb-10-branch:

| commit d8979e81fdae49a0a3d5ba484ef870f54e2f750d
| From: Shahab Vahedi <shahab@synopsys.com>
| Date: Thu, 31 Oct 2019 17:33:08 +0100
| Subject: gdb: Do not interrupt atomic sequences for ARC
Comment 4 Ahmed Sayeed 2021-06-27 18:00:46 UTC Comment hidden (spam)
Comment 5 Ucel Sani 2021-08-19 06:01:48 UTC Comment hidden (spam)
Comment 6 james rohan 2021-09-02 11:06:55 UTC Comment hidden (spam)
Comment 7 james robin 2021-09-06 09:09:11 UTC Comment hidden (spam)
Comment 8 Mehmet gelisin 2021-09-10 19:39:20 UTC Comment hidden (spam)
Comment 9 diheto 2021-09-22 10:11:45 UTC Comment hidden (spam)
Comment 10 Kylan 2021-09-26 13:31:41 UTC Comment hidden (spam)
Comment 11 Gulsen Engin 2021-10-09 11:00:43 UTC Comment hidden (spam)
Comment 12 oficaj3 2021-10-10 16:11:10 UTC Comment hidden (spam)
Comment 13 progonsaytu 2021-10-19 07:14:05 UTC Comment hidden (spam)
Comment 14 glassmtech 2021-10-24 10:02:00 UTC Comment hidden (spam)
Comment 15 paneki 2021-11-06 21:13:10 UTC Comment hidden (spam)
Comment 16 tesaso8237@funboxcn.comxecana8007@funboxcn.com 2021-11-16 19:08:21 UTC Comment hidden (spam)
Comment 17 tesaso8237@funboxcn.comxecana8007@funboxcn.com 2021-11-16 19:12:20 UTC Comment hidden (spam)
Comment 18 tesaso8237@funboxcn.comxecana8007@funboxcn.com 2021-11-16 19:15:47 UTC Comment hidden (spam)
Comment 19 gexed96894 2021-11-22 07:39:48 UTC Comment hidden (spam)