From: Shahab Vahedi <shahab.vahedi@gmail.com>
To: gdb-patches@sourceware.org
Cc: Shahab Vahedi <shahab.vahedi@gmail.com>,
Shahab Vahedi <shahab@synopsys.com>,
Francois Bedard <fbedard@synopsys.com>
Subject: [PATCH] gdb: Do not interrupt atomic sequences for ARC
Date: Tue, 26 Jan 2021 00:02:30 +0100 [thread overview]
Message-ID: <20210125230230.12250-1-shahab.vahedi@gmail.com> (raw)
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's fwrite()
function.
gdb/ChangeLog:
* arc-linux-tdep.c (handle_atomic_sequence): New.
(arc_linux_software_single_step): Call handle_atomic_sequence().
---
gdb/arc-linux-tdep.c | 64 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/gdb/arc-linux-tdep.c b/gdb/arc-linux-tdep.c
index c9fbd7ddc28..0e485d6b967 100644
--- a/gdb/arc-linux-tdep.c
+++ b/gdb/arc-linux-tdep.c
@@ -332,6 +332,67 @@ 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:
+
+ 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. */
+
+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. */
+ if (insn.insn_class != LLOCK)
+ return next_pcs;
+
+ /* 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 LLOKCK'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 +410,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
next reply other threads:[~2021-01-25 23:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 23:02 Shahab Vahedi [this message]
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 ` [PATCH v2] " Shahab Vahedi
2021-02-05 16:13 ` 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=20210125230230.12250-1-shahab.vahedi@gmail.com \
--to=shahab.vahedi@gmail.com \
--cc=fbedard@synopsys.com \
--cc=gdb-patches@sourceware.org \
--cc=shahab@synopsys.com \
/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).