public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tdep/27369] ARC: Stepping over atomic instruction sequences loops infinitely Date: Mon, 08 Feb 2021 12:03:51 +0000 [thread overview] Message-ID: <bug-27369-4717-Pv9R15afIJ@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-27369-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=27369 --- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- 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(). -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2021-02-08 12:03 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-08 11:32 [Bug tdep/27369] New: " shahab.vahedi at gmail dot com 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 [this message] 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-Pv9R15afIJ@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).