Re: Next release OProfile-1.1

"Carl E. Love" <[email protected]>
Newsgroups gmane.linux.oprofile
Message-ID <1433198082.4887.34.camel@oc3328482554>
On Sun, 2015-05-31 at 21:24 -0400, William Cohen wrote:
> On 05/31/2015 09:10 PM, William Cohen wrote:
> > On 05/29/2015 07:42 PM, Carl E. Love wrote:
> >> On Tue, 2015-05-26 at 11:40 -0400, William Cohen wrote:
> >>> Hello OProfile community,
> >>>
> >>> It has be almost a year since the last OProfile release. There have
> >>> been several fixes checked into the OProfile git repository.  It
> >>> would be nice to have these improvements packaged in a release.  I
> >>> plan to put out a release candidate in mid-June.  If there are
> >>> additional fixes or support for additional processors that should be
> >>> included in this release, please let me know as soon as possible.
> >>>
> >>> Thanks,
> >>> -Will
> >>
> >>
> >> Will:
> >>
> >> FYI, I pulled down the latest Git tree of OProfile this afternoon and
> >> tried to compile it on Power.  It failed to compile:
> >>
> >> g++ -DHAVE_CONFIG_H -I. -I..  -I ../libutil -I ../libutil++ -I ../libop -I ../libpe_utils -I ../libperf_events   -W -Wall -fno-common -ftemplate-depth-50 -Werror -g -O2 -MT op_pe_utils.o -MD -MP -MF .deps/op_pe_utils.Tpo -c -o op_pe_utils.o op_pe_utils.cpp
> >> op_pe_utils.cpp: In function ‘bool _get_codes_for_match(unsigned int, const char*, std::vector<operf_event, std::allocator<operf_event> >*)’:
> >> op_pe_utils.cpp:678: error: ‘pfm_get_event_code’ was not declared in this scope
> >> op_pe_utils.cpp:679: error: ‘PFMLIB_SUCCESS’ was not declared in this scope
> >> op_pe_utils.cpp: In function ‘bool convert_event_vals(std::vector<operf_event, std::allocator<operf_event> >*)’:
> >> op_pe_utils.cpp:800: error: ‘PFMLIB_SUCCESS’ was not declared in this scope
> >> op_pe_utils.cpp:803: error: ‘pfm_get_num_events’ was not declared in this scope
> >> op_pe_utils.cpp:804: error: ‘PFMLIB_SUCCESS’ was not declared in this scope
> >> op_pe_utils.cpp:808: error: ‘pfm_get_event_name’ was not declared in this scope
> >> op_pe_utils.cpp:809: error: ‘PFMLIB_SUCCESS’ was not declared in this scope
> >> make[2]: *** [op_pe_utils.o] Error 1
> >>
> >> When I grep the source for "pfm_get_event_code" I see the use of it in op_pe_utils.cpp
> >> but I do not find a definition of the function.  I will look into the issue further and
> >> get back with you.
> >>
> >> Note, it compiled OK on my 64-bit Intel laptop.
> >>
> >>                  Carl Love
> >>
> > 
> > Carl,
> > 
> > Thanks for trying trying things out on PPC.  What particular distribution of Linux was being run on the PPC and what version of libpfm is on the machine? Looking through /usr/include/perfmon/*.h don't see that being defined on Fedora21. Doing a "get blame" on ./libpe_utils/op_pe_utils.cpp show the following commit adding the PFMLIB_SUCCESS
> > 
> > commit 8846630b3b2b2a6555d98d388e97bfae496f5222
> > Author: Maynard Johnson <[email protected]>
> > Date:   Thu Jul 18 13:41:02 2013 -0500
> > 
> >     Add various utility routines needed by new ocount tool
> >     
> >     Signed-off-by: Maynard Johnson <[email protected]>
> > 
> > It looks like this would have been in oprofile-0.9.9 and newer.  I am wondering how that worked in the past.
> > 
> > -Will
> 
> Actually PFM_SUCCESS is in /usr/include/perfmon/pfmlib.h:
> 
> #define PFM_SUCCESS		0	/* success */
> 
> Could you run the following and look through the op_pe_utils.i to see where it is gettint the pfmlib.h file?
> 
> g++ --save-temps -DHAVE_CONFIG_H -I. -I..  -I ../libutil -I ../libutil++ -I ../libop -I ../libpe_utils -I ../libperf_events   -W -Wall -fno-common -ftemplate-depth-50 -Werror -g -O2 -MT op_pe_utils.o -MD -MP -MF .deps/op_pe_utils.Tpo -c -o op_pe_utils.o op_pe_utils.cpp
> 
> If this is on a RHEL6 system, you might need to take special steps to get the proper pfmlib.h because it is in /usr/lib64/papi-5.1.1/usr/include/perfmon/pfmlib.h

Will:

I spent a fair bit of time digging into this.  I have access to a
similar machine with the same RHEL 6.6 install on it and the OProfile
compile worked fine.  Long story, short, the machine where OProfile
failed to build had a couple of versions of PAPI on it, papi-4.1.3 and
papi-5.4.1.  When I did the OProfile configure I would see in the log 

| #define HAVE_LIBPFM3 1
| #define HAVE_LIBPFM 1

The other machine did not have PAPI installed.  When I configured
OProfile on that machine  HAVE_LIBPFM3 = 0 and  HAVE_LIBPFM=1.

I uninstalled PAPI on the machine where the OProfile compile failed, did
an OProfile make clean, make distclean, and rebuilt of OProfile from
scratch and rebuilt OProfile again.  The compile worked fine.  I
re-installed PAPI on the same machine, did a make clean and recompiled
again and OProfile still works.  In each case HAVE_LIBPFM3 = 0.  So, the
best I can determine is removing PAPI took out some old library file
that was causing the OProfile configure to set HAVE_LIBPFM3 to 1 and
thus the compile would fail because that is an old incompatible version
of LIBPFM.  

I pulled OProfile down to a number of different PPC Power machines with
SLES 11, SLES 12, RHEL 6.1, RHEL 6.6, RHEL 7.1, and Fedora 21.  In each
case, OProfile builds fine.  I did not run the OProfile testsuite on
these machines just made sure OProfile compiled.  

So I believe the issue was a specific machine configuration problem not
an underlying issue with OProfile.  When you have the release candidate
ready, I will build and test it by running the OProfile testsuite on the
various OSes, Power 7, Power 8, big endian and little endian to verify
the release candidate.  Thanks for your time.

                      Carl Love
 


------------------------------------------------------------------------------
_______________________________________________
oprofile-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oprofile-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.