public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Shahab Vahedi <shahab.vahedi@gmail.com>
To: gdb-patches@sourceware.org
Cc: Shahab Vahedi <shahab.vahedi@gmail.com>,
	Shahab Vahedi <shahab@synopsys.com>,
	Simon Marchi <simon.marchi@polymtl.ca>,
	Francois Bedard <fbedard@synopsys.com>
Subject: [PATCH v2] gdb: Do not interrupt atomic sequences for ARC
Date: Thu,  4 Feb 2021 20:20:55 +0100	[thread overview]
Message-ID: <20210204192055.31046-1-shahab.vahedi@gmail.com> (raw)
In-Reply-To: <20210125230230.12250-1-shahab.vahedi@gmail.com>

From: Shahab Vahedi <shahab@synopsys.com>

An atomic sequence for ARC looks something like below (For a better
understanding of "llock", "scond", and "LF", please read [1]):

 50: llock   r2,[r0]         ; initiate an atomic write by setting LF=1
 54: brne.nt r2,0,66         ; somebody else wrote? break if so.
 58: scond   r3,[r0]         ; only write if LF is still 1
 62: bne     fwrite+50       ; did we succeed? try again if not.
 66: brne_s  r2,0,148        ; another thread won the game, go waiting
 68: st      r18,[r13,64]    ; welcome to the realm

Normally GDB sets breakpoint on every instructions.  This means that
there are exceptions raised between "llock" and "scond".  When that
happens the "LF" flag is cleared and we lose the atomicity.

This patch teaches GDB the pattern of "llock .. scond" and will set
the next breakpoint _after_ scond.  No matter if you use "n", "ni",
"s", "si"; they all will skip over the atomic sequence now.  If you
really want to break in between you must explicitly set a breakpoint.

[1]
"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:

https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46

v2 (after Simon's remarks[2]):
- 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-January/175487.html

gdb/ChangeLog:

	* arc-linux-tdep.c (handle_atomic_sequence): New.
	(arc_linux_software_single_step): Call handle_atomic_sequence().
---
 gdb/arc-linux-tdep.c | 73 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/gdb/arc-linux-tdep.c b/gdb/arc-linux-tdep.c
index c9fbd7ddc28..45bce67638b 100644
--- a/gdb/arc-linux-tdep.c
+++ b/gdb/arc-linux-tdep.c
@@ -332,6 +332,76 @@ arc_linux_sw_breakpoint_from_kind (struct gdbarch *gdbarch,
 	  : arc_linux_trap_s_le);
 }
 
+/* Check for an atomic sequence of instructions beginning with an
+   LLOCK instruction and ending with a SCOND instruction.
+
+   These patterns are hand coded in libc's (glibc and uclibc). Take
+   a look at [1] for instance:
+
+   main+14: llock   r2,[r0]
+   main+18: brne.nt r2,0,main+30
+   main+22: scond   r3,[r0]
+   main+26: bne     main+14
+   main+30: mov_s   r0,0
+
+   If such a sequence is found, attempt to step over it.
+   A breakpoint is placed at the end of the sequence.
+
+   This function expects the INSN to be a "llock(d)" instruction.
+
+   [1]
+   https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/ \
+     sysdeps/linux/arc/bits/atomic.h#n46
+   */
+
+static std::vector<CORE_ADDR>
+handle_atomic_sequence (arc_instruction insn, disassemble_info &di)
+{
+  const int atomic_seq_len = 24;    /* Instruction sequence length.  */
+  std::vector<CORE_ADDR> next_pcs = {};
+
+  /* Sanity check.  */
+  gdb_assert (insn.insn_class == LLOCK);
+
+  /* Data size we are dealing with: LLOCK vs. LLOCKD  */
+  arc_ldst_data_size llock_data_size_mode = insn.data_size_mode;
+  /* Indicator if any conditional branch is found in the sequence.  */
+  bool found_bc = false;
+  /* Becomes true if "LLOCK(D) .. SCOND(D)" sequence is found.  */
+  bool is_pattern_valid = false;
+
+  for (int insn_count = 0; insn_count < atomic_seq_len; ++insn_count)
+    {
+      arc_insn_decode (arc_insn_get_linear_next_pc (insn),
+		       &di, arc_delayed_print_insn, &insn);
+
+      if (insn.insn_class == BRCC)
+        {
+          /* If more than one conditial branch is found, this is not
+             the pattern we are interested in.  */
+          if (found_bc)
+	    break;
+	  found_bc = true;
+	  continue;
+        }
+
+      /* This is almost a happy ending.  */
+      if (insn.insn_class == SCOND)
+        {
+	  /* SCOND should match the LLOCK's data size.  */
+	  if (insn.data_size_mode == llock_data_size_mode)
+	    is_pattern_valid = true;
+	  break;
+        }
+    }
+
+  if (is_pattern_valid)
+    /* Get next instruction after scond(d).  There is no limm.  */
+    next_pcs.push_back (insn.address + insn.length);
+
+  return next_pcs;
+}
+
 /* Implement the "software_single_step" gdbarch method.  */
 
 static std::vector<CORE_ADDR>
@@ -349,6 +419,9 @@ arc_linux_software_single_step (struct regcache *regcache)
 
   std::vector<CORE_ADDR> next_pcs;
 
+  if (curr_insn.insn_class == LLOCK)
+    return handle_atomic_sequence (curr_insn, di);
+
   /* For instructions with delay slots, the fall thru is not the
      instruction immediately after the current instruction, but the one
      after that.  */
-- 
2.30.0


  parent reply	other threads:[~2021-02-04 19:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 23:02 [PATCH] " Shahab Vahedi
2021-01-26  3:34 ` Simon Marchi
2021-01-26 10:11   ` Shahab Vahedi
2021-01-26 16:02     ` Simon Marchi
2021-02-04 19:27       ` Shahab Vahedi
2021-02-04 19:20 ` Shahab Vahedi [this message]
2021-02-05 16:13   ` [PATCH v2] " Tom Tromey
2021-02-08 12:07 ` [PUSHED master] " Shahab Vahedi
2021-02-08 12:20 ` [PUSHED gdb-10-branch] " Shahab Vahedi

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=20210204192055.31046-1-shahab.vahedi@gmail.com \
    --to=shahab.vahedi@gmail.com \
    --cc=fbedard@synopsys.com \
    --cc=gdb-patches@sourceware.org \
    --cc=shahab@synopsys.com \
    --cc=simon.marchi@polymtl.ca \
    /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: link
Be 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).