supporting hw break/watch for embedded ppc

supporting hw break/watch for embedded ppc

[John S. Yates, Jr.]

I have an mpc855 remote stub that implements Z0/z0.
This worked entirely as expected.  Auto-detection
used to attempt Z0, discover it was unsupported,
and refrained from ever trying it again.  Naively I
assumed that the remaining Zt variants would behave
similarly.  This is not the case.

So where do I go to enable ppc hw breaks/watches?

/john

Re: supporting hw break/watch for embedded ppc

[Andrew Cagney]

> I have an mpc855 remote stub that implements Z0/z0.
> This worked entirely as expected.  Auto-detection
> used to attempt Z0, discover it was unsupported,
> and refrained from ever trying it again.  Naively I
> assumed that the remaining Zt variants would behave
> similarly.  This is not the case.

It should be the case.

> So where do I go to enable ppc hw breaks/watches?

``set debug remote 1'' to see exactly what the host/target are doing.

Andrew

Re: supporting hw break/watch for embedded ppc

[John S. Yates, Jr.]

> > I have an mpc855 remote stub that implements Z0/z0.
> > This worked entirely as expected.  Auto-detection
> > used to attempt Z0, discover it was unsupported,
> > and refrained from ever trying it again.  Naively I
> > assumed that the remaining Zt variants would behave
> > similarly.  This is not the case.
> 
> It should be the case.
> 
> > So where do I go to enable ppc hw breaks/watches?
> 
> ``set debug remote 1'' to see exactly what the host/target are doing.

Been there.  Done that.

The culprit is remote.c/remote_check_watch_resources
which is hardwired via the earlier definitions:

  int remote_hw_watchpoint_limit = 0;
  int remote_hw_breakpoint_limit = 0;

For now I have added comparisons between chip names
and TARGET_ARCHITECTURE->printable_name along with
corresponding known numbers of resource.  It ain't
pretty but it does work.

Am I missing something?

I do not see a parameterized abstraction here that
would operate off the # of hw breakpoint resources,
the # of hw watchpoint resource and an indication 
that heterogeneous watch sets are supported (see the
"ot" argument to remote_check_watch_resources).

Nor do I see a way to provide a chip-specific
implementation of to_can_use_hw_breakpoint.

(But then I have zero grasp of how architectural
parameterization works.  I just grep and look for
obvious patterns that I can mimic.)

/john

Re: supporting hw break/watch for embedded ppc

[Andrew Cagney]

>> > I have an mpc855 remote stub that implements Z0/z0.
>> > This worked entirely as expected.  Auto-detection
>> > used to attempt Z0, discover it was unsupported,
>> > and refrained from ever trying it again.  Naively I
>> > assumed that the remaining Zt variants would behave
>> > similarly.  This is not the case.
> 
>> 
>> It should be the case.
>> 
> 
>> > So where do I go to enable ppc hw breaks/watches?
> 
>> 
>> ``set debug remote 1'' to see exactly what the host/target are doing.
> 
> 
> Been there.  Done that.
> 
> The culprit is remote.c/remote_check_watch_resources
> which is hardwired via the earlier definitions:
> 
>   int remote_hw_watchpoint_limit = 0;
>   int remote_hw_breakpoint_limit = 0;

Have you tried:

(gdb) help set remote hardware-breakpoint-limit
Set the maximum number of target hardware breakpoints.
Specify a negative limit for unlimited.


> For now I have added comparisons between chip names
> and TARGET_ARCHITECTURE->printable_name along with
> corresponding known numbers of resource.  It ain't
> pretty but it does work.
> 
> Am I missing something?

There is a discussion and thread about improving the way GDB queries the 
target for its level of watchpoint support.  It involves some 
re-aranging of the breakpoints though (look for a thread between my 
self and Eli).

I've been to busy fixing up frames.

Andrew

Re: supporting hw break/watch for embedded ppc

[John S. Yates, Jr.]

----- Original Message ----- 
From: "Andrew Cagney" <ac131313@redhat.com>
Subject: Re: supporting hw break/watch for embedded ppc


> Have you tried:
> 
> (gdb) help set remote hardware-breakpoint-limit
> Set the maximum number of target hardware breakpoints.
> Specify a negative limit for unlimited.

No I had not.  Now that you point it out I do
see the command documented in my most recent
gdb.pdf based on TexInfo 20003-02-03.16.  This
does not seem to reflect the 5.3 sources from
which I am working.  In those the command does
not exit.  (remote_hardware_breakpoint_limit
and remote_hardware_watchpoint_limit do exist
as variables within remote.c but there seems to
be no code to update them.)

/john

Re: supporting hw break/watch for embedded ppc

[Andrew Cagney]

> ----- Original Message ----- 
> From: "Andrew Cagney" <ac131313@redhat.com>
> Subject: Re: supporting hw break/watch for embedded ppc
> 
> 
> 
>> Have you tried:
>> 
>> (gdb) help set remote hardware-breakpoint-limit
>> Set the maximum number of target hardware breakpoints.
>> Specify a negative limit for unlimited.
> 
> 
> No I had not.  Now that you point it out I do
> see the command documented in my most recent
> gdb.pdf based on TexInfo 20003-02-03.16.  This
> does not seem to reflect the 5.3 sources from
> which I am working.

Sounds like a snap of the current doco, does the front page read ``for 
GDB Version YYYYMMDD''?

Andrew

Re: supporting hw break/watch for embedded ppc

[John S. Yates, Jr.]

----- Original Message ----- 
From: "Andrew Cagney" <ac131313@redhat.com>
Subject: Re: supporting hw break/watch for embedded ppc


> Sounds like a snap of the current doco, does the front page read ``for 
> GDB Version YYYYMMDD''?

"Ninth Edition, for gdb version 20030404"

/john