public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Jonas Zaddach <zaddach@eurecom.fr>
Cc: gdb@sourceware.org
Subject: Re: How to configure GDB for software single-stepping on an ARM remote stub
Date: Thu, 31 May 2012 10:27:00 -0000	[thread overview]
Message-ID: <4FC74796.5070504@redhat.com> (raw)
In-Reply-To: <CAH9P7YzW6DomHkTYAYv9SZRcRhjUOc9JE2NRJ=2PPtHg1DkWFQ@mail.gmail.com>

On 05/31/2012 11:02 AM, Jonas Zaddach wrote:

> Hi,
> 
> I have written a remote stub for some ARM hardware that supports just
> memory breakpoints (the device does not have a hardware debugging
> unit). I figured out that I need single-stepping to go around
> breakpoints, 


Or more fundamentally, for all stepping, right?

> and that there is support for software single-stepping in
> the code ... but I have no idea on how to tell GDB that I want
> software single-stepping on my target. Can you give me a hint how to
> do it or where to look for documentation?


Unfortunately, GDB is not smart enough to figure out the target can't
single-step, and that it needs to do it itself with software
single-stepping.
The current way is that GDB hardcodes knowledge of when does the target
need it; it depends on architecture, for example, on ARM and MIPS, gdb
assumes the target can step, and then knows that if the target is running
Linux, it needs software stepping.  On other archs, knowing that no chip
was or will be built with hardware debugging smarts, GDB always uses
software stepping.  The simplest is to use a hack like below to force your
GDB to assume software stepping is necessary.  The best would be to make
GDB smarter.

 gdb/arm-tdep.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index df5dea7..829cb5c 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -10122,6 +10122,8 @@ arm_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
 		      _("arm_gdbarch_init: bad byte order for float format"));
     }

+  set_gdbarch_software_single_step (gdbarch, arm_software_single_step);
+
   /* On ARM targets char defaults to unsigned.  */
   set_gdbarch_char_signed (gdbarch, 0);

  reply	other threads:[~2012-05-31 10:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 10:03 Jonas Zaddach
2012-05-31 10:27 ` Pedro Alves [this message]
2012-05-31 10:48   ` Jonas Zaddach

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=4FC74796.5070504@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=zaddach@eurecom.fr \
    /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).