Re: [PATCH V2 1/4] perf: Add hardware breakpoint address mask

[Will Deacon <will.deacon@arm.com>]

Hi Jacob,

On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
> On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> > On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> > >>
> > >> The downside is that in userland perf tool we need differing documentation
> > >> on what the mask syntax means for each architecture.
> > > 
> > > Personally I think this is acceptable.
> > > 
> > > But I am new to this code, so...
> > > 
> > 
> > That would seem really, really awkward.  Yes, perf has a bunch of
> > low-level stuff, but it would seem highly undesirable to force the user
> > to deal with something like that.
> > 
> > It would be good to have a user-friendly syntax that covers most of what
> > users may want to do and perhaps a longer form that can express
> > everything including ARM's byte selects; if the system can't honor the
> > request it should return an error.
> 
> Okay,
> 
> If arch specific masks are a no go, then I think I'm convinced that
> Oleg's idea of using bp_len is the right thing to do. Right now perf
> userland tool hard codes bp_len to 4, so I need to modify it to allow
> user to override the length if desired.

So what value ends up in the bp_len field: a length or a mask? I just want
to make sure it's flexible enough that, if we add another user interface for
the byte-select stuff, we don't need to butcher the attr in another way.

> Oleg, Frederic, et al.
> 
> Which syntax do you prefer?
> 
> If we want to set bp_len to 16:
> 
>   $ perf stat -e mem:0x1000:rw:16
> 
> Or
> 
>   $ perf stat -e mem:0x1000:16
> 
> Or
> 
>   $ perf stat -e mem:0x1000/16
> 
> If no bp_len value is specified, it will still default to 4 as it did
> before.

I certainly like the ability to change the length of an execute breakpoint,
as that helps for halfword instructions on ARM (not sure if your first
syntax precludes that, but just checking...).

Will