Re: [PATCH] ia64 oprofile support for 2.6.0-test4

[Will Cohen <wcohen@redhat.com>]

David Mosberger wrote:
>>>>>>On Tue, 26 Aug 2003 16:42:27 -0400, Will Cohen <wcohen@redhat.com> said:
>>>>>
> 
>   Will> +	eip = instruction_pointer(regs);
> 
> eip?  How about calling it "ip", which is the register name and what's
> used everywhere else in the ia64 tree.
> 
>   Will> +/*
>   Will> + * We use the ia64_psr(regs)->ri to determine which of the three
>   Will> + * instructions in bundle took the sample. The instructions in the
>   Will> + * ia64 do not fall on nice four byte boundaries, so there is no point
>   Will> + * in multiplying ia64_psr(regs)->ri by 4.
>   Will> + */
>   Will> +#define instruction_pointer(regs) ((regs)->cr_iip + ia64_psr(regs)->ri)
> 
> How are you going to get instruction-level precision with this?

I looked at gdb handled this. It appeared for setting break points and 
disassembling code gdb handles the instructions in the bundle in this 
manner. Putting the instruction number as the low bits in the address, 
0, 1, or 2.

> Given this:
> 
>   Will> -	ip >>= prof_shift;
> 
> you'd have to use a prof_shift of 0, which is wasteful.  If you
> multiply ri by 4, you can use a prof_shift of 2, reducing the
> histogram size by a factor of 4 while still getting instruction-level
> accuracy.

> I can see why you don't want to do the multiply-by-four in
> instruction_pointer(), but if that's what you want to avoid, I think
> ia64_do_profile() should should do it so we can get the desired
> effect.
> 
> 	--david

For OProfile it didn't make a difference, but for the histograms it is 
wasteful. I didn't think about the impact on the traditional histogram. 
There are two different ways that the instructions within a bundle are 
being handled: gdb and the kernel profiling code. I chose the gdb approach.

Do the histogram analysis tools currently handle the fiction of bundle 
instruction 0 at address ending in 0, bundle instruction 1 ending in 4, 
and bundle instruction 2 in 8? GDB doesn't.

-Will