From: uweigand@de.ibm.com
To: luisgpm@linux.vnet.ibm.com
Cc: uweigand@de.ibm.com (Ulrich Weigand), gdb-patches@sourceware.org
Subject: Re: [RFC] "single step" atomic instruction sequences as a whole on PPC
Date: Wed, 02 May 2007 14:08:00 -0000 [thread overview]
Message-ID: <200705021408.l42E8Qc0019267@dyn-9-152-216-62.boeblingen.de.ibm.com> (raw)
In-Reply-To: <1177964763.15264.45.camel@localhost> from "Luis Machado" at Apr 30, 2007 05:26:03 PM
Luis Machado wrote:
> Patch updated to reflect the inclusion of the regcache parameter.
Thanks! A number of additional comments:
> +static int
> +deal_with_atomic_sequence ()
Parameter is missing here.
> +{
> + CORE_ADDR pc = read_pc ();
> + CORE_ADDR breaks[2] = {-1, -1};
> + CORE_ADDR loc = pc;
> + int insn = read_memory_integer (loc, PPC_INSN_SIZE);
> + int last_break = 0;
> + int i;
> +
> + /* Assume all atomic sequences start with an lwarx or ldarx instruction. */
Should have two spaces after '.' (multiple instances of this throughout the patch)
> + if ((insn & LWARX_MASK) != LWARX_INSTRUCTION
> + && (insn & LWARX_MASK) != LDARX_INSTRUCTION)
> + return 0;
> +
> + /* Assume that no atomic sequence is longer than 6 instructions. */
> + for (i = 1; i < 5; ++i)
> + {
> + loc += PPC_INSN_SIZE;
> + insn = read_memory_integer (loc, PPC_INSN_SIZE);
> +
> + /* Assume at most one conditional branch instruction between
> + the lwarx and stwcx instructions.*/
Well, what happens if there *is* more than one? You should at least
detect that case ...
> + if ((insn & BC_MASK) == BC_INSTRUCTION)
> + {
> + last_break = 1;
> + breaks[1] = IMMEDIATE_PART (insn);
> + if ( ! ABSOLUTE_P(insn))
Space before '('; no spaces around '!'.
> + breaks[1] += loc;
> + continue;
> + }
Why don't you use the existing branch_dest routine instead of
re-implementing (parts of) it here?
> + if ((insn & STWCX_MASK) == STWCX_INSTRUCTION
> + || (insn & STWCX_MASK) == STDCX_INSTRUCTION)
> + break;
> + }
> +
> + /* Assume that the atomic sequence ends with a stwcx instruction
> + followed by a conditional branch instruction. */
> + if ((insn & STWCX_MASK) != STWCX_INSTRUCTION
> + && (insn & STWCX_MASK) != STDCX_INSTRUCTION)
> + warning (_("Tried to step over an atomic sequence of instructions at %s\n \
> + but could not find the end of the sequence."),
> + core_addr_to_string(pc));
Shouldn't you return to the default single-step handling if you do not
understand the sequence you find?
> +
> + loc += PPC_INSN_SIZE;
> + insn = read_memory_integer (loc, PPC_INSN_SIZE);
> +
> + if ((insn & BC_MASK) != BC_INSTRUCTION)
> + warning (_("Tried to step over an atomic sequence of instructions at %s\n \
> + but the instruction sequence ended in an unexpected way."),
> + core_addr_to_string(pc));
I'm wondering why this test is necessary. So what if there is no conditional
branch immediately after the stwcx? That shouldn't really matter ...
> +
> + breaks[0] = loc;
> +
> + /* This should never happen, but make sure we don't put
> + two breakpoints on the same address. */
> + if (last_break && breaks[1] == breaks[0])
> + last_break = 0;
> +
> + for (i = 0; i <= last_break; ++i)
> + insert_single_step_breakpoint (breaks[i]);
> +
> + printf_unfiltered (_("Stepping over an atomic sequence of instructions beginning at %s\n"),
> + core_addr_to_string (pc));
Should we really output this message unconditionally? If you're automatically
single-stepping (say, due to software watch points), this message could potentially
show up very frequently ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
Ulrich.Weigand@de.ibm.com
next parent reply other threads:[~2007-05-02 14:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1177964763.15264.45.camel@localhost>
2007-05-02 14:08 ` uweigand [this message]
2007-05-03 14:51 ` Luis Machado
2007-05-06 21:20 ` Ulrich Weigand
2007-05-07 15:14 ` Luis Machado
2007-05-07 18:11 ` Ulrich Weigand
2007-05-07 19:28 ` Luis Machado
2007-05-07 22:47 ` Ulrich Weigand
2007-05-07 23:23 ` Luis Machado
2007-05-08 12:50 ` Ulrich Weigand
2007-05-09 14:33 ` Ulrich Weigand
2007-05-09 18:05 ` Luis Machado
2007-05-09 18:12 ` Daniel Jacobowitz
2007-05-09 18:21 ` Luis Machado
2007-05-09 18:34 ` Jan Kratochvil
2007-05-09 18:46 ` Daniel Jacobowitz
2007-05-09 19:10 ` Ulrich Weigand
2007-05-09 19:14 ` Luis Machado
2007-05-10 10:57 ` Emi SUZUKI
2007-05-10 21:31 ` Ulrich Weigand
2007-05-10 21:36 ` Daniel Jacobowitz
2007-05-10 22:58 ` Ulrich Weigand
2007-05-10 23:25 ` Daniel Jacobowitz
2007-05-11 7:34 ` Emi SUZUKI
2007-05-11 12:46 ` Ulrich Weigand
2007-05-09 19:45 ` Ulrich Weigand
2007-05-10 0:48 ` Luis Machado
2007-05-10 20:29 ` Ulrich Weigand
2007-04-09 2:13 Patch for gdb build on hppa hp-ux Daniel Jacobowitz
2007-04-09 23:25 ` Steve Ellcey
2007-04-10 12:05 ` Daniel Jacobowitz
2007-04-10 19:03 ` Eli Zaretskii
2007-04-10 20:22 ` Daniel Jacobowitz
2007-04-13 14:04 ` Daniel Jacobowitz
2007-04-13 17:07 ` [patch] "single step" atomic instruction sequences as a whole on PPC Luis Machado
2007-04-28 23:34 ` [RFC] " Luis Machado
2007-04-28 23:45 ` Ulrich Weigand
2007-04-29 1:53 ` Luis Machado
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=200705021408.l42E8Qc0019267@dyn-9-152-216-62.boeblingen.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=luisgpm@linux.vnet.ibm.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