Hardware breakpoints when using i386 simulator

Hardware breakpoints when using i386 simulator

[David Welch]

Hi,

I'm using gdb 5.0 to debug an os kernel running on an i386 simulator
called bochs. The bochs remote stub supports hardware breakpoints but
instead of sending a request, gdb tries to set breakpoints as if the
program was running locally. I'd like to fix this, my initial idea was
that i386_insert_watchpoint should check if the current target is a remote
one and call remote_insert_watchpoint. Is this the right approach? 

TIA,
David Welch

Re: Hardware breakpoints when using i386 simulator

[Andrew Cagney]

David Welch wrote:
> 
> Hi,
> 
> I'm using gdb 5.0 to debug an os kernel running on an i386 simulator
> called bochs. The bochs remote stub supports hardware breakpoints but
> instead of sending a request, gdb tries to set breakpoints as if the
> program was running locally. I'd like to fix this, my initial idea was
> that i386_insert_watchpoint should check if the current target is a remote
> one and call remote_insert_watchpoint. Is this the right approach?

Hardware breakpoints or watchpoints?

For breakpoints, GDB should first try a ``Z'' packet and then, only if
that fails, fall back to a memory breakpoint.

Use ``set debug remote 1''  before trying to set a breakpoint to see if
this is happening.

For watchpoints, these are still (unfortunatly) determined at compile
time (bug).  Your target (what was it?) may not have them enabled. 
Hardware watchpoint configury needs to be added to the gdbarch vector.

Have a look at remote.c and the macro TARGET_HAS_HARDWARE_WATCHPOINTS.

	Andrew

Re: Hardware breakpoints when using i386 simulator

[Fernando Nasser]

Andrew Cagney wrote:
> 
> David Welch wrote:
> >
> > Hi,
> >
> > I'm using gdb 5.0 to debug an os kernel running on an i386 simulator
> > called bochs. The bochs remote stub supports hardware breakpoints but
> > instead of sending a request, gdb tries to set breakpoints as if the
> > program was running locally. I'd like to fix this, my initial idea was
> > that i386_insert_watchpoint should check if the current target is a remote
> > one and call remote_insert_watchpoint. Is this the right approach?
> 
> Hardware breakpoints or watchpoints?
> 
> For breakpoints, GDB should first try a ``Z'' packet and then, only if
> that fails, fall back to a memory breakpoint.
> 
> Use ``set debug remote 1''  before trying to set a breakpoint to see if
> this is happening.
> 
> For watchpoints, these are still (unfortunatly) determined at compile
> time (bug).  Your target (what was it?) may not have them enabled.
> Hardware watchpoint configury needs to be added to the gdbarch vector.
> 

Right.  I am adding it soon. 

In the meanwhile, add to your local copy of the config/i386/tm-embed.h the following
horrible hack:

#define target_insert_watchpoint(ADDR, LEN, TYPE) \
        remote_insert_watchpoint (ADDR, LEN, TYPE)

extern int remote_insert_watchpoint (CORE_ADDR addr, int len, int type);

#define target_remove_watchpoint(ADDR, LEN, TYPE) \
        remote_remove_watchpoint (ADDR, LEN, TYPE)

extern int remote_remove_watchpoint (CORE_ADDR addr, int len, int type);



> Have a look at remote.c and the macro TARGET_HAS_HARDWARE_WATCHPOINTS.
> 

You have to define that as well... 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: Hardware breakpoints when using i386 simulator

[David Welch]

In message < 398031EE.14D2D017@cygnus.com > Fernando Nasser <fnasser@cygnus.com> writes:
> Andrew Cagney wrote:
> > 
> > Hardware breakpoints or watchpoints?
> > 
Watchpoints, sorry for the confusion. 

> > For watchpoints, these are still (unfortunatly) determined at compile
> > time (bug).  Your target (what was it?) may not have them enabled.
> > Hardware watchpoint configury needs to be added to the gdbarch vector.
> > 
> 
> Right.  I am adding it soon. 
> 
> In the meanwhile, add to your local copy of the config/i386/tm-embed.h the 
> following horrible hack:
> 
[...]
>
I did approximately what you suggest and it seems to work quite well.