Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


       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