public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "shahab.vahedi at gmail dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-27369-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=27369 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 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------- -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2021-02-08 11:32 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-08 11:32 shahab.vahedi at gmail dot com [this message] 2021-02-08 11:53 ` [Bug tdep/27369] " shahab.vahedi at gmail dot com 2021-02-08 12:03 ` cvs-commit at gcc dot gnu.org 2021-02-08 12:07 ` luis.machado at linaro dot org 2021-02-08 12:12 ` cvs-commit at gcc dot gnu.org 2021-02-08 12:32 ` shahab.vahedi at gmail dot com 2021-06-27 18:00 ` ahmedsayeed1982 at yahoo dot com 2021-08-19 6:01 ` ucelsanicin at yahoo dot com 2021-09-02 11:06 ` donipah907 at mtlcz dot com 2021-09-02 11:13 ` mark at klomp dot org 2021-09-06 9:09 ` focixujo at livinginsurance dot co.uk 2021-09-10 19:39 ` mehmetgelisin at aol dot com 2021-09-22 10:11 ` diheto5497 at secbuf dot com 2021-09-26 13:31 ` tes.vik1986 at gmail dot com 2021-10-09 11:00 ` gulsenenginar at aol dot com 2021-10-10 16:11 ` oficaj3 at gmail dot com 2021-10-19 7:14 ` progonsaytu at gmail dot com 2021-10-24 10:02 ` glassmtech at ukr dot net 2021-11-06 21:13 ` paneki8601 at dukeoo dot com 2021-11-16 19:08 ` xecana8007 at funboxcn dot com 2021-11-16 19:12 ` xecana8007 at funboxcn dot com 2021-11-16 19:15 ` xecana8007 at funboxcn dot com 2021-11-17 11:07 ` luis.machado at linaro dot org 2021-11-22 7:39 ` gexed96894 at keagenan dot com
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=bug-27369-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@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: linkBe 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).