public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug tdep/27369] New: ARC: Stepping over atomic instruction sequences loops infinitely
@ 2021-02-08 11:32 shahab.vahedi at gmail dot com
  2021-02-08 11:53 ` [Bug tdep/27369] " shahab.vahedi at gmail dot com
                   ` (22 more replies)
  0 siblings, 23 replies; 24+ messages in thread
From: shahab.vahedi at gmail dot com @ 2021-02-08 11:32 UTC (permalink / raw)
  To: gdb-prs

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.

^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2021-11-22  7:39 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-08 11:32 [Bug tdep/27369] New: ARC: Stepping over atomic instruction sequences loops infinitely 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
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

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).