From: Matthew M. <ms...@fr...> - 2013-02-05 18:02:11
|
You can't determine the target for running on by running uname on the build machine. Use a better method instead. Signed-off-by: Matthew McClintock <ms...@fr...> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a9b1ee4..4b73cdd 100644 --- a/configure.ac +++ b/configure.ac @@ -155,10 +155,10 @@ fi AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) +AC_CANONICAL_HOST if test "$HAVE_PERF_EVENTS" = "1"; then PFM_LIB= - arch="`uname -m`" - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then + if test "$host_cpu" = "powerpc"; then AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', -- 1.7.9.7 |
From: Maynard J. <may...@us...> - 2013-02-06 15:56:05
|
On 02/05/2013 11:46 AM, Matthew McClintock wrote: > You can't determine the target for running on by running uname > on the build machine. Use a better method instead. This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. -Maynard > > Signed-off-by: Matthew McClintock <ms...@fr...> > --- > configure.ac | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index a9b1ee4..4b73cdd 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -155,10 +155,10 @@ fi > > AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) > > +AC_CANONICAL_HOST > if test "$HAVE_PERF_EVENTS" = "1"; then > PFM_LIB= > - arch="`uname -m`" > - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then > + if test "$host_cpu" = "powerpc"; then > AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) > AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ > AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', |
From: McClintock Matthew-B. <B2...@fr...> - 2013-02-07 16:57:03
|
On Wednesday, February 6, 2013, Maynard Johnson <may...@us...<mailto:may...@us...>> wrote: > On 02/05/2013 11:46 AM, Matthew McClintock wrote: >> You can't determine the target for running on by running uname >> on the build machine. Use a better method instead. > > This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. Hmm, I thought I read that $host_cpu would be wrong "powerpc" still. I will test this out and resubmit if appropriate in a few days once I'm back from vacation. > What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? I'm trying to fix cross compiling. Running 'uname' on the build machine to determine arch won't work properly. > I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. What do you mean libpfm does not support ppc? It builds fine and links with oprofile just fine. In fact oprofile seems to be unable to build at all without libpfm, which is why this issue came up for me. Please correct me if I'm wrong, I'm not a oprofile/libpfm expert by any means here ;) -M > > -Maynard >> >> Signed-off-by: Matthew McClintock <ms...@fr...<mailto:ms...@fr...>> >> --- >> configure.ac<http://configure.ac> | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/configure.ac<http://configure.ac> b/configure.ac<http://configure.ac> >> index a9b1ee4..4b73cdd 100644 >> --- a/configure.ac<http://configure.ac> >> +++ b/configure.ac<http://configure.ac> >> @@ -155,10 +155,10 @@ fi >> >> AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) >> >> +AC_CANONICAL_HOST >> if test "$HAVE_PERF_EVENTS" = "1"; then >> PFM_LIB= >> - arch="`uname -m`" >> - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then >> + if test "$host_cpu" = "powerpc"; then >> AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) >> AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ >> AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', > > > |
From: Maynard J. <may...@us...> - 2013-02-07 21:11:06
|
On 02/07/2013 10:41 AM, McClintock Matthew-B29882 wrote: > On Wednesday, February 6, 2013, Maynard Johnson <may...@us... <mailto:may...@us...>> wrote: >> On 02/05/2013 11:46 AM, Matthew McClintock wrote: >>> You can't determine the target for running on by running uname >>> on the build machine. Use a better method instead. >> >> This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. > > Hmm, I thought I read that $host_cpu would be wrong "powerpc" still. I will test this out and resubmit if appropriate in a few days once I'm back from vacation. Sorry, maybe what you wrote above is a typo, but I just don't understand what you mean by "$host_cpu would be wrong "powerpc" still". > >> What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? > > I'm trying to fix cross compiling. Running 'uname' on the build machine to determine arch won't work properly. Let me explain why this configure check exists in the first place. Almost all (possibly all) architectures other than ppc64 store event codes with their oprofile event information. These are the codes that operf passes to the perf_event_open syscall. If you're familiar with the 'perf' tool, these are the same codes you would pass using the syntax of 'perf record -e r<hex-code>'. But the ppc64 oprofile event definitions use a triple of MMCR register values instead of a single hex code. When using legacy opcontrol, these register values are written to the oprofilefs and the oprofile kernel driver reads them. But those register values can't be used by operf. So when operf is built for ppc64, we need to link to the libpfm library which has helper functions that translate symbolic event names (e.g., PM_RUN_CYC) to a simple hex code that can be passed to perf_event_open. But now, looking at how legacy oprofile works for the ppc arch, it seems that the oprofile event codes for ppc are probably also valid for operf -- i.e., no help is needed from libpfm. So I believe my original coding of that configure check was incorrect, and I should not have included "ppc" when looking at the result of 'uname -m'. > >> I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. > > What do you mean libpfm does not support ppc? It builds fine and links with oprofile just fine. In fact oprofile seems to be unable to build at all without libpfm, which is why this issue came up for me. Have you run this operf on ppc? Anyway, if my statement above is right (that ppc does *not* need libpfm), then you should not be linking with libpfm. Can you explain how you came to the conclusion that you needed this patch of yours? Was there some code failing to compile? Something surrounded by "#if (defined(__powerpc__) || defined(__powerpc64__))" by chance? -Maynard > > Please correct me if I'm wrong, I'm not a oprofile/libpfm expert by any means here ;) > > -M > >> >> -Maynard >>> >>> Signed-off-by: Matthew McClintock <ms...@fr... <mailto:ms...@fr...>> >>> --- >>> configure.ac <http://configure.ac> | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/configure.ac <http://configure.ac> b/configure.ac <http://configure.ac> >>> index a9b1ee4..4b73cdd 100644 >>> --- a/configure.ac <http://configure.ac> >>> +++ b/configure.ac <http://configure.ac> >>> @@ -155,10 +155,10 @@ fi >>> >>> AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) >>> >>> +AC_CANONICAL_HOST >>> if test "$HAVE_PERF_EVENTS" = "1"; then >>> PFM_LIB= >>> - arch="`uname -m`" >>> - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then >>> + if test "$host_cpu" = "powerpc"; then >>> AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) >>> AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ >>> AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', >> >> >> |
From: McClintock Matthew-B. <B2...@fr...> - 2013-02-11 17:04:09
|
On Thu, Feb 7, 2013 at 3:10 PM, Maynard Johnson <may...@us...> wrote: > On 02/07/2013 10:41 AM, McClintock Matthew-B29882 wrote: >> On Wednesday, February 6, 2013, Maynard Johnson <may...@us... <mailto:may...@us...>> wrote: >>> On 02/05/2013 11:46 AM, Matthew McClintock wrote: >>>> You can't determine the target for running on by running uname >>>> on the build machine. Use a better method instead. >>> >>> This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. >> >> Hmm, I thought I read that $host_cpu would be wrong "powerpc" still. I will test this out and resubmit if appropriate in a few days once I'm back from vacation. > Sorry, maybe what you wrote above is a typo, but I just don't understand what you mean by "$host_cpu would be wrong "powerpc" still". Sorry, I clearly was not typing well that day. I was just trying to say, it appears you are right in that host_cpu will be powerpc OR powerpc64 and I need to check both cases. >> >>> What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? >> >> I'm trying to fix cross compiling. Running 'uname' on the build machine to determine arch won't work properly. > Let me explain why this configure check exists in the first place. Almost all (possibly all) architectures other than ppc64 store event codes with their oprofile event information. These are the codes that operf passes to the perf_event_open syscall. If you're familiar with the 'perf' tool, these are the same codes you would pass using the syntax of 'perf record -e r<hex-code>'. But the ppc64 oprofile event definitions use a triple of MMCR register values instead of a single hex code. When using legacy opcontrol, these register values are written to the oprofilefs and the oprofile kernel driver reads them. But those register values can't be used by operf. So when operf is built for ppc64, we need to link to the libpfm library which has helper functions that translate symbolic event names (e.g., PM_RUN_CYC) to a simple hex code that can be passed to perf_event_open. Got it. > > But now, looking at how legacy oprofile works for the ppc arch, it seems that the oprofile event codes for ppc are probably also valid for operf -- i.e., no help is needed from libpfm. So I believe my original coding of that configure check was incorrect, and I should not have included "ppc" when looking at the result of 'uname -m'. Ok, but you also have a build problem when cross compiling. This is a completely different issue than what may be functionally correct. Right now you are checking uname on the build machine to determine libpfm usage on the target. This won't work and results in build errors such as this: So, without this patch (which is missing powerpc64 as noted above) and when cross compiling we will get build errors and that's not good for running oprofile OR operf on the target. >> >>> I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. I got libpfm to build and link against operf on ppc32 - now if it actually does anything useful is up in the air. However, when I ran operf I got a message about operf not being supported on my kernel - bu I did not look too much deeper. This is better than failing to cross compile IMO. >> What do you mean libpfm does not support ppc? It builds fine and links with oprofile just fine. In fact oprofile seems to be unable to build at all without libpfm, which is why this issue came up for me. > Have you run this operf on ppc? Anyway, if my statement above is right (that ppc does *not* need libpfm), then you should not be linking with libpfm. Can you explain how you came to the conclusion that you needed this patch of yours? Was there some code failing to compile? Something surrounded by "#if (defined(__powerpc__) || defined(__powerpc64__))" by chance? Yes, try to cross compile oprofile on an x86 host target ppc32 or ppc64 and you will get these errors: | operf_utils.cpp: In function 'bool _op_get_event_codes(std::vector<operf_event>*)': | operf_utils.cpp:151:21: error: 'pfm_initialize' was not declared in this scope | operf_utils.cpp:151:26: error: 'PFM_SUCCESS' was not declared in this scope | operf_utils.cpp:166:45: error: 'PFM_PLM3' was not declared in this scope | operf_utils.cpp:166:55: error: 'PFM_OS_NONE' was not declared in this scope | operf_utils.cpp:166:72: error: 'pfm_get_os_event_encoding' was not declared in this scope | operf_utils.cpp:167:14: error: 'PFM_SUCCESS' was not declared in this scope | make[2]: *** [operf_utils.o] Error 1 -M > -Maynard > >> >> Please correct me if I'm wrong, I'm not a oprofile/libpfm expert by any means here ;) >> >> -M >> >>> >>> -Maynard >>>> >>>> Signed-off-by: Matthew McClintock <ms...@fr... <mailto:ms...@fr...>> >>>> --- >>>> configure.ac <http://configure.ac> | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/configure.ac <http://configure.ac> b/configure.ac <http://configure.ac> >>>> index a9b1ee4..4b73cdd 100644 >>>> --- a/configure.ac <http://configure.ac> >>>> +++ b/configure.ac <http://configure.ac> >>>> @@ -155,10 +155,10 @@ fi >>>> >>>> AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) >>>> >>>> +AC_CANONICAL_HOST >>>> if test "$HAVE_PERF_EVENTS" = "1"; then >>>> PFM_LIB= >>>> - arch="`uname -m`" >>>> - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then >>>> + if test "$host_cpu" = "powerpc"; then >>>> AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) >>>> AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ >>>> AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', >>> >>> >>> > > |
From: Maynard J. <may...@us...> - 2013-02-11 18:49:46
|
On 02/11/2013 11:02 AM, McClintock Matthew-B29882 wrote: > On Thu, Feb 7, 2013 at 3:10 PM, Maynard Johnson <may...@us...> wrote: >> On 02/07/2013 10:41 AM, McClintock Matthew-B29882 wrote: >>> On Wednesday, February 6, 2013, Maynard Johnson <may...@us... <mailto:may...@us...>> wrote: >>>> On 02/05/2013 11:46 AM, Matthew McClintock wrote: >>>>> You can't determine the target for running on by running uname >>>>> on the build machine. Use a better method instead. >>>> >>>> This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. >>> >>> Hmm, I thought I read that $host_cpu would be wrong "powerpc" still. I will test this out and resubmit if appropriate in a few days once I'm back from vacation. >> Sorry, maybe what you wrote above is a typo, but I just don't understand what you mean by "$host_cpu would be wrong "powerpc" still". > > Sorry, I clearly was not typing well that day. I was just trying to > say, it appears you are right in that host_cpu will be powerpc OR > powerpc64 and I need to check both cases. > >>> >>>> What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? >>> >>> I'm trying to fix cross compiling. Running 'uname' on the build machine to determine arch won't work properly. >> Let me explain why this configure check exists in the first place. Almost all (possibly all) architectures other than ppc64 store event codes with their oprofile event information. These are the codes that operf passes to the perf_event_open syscall. If you're familiar with the 'perf' tool, these are the same codes you would pass using the syntax of 'perf record -e r<hex-code>'. But the ppc64 oprofile event definitions use a triple of MMCR register values instead of a single hex code. When using legacy opcontrol, these register values are written to the oprofilefs and the oprofile kernel driver reads them. But those register values can't be used by operf. So when operf is built for ppc64, we need to link to the libpfm library which has helper functions that translate symbolic event names (e.g., PM_RUN_CYC) to a simple hex code that can be passed to perf_event_open. > > Got it. > >> >> But now, looking at how legacy oprofile works for the ppc arch, it seems that the oprofile event codes for ppc are probably also valid for operf -- i.e., no help is needed from libpfm. So I believe my original coding of that configure check was incorrect, and I should not have included "ppc" when looking at the result of 'uname -m'. > > Ok, but you also have a build problem when cross compiling. This is a > completely different issue than what may be functionally correct. > Right now you are checking uname on the build machine to determine > libpfm usage on the target. This won't work and results in build > errors such as this: > > So, without this patch (which is missing powerpc64 as noted above) and > when cross compiling we will get build errors and that's not good for > running oprofile OR operf on the target. Yes, I agree that the 'uname' stuff is not the right way to check for host, and that $host_cpu should be used instead. But as I said above, I'm quite certain that only "powerpc64" should be checked for. See below for more on this. > >>> >>>> I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. > > I got libpfm to build and link against operf on ppc32 - now if it > actually does anything useful is up in the air. No, it wouldn't do anything useful -- it would actually cause operf to fail, so you do NOT want to link with libpfm. > However, when I ran > operf I got a message about operf not being supported on my kernel - > bu I did not look too much deeper. This is better than failing to > cross compile IMO. There are a number of different reasons why operf may be unsupported. The exact error message text is needed to determine the cause. > >>> What do you mean libpfm does not support ppc? It builds fine and links with oprofile just fine. In fact oprofile seems to be unable to build at all without libpfm, which is why this issue came up for me. >> Have you run this operf on ppc? Anyway, if my statement above is right (that ppc does *not* need libpfm), then you should not be linking with libpfm. Can you explain how you came to the conclusion that you needed this patch of yours? Was there some code failing to compile? Something surrounded by "#if (defined(__powerpc__) || defined(__powerpc64__))" by chance? > > Yes, try to cross compile oprofile on an x86 host target ppc32 or > ppc64 and you will get these errors: Yes, this is as I suspected. Note that the code location identified below is inside an "#if (defined(__powerpc__) || defined(__powerpc64__))". That "#if defined" should probably be: #if (defined(HAVE_LIBPFM) && ((defined(__powerpc__) || defined(__powerpc64__))) There are a few other spots in operf code where I made the same mistake of incorrectly interpreting "__powerpc__" as meaning 32-bit build on ppc64 arch, since it can also mean 32-bit build on ppc32 arch. :-/ I'll work up a patch and post it to the list. -Maynard > > | operf_utils.cpp: In function 'bool > _op_get_event_codes(std::vector<operf_event>*)': > | operf_utils.cpp:151:21: error: 'pfm_initialize' was not declared in this scope > | operf_utils.cpp:151:26: error: 'PFM_SUCCESS' was not declared in this scope > | operf_utils.cpp:166:45: error: 'PFM_PLM3' was not declared in this scope > | operf_utils.cpp:166:55: error: 'PFM_OS_NONE' was not declared in this scope > | operf_utils.cpp:166:72: error: 'pfm_get_os_event_encoding' was not > declared in this scope > | operf_utils.cpp:167:14: error: 'PFM_SUCCESS' was not declared in this scope > | make[2]: *** [operf_utils.o] Error 1 > > -M > >> -Maynard >> >>> >>> Please correct me if I'm wrong, I'm not a oprofile/libpfm expert by any means here ;) >>> >>> -M >>> >>>> >>>> -Maynard >>>>> >>>>> Signed-off-by: Matthew McClintock <ms...@fr... <mailto:ms...@fr...>> >>>>> --- >>>>> configure.ac <http://configure.ac> | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/configure.ac <http://configure.ac> b/configure.ac <http://configure.ac> >>>>> index a9b1ee4..4b73cdd 100644 >>>>> --- a/configure.ac <http://configure.ac> >>>>> +++ b/configure.ac <http://configure.ac> >>>>> @@ -155,10 +155,10 @@ fi >>>>> >>>>> AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) >>>>> >>>>> +AC_CANONICAL_HOST >>>>> if test "$HAVE_PERF_EVENTS" = "1"; then >>>>> PFM_LIB= >>>>> - arch="`uname -m`" >>>>> - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then >>>>> + if test "$host_cpu" = "powerpc"; then >>>>> AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) >>>>> AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ >>>>> AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', >>>> >>>> >>>> >> >> |
From: McClintock Matthew-B. <B2...@fr...> - 2013-02-11 18:58:42
|
On Mon, Feb 11, 2013 at 12:24 PM, Maynard Johnson <may...@us...> wrote: > On 02/11/2013 11:02 AM, McClintock Matthew-B29882 wrote: >> On Thu, Feb 7, 2013 at 3:10 PM, Maynard Johnson <may...@us...> wrote: >>> On 02/07/2013 10:41 AM, McClintock Matthew-B29882 wrote: >>>> On Wednesday, February 6, 2013, Maynard Johnson <may...@us... <mailto:may...@us...>> wrote: >>>>> On 02/05/2013 11:46 AM, Matthew McClintock wrote: >>>>>> You can't determine the target for running on by running uname >>>>>> on the build machine. Use a better method instead. >>>>> >>>>> This patch breaks native ppc64 builds, since $host_cpu is "powerpc64" in that case. >>>> >>>> Hmm, I thought I read that $host_cpu would be wrong "powerpc" still. I will test this out and resubmit if appropriate in a few days once I'm back from vacation. >>> Sorry, maybe what you wrote above is a typo, but I just don't understand what you mean by "$host_cpu would be wrong "powerpc" still". >> >> Sorry, I clearly was not typing well that day. I was just trying to >> say, it appears you are right in that host_cpu will be powerpc OR >> powerpc64 and I need to check both cases. >> >>>> >>>>> What exactly is the intent of the patch? Do you wish to include or exclude the ppc arch configuring with libpfm? >>>> >>>> I'm trying to fix cross compiling. Running 'uname' on the build machine to determine arch won't work properly. >>> Let me explain why this configure check exists in the first place. Almost all (possibly all) architectures other than ppc64 store event codes with their oprofile event information. These are the codes that operf passes to the perf_event_open syscall. If you're familiar with the 'perf' tool, these are the same codes you would pass using the syntax of 'perf record -e r<hex-code>'. But the ppc64 oprofile event definitions use a triple of MMCR register values instead of a single hex code. When using legacy opcontrol, these register values are written to the oprofilefs and the oprofile kernel driver reads them. But those register values can't be used by operf. So when operf is built for ppc64, we need to link to the libpfm library which has helper functions that translate symbolic event names (e.g., PM_RUN_CYC) to a simple hex code that can be passed to perf_event_open. >> >> Got it. >> >>> >>> But now, looking at how legacy oprofile works for the ppc arch, it seems that the oprofile event codes for ppc are probably also valid for operf -- i.e., no help is needed from libpfm. So I believe my original coding of that configure check was incorrect, and I should not have included "ppc" when looking at the result of 'uname -m'. >> >> Ok, but you also have a build problem when cross compiling. This is a >> completely different issue than what may be functionally correct. >> Right now you are checking uname on the build machine to determine >> libpfm usage on the target. This won't work and results in build >> errors such as this: >> >> So, without this patch (which is missing powerpc64 as noted above) and >> when cross compiling we will get build errors and that's not good for >> running oprofile OR operf on the target. > Yes, I agree that the 'uname' stuff is not the right way to check for host, and that $host_cpu should be used instead. But as I said above, I'm quite certain that only "powerpc64" should be checked for. See below for more on this. >> >>>> >>>>> I would guess the latter since I see no evidence that libpfm supports ppc, but that doesn't seem to be how the patch was written. >> >> I got libpfm to build and link against operf on ppc32 - now if it >> actually does anything useful is up in the air. > No, it wouldn't do anything useful -- it would actually cause operf to fail, so you do NOT want to link with libpfm. >> However, when I ran >> operf I got a message about operf not being supported on my kernel - >> bu I did not look too much deeper. This is better than failing to >> cross compile IMO. > There are a number of different reasons why operf may be unsupported. The exact error message text is needed to determine the cause. >> >>>> What do you mean libpfm does not support ppc? It builds fine and links with oprofile just fine. In fact oprofile seems to be unable to build at all without libpfm, which is why this issue came up for me. >>> Have you run this operf on ppc? Anyway, if my statement above is right (that ppc does *not* need libpfm), then you should not be linking with libpfm. Can you explain how you came to the conclusion that you needed this patch of yours? Was there some code failing to compile? Something surrounded by "#if (defined(__powerpc__) || defined(__powerpc64__))" by chance? >> >> Yes, try to cross compile oprofile on an x86 host target ppc32 or >> ppc64 and you will get these errors: > Yes, this is as I suspected. Note that the code location identified below is inside an "#if (defined(__powerpc__) || defined(__powerpc64__))". That "#if defined" should probably be: > #if (defined(HAVE_LIBPFM) && ((defined(__powerpc__) || defined(__powerpc64__))) > > There are a few other spots in operf code where I made the same mistake of incorrectly interpreting "__powerpc__" as meaning 32-bit build on ppc64 arch, since it can also mean 32-bit build on ppc32 arch. :-/ > > I'll work up a patch and post it to the list. Awesome, thanks for clearing things up. If possible, can you CC me on the patch since I'm not subscribed? Thanks, -M > > -Maynard > >> >> | operf_utils.cpp: In function 'bool >> _op_get_event_codes(std::vector<operf_event>*)': >> | operf_utils.cpp:151:21: error: 'pfm_initialize' was not declared in this scope >> | operf_utils.cpp:151:26: error: 'PFM_SUCCESS' was not declared in this scope >> | operf_utils.cpp:166:45: error: 'PFM_PLM3' was not declared in this scope >> | operf_utils.cpp:166:55: error: 'PFM_OS_NONE' was not declared in this scope >> | operf_utils.cpp:166:72: error: 'pfm_get_os_event_encoding' was not >> declared in this scope >> | operf_utils.cpp:167:14: error: 'PFM_SUCCESS' was not declared in this scope >> | make[2]: *** [operf_utils.o] Error 1 >> >> -M >> >>> -Maynard >>> >>>> >>>> Please correct me if I'm wrong, I'm not a oprofile/libpfm expert by any means here ;) >>>> >>>> -M >>>> >>>>> >>>>> -Maynard >>>>>> >>>>>> Signed-off-by: Matthew McClintock <ms...@fr... <mailto:ms...@fr...>> >>>>>> --- >>>>>> configure.ac <http://configure.ac> | 4 ++-- >>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/configure.ac <http://configure.ac> b/configure.ac <http://configure.ac> >>>>>> index a9b1ee4..4b73cdd 100644 >>>>>> --- a/configure.ac <http://configure.ac> >>>>>> +++ b/configure.ac <http://configure.ac> >>>>>> @@ -155,10 +155,10 @@ fi >>>>>> >>>>>> AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists]) >>>>>> >>>>>> +AC_CANONICAL_HOST >>>>>> if test "$HAVE_PERF_EVENTS" = "1"; then >>>>>> PFM_LIB= >>>>>> - arch="`uname -m`" >>>>>> - if test "$arch" = "ppc64" || test "$arch" = "ppc"; then >>>>>> + if test "$host_cpu" = "powerpc"; then >>>>>> AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; usually provided in papi devel package])]) >>>>>> AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [ >>>>>> AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1', >>>>> >>>>> >>>>> >>> >>> > > |