[ oprofile-Bugs-3517415 ] perf-events git branch compile errors and fixes

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #3517415, was opened at 2012-04-13 00:02
Message generated for change (Comment added) made by maynardj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3517415&group_id=16191

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas Wirooks (nudgegoonies)
Assigned to: Maynard Johnson (maynardj)
Summary: perf-events git branch compile errors and fixes

Initial Comment:
I checked out the perf-events git branch yesterday because i have to do performance analysis on a virtualized multicoremachine. To use the vpmu in order with the perf-events git branch i installed the lates fedora 17 alpha with kernel 3.3.1 and compiled the latest libpfm4 by myself. Yesterday i tried to compile the oprofile perf-events git branch and had severel compile errors.

One thing is the HAVE_LIBPFM define wich is not properly set. Isn't there a configure option to enably this? 

The other thing is the order of including <perf/libpfm.h> and one file missing this include completely.

Attached are the diffs with my results. I assume there is an other solution for die HAVE_LIBPFM instead of removing the ifdef's ;-) But there is still the problem with die ordering so pleays have attention to the position where the includes are. Maybe this all is fedora 17 alpha related wich comes with an very actual version of gcc. But i don't think the ordering will have effects on other versions of gcc and/or distribution.

----------------------------------------------------------------------

>Comment By: Maynard Johnson (maynardj)
Date: 2012-04-17 10:03

Message:
Please try the patch I attached to this bug.  I'm pretty sure that should
fix the Fedora build error, which is valid.  We're just getting lucky on
Debian and other distros.

----------------------------------------------------------------------

Comment By: Andreas Wirooks (nudgegoonies)
Date: 2012-04-17 07:26

Message:
I tried it on my local Debian 6 Squeeze i386 (with some backports) and on
the server with Fedora 17 Alpha AMD64.

On Debian i compiled two times. One time unmodified and one time with the
HAVE_LIBPFM outcommented (i know it makes no sense). Both builds were
completed without errors.

On Fedora i also compiled two times. Both builds stopped.

Unmodified:
g++ -DHAVE_CONFIG_H -I. -I..  -I ../libabi -I ../libutil -I ../libutil++ -I
../libop -I ../libdb -I ../libperf_events   -g -O2 -MT operf_utils.o -MD
-MP -MF .deps/operf_utils.Tpo -c -o operf_utils.o operf_utils.cpp
In file included from operf_utils.cpp:25:0:
operf_counter.h: In function ‘int op_perf_event_open(perf_event_attr*,
pid_t, int, int, long unsigned int)’:
operf_counter.h:47:26: error: ‘syscall’ was not declared in this scope
operf_utils.cpp: In function ‘int OP_perf_utils::op_write_output(int,
void*, size_t)’:
operf_utils.cpp:600:36: error: ‘write’ was not declared in this scope
operf_utils.cpp: In function ‘int
OP_perf_utils::op_mmap_trace_file(mmap_info&)’:
operf_utils.cpp:988:19: error: ‘_SC_PAGESIZE’ was not declared in this
scope
operf_utils.cpp:988:31: error: ‘sysconf’ was not declared in this
scope
operf_utils.cpp: In function ‘event_t*
OP_perf_utils::op_get_perf_event(mmap_info&)’:
operf_utils.cpp:1013:19: error: ‘_SC_PAGESIZE’ was not declared in this
scope
operf_utils.cpp:1013:31: error: ‘sysconf’ was not declared in this
scope

Including the libpfm.h inside operf_counter.h is the fix again.

With HAVE_LIBPFM outcommented:
g++ -DHAVE_CONFIG_H -I. -I..  -I ../libabi -I ../libutil -I ../libutil++ -I
../libop -I ../libdb -I ../libperf_events   -g -O2 -MT operf_utils.o -MD
-MP -MF .deps/operf_utils.Tpo -c -o operf_utils.o operf_utils.cpp
In file included from operf_utils.cpp:25:0:
operf_counter.h: In function ‘int op_perf_event_open(perf_event_attr*,
pid_t, int, int, long unsigned int)’:
operf_counter.h:47:26: error: ‘syscall’ was not declared in this scope

