Re: oprofile - ppc

On 03/09/2016 06:47 AM, Ulrik De Bie wrote:
> Hi,
> 
> I already sent this message to Maynard Johnson but since I got no response,
> I post this to this list.

Hi Ulrik,

Maynard retired from IBM  December 2014 and is no longer involved with OProfile.  It is doubtful that he would be reading email sent to the IBM account.

I would like to ensure that oprofile is still works for various processors.  Patches to address this problem will be welcomed.

The patch below looks like it is the right place, but it can't be hard-coded.  There should be a check of uname_info.machine and then a a call to a function that identifies the 32-bit ppc variant.

If you have other patches for oprofile, feel free to send them also.

-Will



> 
> 
> The oprofile 0.9.6 was working good on the ppc e500v2 board, but the
> oprofile 1.0.0 (current git HEAD) was not. I took a look at the
> code and found out that ppc64 cpu detection is possible, but for some
> strange reason ppc(32) detection was left out.
> 
> Some information on the cpu:
> 
> /root# cat /proc/cpuinfo 
> processor       : 0
> cpu             : e500v2
> clock           : 1200.000000MHz
> revision        : 5.1 (pvr 8021 1051)
> bogomips        : 150.00
> 
> processor       : 1
> cpu             : e500v2
> clock           : 1200.000000MHz
> revision        : 5.1 (pvr 8021 1051)
> bogomips        : 150.00
> 
> total bogomips  : 300.00
> timebase        : 75000000
> platform        : P2020 RDB
> model           : fsl,P2020
> Memory          : 512 MB
> /root# uname -a
> Linux ntc7102 3.3.8 #1 SMP Thu Nov 19 04:59:51 CET 2015 ppc GNU/Linux
> 
> 
> 
> With the following hardcoding, I was able to use the oprofile tools without further problems:
> 
> diff --git a/libop/op_cpu_type.c b/libop/op_cpu_type.c
> index b1d5ecf..15d195b 100644
> --- a/libop/op_cpu_type.c
> +++ b/libop/op_cpu_type.c
> @@ -686,6 +686,7 @@ static op_cpu _get_s390_cpu_type(void)
>  static op_cpu __get_cpu_type(void)
>  {
>  	struct utsname uname_info;
> +	return op_get_cpu_number("ppc/e500v2");
>  	if (uname(&uname_info) < 0) {
>  		perror("uname failed");
>  		return CPU_NO_GOOD;
> diff --git a/pe_profiling/operf.cpp b/pe_profiling/operf.cpp
> index 21bf232..706ae85 100644
> --- a/pe_profiling/operf.cpp
> +++ b/pe_profiling/operf.cpp
> @@ -1502,7 +1502,7 @@ int main(int argc, char * const argv[])
>  	if (rc)
>  		exit(1);
>  
> -	cpu_type = op_get_cpu_type();
> +	cpu_type = op_get_cpu_number("ppc/e500v2");
>  	if (cpu_type == CPU_NO_GOOD) {
>  		cerr << "Unable to ascertain cpu type.  Exiting." << endl;
>  		cleanup();
> 
> 
> Would you be accepting a patch from my side ?
> 
> 
> By the way, in the past oprofile accepted kernel start/end from the command
> line; now it requires objdummp on the target. Would you accept a patch that
> would not require objdump when the info is given on the commandline ?
> 
> 
> kind regards,
> Ulrik
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> oprofile-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
> 


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140