ARM7, remote GDB, Software Breakpoints

ARM7, remote GDB, Software Breakpoints

[Torsten Mohr]

Hi,

i have several questions related to the GDB remote protocol
server i wrote ( http://www.s.netic.de/tmohr/pppcb-0.5.0.tar.bz2 ),
it would be great if someone could give me some hints.


1. I could handle HW breakpoints, how can i tell GDB that it should
use HW breakpoints?  Just answering requests for SW breakpoints with
"ENN" doesn't seem to make GDB use HW breakpoints.


2. When i use SW breakpoints and download and start a program on
the target, first the program is downloaded and then the SW
breakpoints are set.  SW breakpoints are done by replacing the
instruction at that address with a "breakpoint instruction".
When the program stops on a "breakpoint instruction", and i
then do a "step" or "continue", that original instruction is
NOT EXECUTED, it seems i have to restore that value temporarily,
do a "single step" and put back that "breakpoint instruction"
again, right?
From watching the communication between target and server i assume
it is like this, i just want to make sure this is the way to handle
it and i don't miss anything.


3. Thumb mode is not handled at all at the moment, what do i need
to do to handle Thumb mode?
If GDB downloads a program into the target and sets the PC to a
certain address, how does my server know if it should execute this
in ARM or in Thumb mode?


Best regards,
Torsten.

Re: ARM7, remote GDB, Software Breakpoints

[Quality Quorum]

On Wed, 12 Feb 2003, Torsten Mohr wrote:

> Hi,
>
> i have several questions related to the GDB remote protocol
> server i wrote ( http://www.s.netic.de/tmohr/pppcb-0.5.0.tar.bz2 ),
> it would be great if someone could give me some hints.
>
>
> 1. I could handle HW breakpoints, how can i tell GDB that it should
> use HW breakpoints?  Just answering requests for SW breakpoints with
> "ENN" doesn't seem to make GDB use HW breakpoints.

You have to implement commands starting with 'Z' and 'z' in order to
support hw breakpoints.

>
>
> 2. When i use SW breakpoints and download and start a program on
> the target, first the program is downloaded and then the SW
> breakpoints are set.  SW breakpoints are done by replacing the
> instruction at that address with a "breakpoint instruction".
> When the program stops on a "breakpoint instruction", and i
> then do a "step" or "continue", that original instruction is
> NOT EXECUTED, it seems i have to restore that value temporarily,
> do a "single step" and put back that "breakpoint instruction"
> again, right?
> >From watching the communication between target and server i assume
> it is like this, i just want to make sure this is the way to handle
> it and i don't miss anything.


It is very strange, because gdb works exactly this way. I am wondering do
you have 'step' command implemented?

>
>
> 3. Thumb mode is not handled at all at the moment, what do i need
> to do to handle Thumb mode?
> If GDB downloads a program into the target and sets the PC to a
> certain address, how does my server know if it should execute this
> in ARM or in Thumb mode?
>
>
> Best regards,
> Torsten.
>

Thanks,

Aleksey

Re: ARM7, remote GDB, Software Breakpoints

[Torsten Mohr]

Hi,

thanks for your hint.

> > 1. I could handle HW breakpoints, how can i tell GDB that it should
> > use HW breakpoints?  Just answering requests for SW breakpoints with
> > "ENN" doesn't seem to make GDB use HW breakpoints.
>
> You have to implement commands starting with 'Z' and 'z' in order to
> support hw breakpoints.

Yes, i do that.  According to GDB remote protocol, when i answer
a request for "Z0..." with "ENN" (means "i can't handle software
breakpoints"), GDB doesn't try hardware breakpoints.

But maybe, when i have some hardware that doesn't run in RAM,
but in Flash-ROM, i think i'd rather like to have HW breakpoints.
Also, when i don't answer with "ENN", but with "" (empty),
GDB doesn't try HW breakpoints.


> It is very strange, because gdb works exactly this way. I am wondering do
> you have 'step' command implemented?

Oops, my misinterpretation of that protocol.  Yes, it just works
as it is.  Great.


> > 3. Thumb mode is not handled at all at the moment, what do i need
> > to do to handle Thumb mode?
> > If GDB downloads a program into the target and sets the PC to a
> > certain address, how does my server know if it should execute this
> > in ARM or in Thumb mode?


Thanks,
Torsten.

Re: ARM7, remote GDB, Software Breakpoints

[Daniel Jacobowitz]

On Wed, Feb 12, 2003 at 09:17:58PM +0100, Torsten Mohr wrote:
> Hi,
> 
> thanks for your hint.
> 
> > > 1. I could handle HW breakpoints, how can i tell GDB that it should
> > > use HW breakpoints?  Just answering requests for SW breakpoints with
> > > "ENN" doesn't seem to make GDB use HW breakpoints.
> >
> > You have to implement commands starting with 'Z' and 'z' in order to
> > support hw breakpoints.
> 
> Yes, i do that.  According to GDB remote protocol, when i answer
> a request for "Z0..." with "ENN" (means "i can't handle software
> breakpoints"), GDB doesn't try hardware breakpoints.
> 
> But maybe, when i have some hardware that doesn't run in RAM,
> but in Flash-ROM, i think i'd rather like to have HW breakpoints.
> Also, when i don't answer with "ENN", but with "" (empty),
> GDB doesn't try HW breakpoints.

This was touched recently.  The remote logic decides that 0 hardware
breakpoint resources are available; I don't remember if the patch to
fix it was checked in.  You might want to ask Andrew if he remembers
the problem.

There's probably something in the host gdb you have to set.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: ARM7, remote GDB, Software Breakpoints

[Quality Quorum]

On Wed, 12 Feb 2003, Torsten Mohr wrote:

> Hi,
>
> thanks for your hint.
>
> > > 1. I could handle HW breakpoints, how can i tell GDB that it should
> > > use HW breakpoints?  Just answering requests for SW breakpoints with
> > > "ENN" doesn't seem to make GDB use HW breakpoints.
> >
> > You have to implement commands starting with 'Z' and 'z' in order to
> > support hw breakpoints.
>
> Yes, i do that.  According to GDB remote protocol, when i answer
> a request for "Z0..." with "ENN" (means "i can't handle software
> breakpoints"), GDB doesn't try hardware breakpoints.

As far as understand in order to set hw-breakpoint, user should explicitly
say that he/she wants hw-breakpoint (I do not remember precise syntax), '
'breakpoint' is always a software breakpoint.

>
> But maybe, when i have some hardware that doesn't run in RAM,
> but in Flash-ROM, i think i'd rather like to have HW breakpoints.
> Also, when i don't answer with "ENN", but with "" (empty),
> GDB doesn't try HW breakpoints.
>
>
> > It is very strange, because gdb works exactly this way. I am wondering do
> > you have 'step' command implemented?
>
> Oops, my misinterpretation of that protocol.  Yes, it just works
> as it is.  Great.
>
>
> > > 3. Thumb mode is not handled at all at the moment, what do i need
> > > to do to handle Thumb mode?
> > > If GDB downloads a program into the target and sets the PC to a
> > > certain address, how does my server know if it should execute this
> > > in ARM or in Thumb mode?
>
>
> Thanks,
> Torsten.
>

Thanks,

Aleksey

Re: ARM7, remote GDB, Software Breakpoints

[Steven Johnson]

>
>
>This was touched recently.  The remote logic decides that 0 hardware
>breakpoint resources are available; I don't remember if the patch to
>fix it was checked in.  You might want to ask Andrew if he remembers
>the problem.
>
>There's probably something in the host gdb you have to set.
>
>  
>

Very recently, I posted a patch to the gdb patches list, that allows the 
user to set the number of hardware breakpoints and watchpoints their 
target supports by way of commands within GDB.  I never received any 
feedback for it, so I don't know what status it is.

I also tackeled it defferently.  In my stub, when I set a breakpoint I 
Favour Hardware breakpints (because I think they are better).  So if gdb 
tells the stub to set a breakpoint, regardless of type, then I set 
hardware breakpoints until they are exhausted, and then I fall back to 
software breakpoints.  If GDB explicitly tells my stub to set hardware 
breakpoints it sets these first. (And then falls back to software).  So 
basically I prioritise breakpoints and use what GDB tells the stub as a 
hint, so:

1. Set GDB Requested Hardware Breakpoints first.
2. Set GDB Requested Software Breakpoints second.
3. Until all hardware breakpoints are consumed, set hardware breakpoints.
4. When all hardware breakpoints are consumed revert to software 
breakpoints.

This works really well for me.  The only thing the user has to be 
carefull of is not setting too many breakpoints when debugging in ROM. 
 But if your not carefull enough to do this, your probably not capable 
of debugging ROM based code anyway :)

Steven Johnson

Re: ARM7, remote GDB, Software Breakpoints

[Andrew Cagney]

> 
> This was touched recently.  The remote logic decides that 0 hardware
> breakpoint resources are available; I don't remember if the patch to
> fix it was checked in.  You might want to ask Andrew if he remembers
> the problem.

I'm tracking it in the bug database.  I've also a second equivalent 
patch - need to compare.

StevenJ's description matches one I gave earlier.

Andrew