Same fix works here. There is no problem with operf_mangling anymore.

Looks like there is something wrong with Fedora because Debian has no
problems with the source.

----------------------------------------------------------------------

Comment By: Maynard Johnson (maynardj)
Date: 2012-04-16 08:34

Message:
The build error you're getting may be because I didn't follow proper
convention for header inclusions for syscall.  I'll attach a patch that
fixes up operf_counter.h to include the correct header files for syscall. 
Please test it and let me know your results.

----------------------------------------------------------------------

Comment By: Andreas Wirooks (nudgegoonies)
Date: 2012-04-16 07:11

Message:
I am really happy you answered to my report.

I have to say sorry, because i am working the AMD64 platform (2 quad-core
opterons) and and not on PPC. So i think this is the reason behind my
report. Now i understand why HAVE_LIBPFM was not set although i installed
libpfm4.

I compiled oprofile again without including libpfm.h in operf_mangling.cpp
and that was the errormessage:

In file included from operf_mangling.cpp:21:0:
operf_counter.h: In Funktion »int op_perf_event_open(perf_event_attr*,
pid_t, int, int, long unsigned int)«:
operf_counter.h:47:26: Error: »syscall« was not declared in this scope 

This looked very strange to me, because the error is in operf_counter.h. I
already tried to include the corresponding .h file from linux inside
operf_counter.h, without effect of course, until i saw, that the error came
up  while compiling operf_mangling. I think it has to do with the order in
wich the files are included.

I would really like to start coding on something like that because working
close to the hardware and the linux kernel personally interests me. I study
computer science and do my internship at the moment. But my actual job the
supervising tutor gave me is to evaluate different tools for performance
analysis under KVM.  I do my internship until end of august. I don't know
what will follow. The student who did his intership before me hat to do the
performance analysis under XEN. He used xenoprofile.

I use KVM via libvirt and the parameter "-cpu host". Guest and host are
both fedora 17 alpha installations in identical configuration for later
comparsion. I also tried to use the perf utility directly with the kvm
parameter. Well, it is not stable at the moment. Especially "perf top"
tends to crash after 5 till 15 seconds.

Thank you very much for answering.

----------------------------------------------------------------------

Comment By: Maynard Johnson (maynardj)
Date: 2012-04-13 07:57

Message:
Thank you for your interest in testing out the perf-events branch.
Currently, the configure.in checks for libpfm only on ppc64 systems.  So
that's the only way that HAVE_LIBPFM will get set to 1 (via
AC_CHECK_LIB(pfm)).  The only place in the perf-events branch where libpfm
is used is in libperf_events/operf_utils.cpp, and these areas are
surrounded by #ifdefs for __powerpc{64}__.  So for all other architectures,
HAVE_LIBPFM should be '0'.  Therefore, I am assuming you are running with
the Fedora/ppc alpha currently under development.  Correct?

Your patch correctly points out that the #include of perfmon/libpfm.h is
*NOT* needed for libperf_events/operf_counter.cpp.  But as I said above,
the only place in the perf-events branch that uses libpfm is
operf_utils.cpp, so I do not understand why you needed to add the #include
in operf_mangling.cpp.  And moving the #include upwards in operf_utils.cpp
-- is that a style thing or did the F17 compiler complain about something? 
I don't have access to an F17 box to try to build the perf-events branch,
but it builds find on RHEL 6.2.

By the way, I'm not familiar with the virtualization aspect of your
environment.  Is this KVM?  If so, I'm afraid that you'll find the oprofile
perf-events code is incomplete in that guest kernel and guest user samples
are not currently recorded.  Theoretically, the 'perf' tool does support
guest OS's. It would be great to have some help to flesh out the oprofile
perf-events branch to add this support -- at least for testing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=3517415&group_id=16191