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);
>
prev parent 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).