public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jonas Zaddach <zaddach@eurecom.fr>
To: Pedro Alves <palves@redhat.com>
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:48:00 -0000	[thread overview]
Message-ID: <CAH9P7YztaR6BESsv8JpXXt_YmO1TR6ecdpo7uRW_NA54kVoS_Q@mail.gmail.com> (raw)
In-Reply-To: <4FC74796.5070504@redhat.com>

Thank you, that is exactly what I wanted :) I felt a bit stupid since
I thought that there must be some configuration file for it ...
A good way to make this configurable in my opinion would be to allow
the remote stub to reply with an error to the step command, or query
stepping support with a qStepping command, and then switch on software
stepping when needed ... If you think other people are interested in
that I can do a patch.

On Thu, May 31, 2012 at 12:27 PM, Pedro Alves <palves@redhat.com> wrote:
> 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:48 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
2012-05-31 10:48   ` Jonas Zaddach [this message]

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=CAH9P7YztaR6BESsv8JpXXt_YmO1TR6ecdpo7uRW_NA54kVoS_Q@mail.gmail.com \
    --to=zaddach@eurecom.fr \
    --cc=gdb@sourceware.org \
    --cc=palves@redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).