Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Luis Machado via Gdb <gdb@sourceware.org>
To: Nicholas Piggin <npiggin@gmail.com>, gdb@sourceware.org
Subject: Re: [RFC PATCH] gdb: powerpc: Provide an option to disable single step atomic heuristic
Date: Mon, 4 Mar 2024 15:41:08 +0000	[thread overview]
Message-ID: <8073df5c-d0fd-49ac-bf07-ad4313bc6746@arm.com> (raw)
In-Reply-To: <20240222055246.879454-1-npiggin@gmail.com>

Hi,

On 2/22/24 05:52, Nicholas Piggin via Gdb wrote:
> gdb tries to step over atomic (larx/stcx.) sequences because stepping
> through them tends to clear the reservation and prevent forward
> progress.
> 
> More specialised targets like an emulator or hardware debug interface
> can support single stepping without clearing reservation. It would be
> nice to permit atomic sequences to be stepped into as an option. QEMU
> can do this, for example.
> 
> Other targets not just powerpc could have the same issue, so not sure
> whether it would make sense to be a generic option, or if it's such a
> niche case that it's not worthwhile.
> 
> Also, would there be a way to describe this capability to a gdb client
> in the protocol?
> 

I think you'd need some way to tell gdb that it can skip registering the atomic-stepping hook.

While that is easy for a remote target to do, it may be a bit more complex to convey that information if, say,
gdb is running within a system QEMU instance and you want QEMU to handle the atomic sequence and tell gdb it
doesn't need to bother with additional atomic-stepping logic.

So it needs to be something that works both for remote targets and for native targets, like a flag in /proc/<pid>/*
, some register value and so on.

I don't have a strong opinion on whether this should be a generic setting or not. If QEMU can do it for multiple architectures,
then it may make sense to make it generic. Otherwise a ppc-specific option would work OK.

> Thanks,
> Nick
> ---
>  gdb/rs6000-tdep.c | 36 ++++++++++++++++++++++++++++++++++--
>  1 file changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
> index c8450345be2..e911abc7604 100644
> --- a/gdb/rs6000-tdep.c
> +++ b/gdb/rs6000-tdep.c
> @@ -153,6 +153,9 @@ static const char *const powerpc_vector_strings[] =
>  static enum powerpc_vector_abi powerpc_vector_abi_global = POWERPC_VEC_AUTO;
>  static const char *powerpc_vector_abi_string = "auto";
>  
> +/* Single-step tries to step over entire larx/stcx. atomic sequence */
> +static bool powerpc_step_over_atomic = true;
> +
>  /* PowerPC-related per-inferior data.  */
>  
>  static const registry<inferior>::key<ppc_inferior_data> ppc_inferior_data_key;
> @@ -1132,7 +1135,7 @@ ppc_displaced_step_hw_singlestep (struct gdbarch *gdbarch)
>  
>  /* Checks for an atomic sequence of instructions beginning with a
>     Load And Reserve instruction and ending with a Store Conditional
> -   instruction.  If such a sequence is found, attempt to step through it.
> +   instruction.  If such a sequence is found, attempt to step over it.
>     A breakpoint is placed at the end of the sequence.  */
>  std::vector<CORE_ADDR>
>  ppc_deal_with_atomic_sequence (struct regcache *regcache)
> @@ -1143,13 +1146,19 @@ ppc_deal_with_atomic_sequence (struct regcache *regcache)
>    CORE_ADDR breaks[2] = {CORE_ADDR_MAX, CORE_ADDR_MAX};
>    CORE_ADDR loc = pc;
>    CORE_ADDR closing_insn; /* Instruction that closes the atomic sequence.  */
> -  int insn = read_memory_integer (loc, PPC_INSN_SIZE, byte_order);
> +  int insn;
>    int insn_count;
>    int index;
>    int last_breakpoint = 0; /* Defaults to 0 (no breakpoints placed).  */  
>    const int atomic_sequence_length = 16; /* Instruction sequence length.  */
>    int bc_insn_count = 0; /* Conditional branch instruction count.  */
>  
> +  /* global enable option for atomic sequence single step heuristic */
> +  if (!powerpc_step_over_atomic)
> +    return {};
> +
> +  insn = read_memory_integer (loc, PPC_INSN_SIZE, byte_order);
> +
>    /* Assume all atomic sequences start with a Load And Reserve instruction.  */
>    if (!IS_LOAD_AND_RESERVE_INSN (insn))
>      return {};
> @@ -8644,6 +8653,14 @@ show_powerpc_exact_watchpoints (struct ui_file *file, int from_tty,
>    gdb_printf (file, _("Use of exact watchpoints is %s.\n"), value);
>  }
>  
> +static void
> +show_powerpc_step_over_atomic (struct ui_file *file, int from_tty,
> +			       struct cmd_list_element *c,
> +			       const char *value)
> +{
> +  gdb_printf (file, _("Single-step over atomic (larx/stcx.) sequences %s.\n"), value);
> +}
> +
>  /* Read a PPC instruction from memory.  */
>  
>  static unsigned int
> @@ -8787,4 +8804,19 @@ scalar type, thus assuming that the variable is accessed through the address\n\
>  of its first byte."),
>  			   NULL, show_powerpc_exact_watchpoints,
>  			   &setpowerpccmdlist, &showpowerpccmdlist);
> +
> +  add_setshow_boolean_cmd ("step-over-atomic", class_support,
> +			   &powerpc_step_over_atomic,
> +			   _("\
> +Set whether single-step tries to step over atomics."),
> +			   _("\
> +Show whether single-step tries to step over atomics."),
> +			   _("\
> +If true, when GDB single-steps a larx instruction, it will try to find the\n\
> +the matching stcx. instruction and step over the entire atomic sequence.\n\
> +This can be required for forward-progress because single-stepping may clear\n\
> +the reservation. Special environments like emulators and low level hardware\n\
> +debug interfaces may not have this restriction, so this could be disabled."),
> +			   NULL, show_powerpc_step_over_atomic,
> +			   &setpowerpccmdlist, &showpowerpccmdlist);
>  }


  reply	other threads:[~2024-03-04 15:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22  5:52 Nicholas Piggin via Gdb
2024-03-04 15:41 ` Luis Machado via Gdb [this message]
2024-03-05  3:07   ` Nicholas Piggin via Gdb

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=8073df5c-d0fd-49ac-bf07-ad4313bc6746@arm.com \
    --to=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=npiggin@gmail.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