Menu

#212 perf-events git branch compile errors and fixes

closed-fixed
None
5
2012-04-18
2012-04-13
No

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.

Discussion

  • Andreas Wirooks

    Andreas Wirooks - 2012-04-13
     
  • Maynard Johnson

    Maynard Johnson - 2012-04-13
    • assigned_to: nobody --> maynardj
     
  • Maynard Johnson

    Maynard Johnson - 2012-04-13

    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.

     
  • Andreas Wirooks

    Andreas Wirooks - 2012-04-16

    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.

     
  • Maynard Johnson

    Maynard Johnson - 2012-04-16

    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.

     
  • Maynard Johnson

    Maynard Johnson - 2012-04-16

    Patch to fix this bug

     
  • Andreas Wirooks

    Andreas Wirooks - 2012-04-17

    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.

     
  • Maynard Johnson

    Maynard Johnson - 2012-04-17

    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.

     
  • Andreas Wirooks

    Andreas Wirooks - 2012-04-18

    I tried the patch in all 4 configurations without any errors.

    Thank you!

     
  • Maynard Johnson

    Maynard Johnson - 2012-04-18

    Patch has been pushed upstream into the perf-events branch. Thanks for the bug report.

     
  • Maynard Johnson

    Maynard Johnson - 2012-04-18
    • status: open --> closed-fixed
     

Log in to post a comment.