Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH v3 08/10] Support software single step on ARM in GDBServer.
Date: Thu, 26 Nov 2015 12:48:00 -0000	[thread overview]
Message-ID: <86ziy1vsdr.fsf@gmail.com> (raw)
In-Reply-To: <1448287968-12907-9-git-send-email-antoine.tremblay@ericsson.com>	(Antoine Tremblay's message of "Mon, 23 Nov 2015 09:12:46 -0500")

Antoine Tremblay <antoine.tremblay@ericsson.com> writes:

> Limitations :
>
> GDBServer can't step over a sigreturn or rt_sigreturn syscall since this would
> require the DWARF information to identify the caller PC. This situation
> only prints a warning for the moment.

They are using frame not DWARF to identify the PC, however, it is not
necessary.  When GDB or GDBserver is doing software single step, it must
be in the inner-most frame, so we can get the caller PC by examining the
stack at a certain offset from SP (from regcache), like what are doing in
arm_linux_sigreturn_init and arm_linux_rt_sigreturn_init, rather than
replying frame unwinding.  See my comments to arm_get_next_pcs_syscall_next_pc.

> +
> +/* Wrapper over syscall_next_pc for use in get_next_pcs.  */
> +
> +CORE_ADDR
> +arm_get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self, CORE_ADDR pc)
> +{
> +  struct arm_gdb_get_next_pcs *next_pcs = (struct arm_gdb_get_next_pcs *) self;
> +  struct gdbarch_tdep *tdep;
> +
> +  tdep = gdbarch_tdep (next_pcs->gdbarch);
> +  if (tdep->syscall_next_pc != NULL)
> +    return tdep->syscall_next_pc (next_pcs->frame);
> +
> +  return 0;
> +}
> +


> +/* When PC is at a syscall instruction, return the PC of the next
> +   instruction to be executed.  */
> +static CORE_ADDR
> +get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self, CORE_ADDR pc)
> +{
> +  CORE_ADDR return_addr = 0;
> +  int is_thumb = self->is_thumb;
> +  ULONGEST svc_number = 0;
> +
> +  if (is_thumb)
> +    {
> +      svc_number = self->ops->collect_register_unsigned (self, 7);
> +      return_addr = pc + 2;
> +    }
> +  else
> +    {
> +      unsigned long this_instr = self->ops->read_memory_unsigned_integer
> +	((CORE_ADDR) pc, 4, self->byte_order_for_code);
> +
> +      unsigned long svc_operand = (0x00ffffff & this_instr);
> +      if (svc_operand)  /* OABI.  */
> +	{
> +	  svc_number = svc_operand - 0x900000;
> +	}
> +      else /* EABI.  */
> +	{
> +	  svc_number = self->ops->collect_register_unsigned (self, 7);
> +	}
> +
> +      return_addr = pc + 4;
> +    }
> +
> +  /* Is this a sigreturn or rt_sigreturn syscall?
> +     If so it is currently not handeled.  */
> +  if (svc_number == 119 || svc_number == 173)
> +    {
> +      if (debug_threads)
> +	debug_printf ("Unhandled sigreturn or rt_sigreturn syscall\n");

We can still compute the caller pc by examining stack.

> +    }
> +
> +  /* Addresses for calling Thumb functions have the bit 0 set.  */
> +  if (is_thumb)
> +    return_addr = MAKE_THUMB_ADDR (return_addr);
> +
> +  return return_addr;
> +}
>  

This leads me thinking more about current software single step code in
GDB.  In GDB side, we are using frame to access registers, while in
GDBserver, we are using regcache.  Why don't we use regcache in both
sides? so that the "struct arm_get_next_pcs_ops" can be simplified, for
example, field collect_register_unsigned may be no longer necessary.

In fact, software_single_step used to have regcache argument, added by
https://sourceware.org/ml/gdb-patches/2007-04/msg00218.html but we
changed to argument frame
https://sourceware.org/ml/gdb-patches/2007-04/msg00218.html  IMO, it is
better to use regcache than frame.  We have two options,

 #1, switch from frame apis to regcache apis to access registers in arm
  software single step.  We can get regcache by get_current_regcache ().
 #2, change argument of gdbarch method software_single_step from frame
  to regcache, which means all its implementations need update, and
  switch to regcache apis to access registers.

#2 is the right way to go in long term, and we really need to improve
software_single_step.  Let me what do you think.

-- 
Yao (齐尧)


  parent reply	other threads:[~2015-11-26 12:48 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 14:14 [PATCH v3 0/10] Support software single step and conditional breakpoints " Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 01/10] Fix breakpoint size when stepping over a permanent breakpoint " Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 03/10] Refactor queries for hardware and software single stepping support " Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 07/10] Share some ARM target dependant code from GDB with GDBServer Antoine Tremblay
2015-11-25 17:01   ` Yao Qi
2015-11-26 10:38   ` Yao Qi
2015-11-26 13:56     ` Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 02/10] Fix instruction skipping when using software single step in GDBServer Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 09/10] Enable software single stepping for while-stepping actions " Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 04/10] Remove support for thread events without PTRACE_EVENT_CLONE " Antoine Tremblay
2015-11-25 16:48   ` Yao Qi
2015-11-25 17:42     ` Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 05/10] Remove too simple breakpoint_reinsert_addr implementations Antoine Tremblay
2015-11-23 14:14 ` [PATCH v3 06/10] Replace breakpoint_reinsert_addr by get_next_pcs operation in GDBServer Antoine Tremblay
2015-11-26 10:30   ` Yao Qi
2015-11-26 13:48     ` Antoine Tremblay
2015-11-26 10:50   ` Pedro Alves
2015-11-26 13:50     ` Antoine Tremblay
2015-11-23 14:15 ` [PATCH v3 10/10] Enable conditional breakpoints for targets that support software single step " Antoine Tremblay
2015-11-26 10:25   ` Yao Qi
2015-11-26 15:34     ` Antoine Tremblay
2015-12-03  9:50       ` Yao Qi
2015-11-23 14:15 ` [PATCH v3 08/10] Support software single step on ARM " Antoine Tremblay
2015-11-26 10:49   ` Pedro Alves
2015-11-26 13:35     ` Antoine Tremblay
2015-11-26 12:48   ` Yao Qi [this message]
2015-11-26 15:12     ` Antoine Tremblay
2015-11-26 16:04       ` Yao Qi
2015-11-26 16:07         ` Antoine Tremblay
2015-11-27 13:45           ` Antoine Tremblay
2015-11-27 15:15             ` Yao Qi
2015-11-27 15:35               ` Antoine Tremblay
2015-11-27  9:27 ` [PATCH v3 0/10] Support software single step and conditional breakpoints " Yao Qi
2015-11-27 13:16   ` Antoine Tremblay
2015-11-30 20:21     ` Antoine Tremblay
2015-12-01  9:33     ` Yao Qi
2015-12-01 13:00       ` Antoine Tremblay

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=86ziy1vsdr.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=antoine.tremblay@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    /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