From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 243A33893648; Mon, 8 Feb 2021 11:32:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 243A33893648 From: "shahab.vahedi at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug tdep/27369] New: ARC: Stepping over atomic instruction sequences loops infinitely Date: Mon, 08 Feb 2021 11:32:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: shahab.vahedi at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 11:32:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27369 Bug ID: 27369 Summary: ARC: Stepping over atomic instruction sequences loops infinitely Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: shahab.vahedi at gmail dot com Target Milestone: --- When stepping over thread-lock related codes (in uClibc), the inferior proc= ess 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=20 7 > __STDIO_AUTO_THREADLOCK(stream); 8=20 9 retval =3D fwrite_unlocked(ptr, size, nmemb, stream); 10=20 11 __STDIO_AUTO_THREADUNLOCK(stream); 12=20 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. Therefo= re, 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 breakpoin= ts after the sequence -- line 6 in this example. [1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/a= rc/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" \ : "=3D&r"(prev) \ : "r"(mem), "ir"(oldval), \ "r"(newval) /* can't be "ir". scond can't take limm for "b" */\ : "cc", "memory"); \ \ prev; \ }) ------>8------- --=20 You are receiving this mail because: You are on the CC list for the bug.=