Getting the i386 watchpoints into the taget vector?

Getting the i386 watchpoints into the taget vector?

[Andrew Cagney]

Hello,

With the watchpoint interface made part of the target vector, its time 
to think about how the i386 case should be handled.  Instead of using a 
system interface, the i386 manipulates the hardware watchpoint registers 
directly.  For want of a better name, I'll call this ``native watchpoints''.

One thought is to change the config/i386/nm-i386.h macros to something 
native specific (native_insert_watchpoint()) and then have the various 
native targets (infptrace.c, ...) add these methods to their target vector.

It does restrict things to native targets.  A remote target couldn't 
make use of GDB's built-in knowledge of watchpoint registers.

Another (less well thought out) idea, is for the target stack, to fall 
back to the ``native watchpoint'' mechanism when the [remote] target 
doesn't support watchpoints. I think this would mean putting the 
``native watchpoint'' methods in the architecture vector where the 
target vector code could call it.

Thoughts?  Better ideas?

Andrew

Re: Getting the i386 watchpoints into the taget vector?

[Kevin Buettner]

On Sep 19,  9:57pm, Andrew Cagney wrote:

> Another (less well thought out) idea, is for the target stack, to fall 
> back to the ``native watchpoint'' mechanism when the [remote] target 
> doesn't support watchpoints. I think this would mean putting the 
> ``native watchpoint'' methods in the architecture vector where the 
> target vector code could call it.

Assuming a remote target, I can see that this would work in situations
where you have access to the hardware breakpoint registers via the
remote protocol.  However, in situations where the ``native watchpoint''
mechanism consists of funky ptrace() calls (or the like), this clearly
won't work.  (E.g, I don't think this could be made to work for
Linux/IA-64.)

Kevin

Re: Getting the i386 watchpoints into the taget vector?

[Paul Koning]

>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:

 Andrew> One thought is to change the config/i386/nm-i386.h macros to
 Andrew> something native specific (native_insert_watchpoint()) and
 Andrew> then have the various native targets (infptrace.c, ...) add
 Andrew> these methods to their target vector.

 Andrew> It does restrict things to native targets.  A remote target
 Andrew> couldn't make use of GDB's built-in knowledge of watchpoint
 Andrew> registers.

General comment: for an embedded systems developer, it's a constant
source of bafflement to trip over gdb features that don't work in a
remote-target setting.  It sure would be nice if the number of such
cases were going down, not up, over time.

      paul

Re: Getting the i386 watchpoints into the taget vector?

[Andrew Cagney]

>>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
> 
>  Andrew> One thought is to change the config/i386/nm-i386.h macros to
>  Andrew> something native specific (native_insert_watchpoint()) and
>  Andrew> then have the various native targets (infptrace.c, ...) add
>  Andrew> these methods to their target vector.
> 
>  Andrew> It does restrict things to native targets.  A remote target
>  Andrew> couldn't make use of GDB's built-in knowledge of watchpoint
>  Andrew> registers.
> 
> General comment: for an embedded systems developer, it's a constant
> source of bafflement to trip over gdb features that don't work in a
> remote-target setting.  It sure would be nice if the number of such
> cases were going down, not up, over time.

Can you document or bug report them?  Of hand I can only think of gcore 
(and that largely requires someone to perform the leg work).

Andrew

Re: Getting the i386 watchpoints into the taget vector?

[Eli Zaretskii]

> Date: Thu, 19 Sep 2002 21:57:40 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
> 
> Instead of using a system interface, the i386 manipulates the
> hardware watchpoint registers directly.

Really?  What I see is that most i386 ports use ptrace or similar
interfaces to access the hardware watchpoints.  So in what sense is
this manipulation ``direct''?

> One thought is to change the config/i386/nm-i386.h macros to something 
> native specific (native_insert_watchpoint()) and then have the various 
> native targets (infptrace.c, ...) add these methods to their target vector.
> 
> It does restrict things to native targets.  A remote target couldn't 
> make use of GDB's built-in knowledge of watchpoint registers.
> 
> Another (less well thought out) idea, is for the target stack, to fall 
> back to the ``native watchpoint'' mechanism when the [remote] target 
> doesn't support watchpoints. I think this would mean putting the 
> ``native watchpoint'' methods in the architecture vector where the 
> target vector code could call it.

Why not simply allow remote targets define the watchpoint-related
macros?  Let their definitions issue remote packets that will cause
the target end DTRT.  As long as the target is a i386-compatible
machine, the internal bookkeeping we have in the current code will
work.

Am I missing something?

Re: Getting the i386 watchpoints into the taget vector?

[Andrew Cagney]

>> Date: Thu, 19 Sep 2002 21:57:40 -0400
>> From: Andrew Cagney <ac131313@ges.redhat.com>
>> 
>> Instead of using a system interface, the i386 manipulates the
>> hardware watchpoint registers directly.
> 
> 
> Really?  What I see is that most i386 ports use ptrace or similar
> interfaces to access the hardware watchpoints.  So in what sense is
> this manipulation ``direct''?

(Probably bad choice of words).

GDB can implement watchpoints, for a remote target, using two mechanism:

- sending the remote target the watchpoint request (the Z packet) and 
let the remote target implement the details

- manipulate the h/w watchpoint registers directly, sending the remote 
target register read/write operations - what I believe i386-nat.c does.

The native equivalents are roughly:

- use some sort of custom h/w watchpoint kernel interface

- use ptrace(PT_GETREGS) / ptrace (PT_SETREGS)


>> One thought is to change the config/i386/nm-i386.h macros to something 
>> native specific (native_insert_watchpoint()) and then have the various 
>> native targets (infptrace.c, ...) add these methods to their target vector.
>> 
>> It does restrict things to native targets.  A remote target couldn't 
>> make use of GDB's built-in knowledge of watchpoint registers.
>> 
>> Another (less well thought out) idea, is for the target stack, to fall 
>> back to the ``native watchpoint'' mechanism when the [remote] target 
>> doesn't support watchpoints. I think this would mean putting the 
>> ``native watchpoint'' methods in the architecture vector where the 
>> target vector code could call it.
> 
> 
> Why not simply allow remote targets define the watchpoint-related
> macros?  Let their definitions issue remote packets that will cause
> the target end DTRT.  As long as the target is a i386-compatible
> machine, the internal bookkeeping we have in the current code will
> work.

I'm not sure what you mean here.  If we used macro's then they would run 
afowl of trying to make everything multi-arch.

Andrew

PS: Someone should implement the equivalent sim commands.  sim/common 
has a watchpoint framework.  Just needs the sim<->gdb interface.

Re: Getting the i386 watchpoints into the taget vector?

[Eli Zaretskii]

> Date: Fri, 20 Sep 2002 19:51:53 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
> 
> GDB can implement watchpoints, for a remote target, using two mechanism:
> 
> - sending the remote target the watchpoint request (the Z packet) and 
> let the remote target implement the details
> 
> - manipulate the h/w watchpoint registers directly, sending the remote 
> target register read/write operations - what I believe i386-nat.c does.

It doesn't really matter, IMHO, which way we choose to go.  What is
important is that we provide in GDB a module that can be used by i386
targets, either native or remote, and that this module has the same
machinery that is now implemented for native i386 debugging.  To wit,
the replica of the machine debug registers should be maintained by
that module, and it should use reference counts to allow sharing of
debug registers between different watchpoints.

In other words, if we go the first way, target ends should not need
to invent the implementation, but instead should call functions in a
module supplied as part of the GDB sources.