How to configure GDB for software single-stepping on an ARM remote stub

How to configure GDB for software single-stepping on an ARM remote stub

[Jonas Zaddach]

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, 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?

Thank you, Jonas

Re: How to configure GDB for software single-stepping on an ARM remote stub

[Pedro Alves]

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);

Re: How to configure GDB for software single-stepping on an ARM remote stub

[Jonas Zaddach]

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);
>