Hi Stephane,
Thanks for your reply.
The problem is that the (*p) data structure has not been initialized by the
time the check is made in "if ((*p)->pmu_type == forced_pmu)". Because the
structure has not been initialized, it contains all zeros, and so (*p)->
pmu_type IS equal to forced_pmu (which is zero too).
The (*p) data structure is initialized in the following if-statement which
contains a call to detect_pmu(), but we never get that far.
Regards,
- Corey,
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
"stephane eranian" <[EMAIL PROTECTED]> wrote on 08/06/2008 04:27:51
PM:
> Corey,
>
> Let me explain the motivation behind this change. The idea is to allow
> testing of the library without having to necessarily
> run on a host with the specific PMU you want to test. For instance,
> I'd like to be on Core 2 and test the AMD64 libpfm code.
> To do that you have to bypass the PMU detection code. Unfortunately
> that is not as easy as that. Many detection routines
> are doing more that detection, they also initialize certain
> structures. In the libpfm-3.5, I simply split detection and
> initialization.
> When you force (using env. variable LIBPFM_FORCE_PMU), then you skip
> detection but you still execute initialization.
> That works in most cases, however when the initialization needs to
> touch HW, e.g, CPUID or cpuinfo, then you have to make
> it up. I have fixed all the X86 and Itanium detection routines. If you
> are not forcing the PMU, then there should be no changes
> because the init callback is optional. So it is not clear to me why
> you are having a problem.
>
>
> To force a specific PMU, you need to set LIBPFM_FORCE_PMU=n where n is
> the libpfm PMU model value which you get
> out of include/perfmon/pfmlib.h, e.g., 34 is for Intel CoreDuo.
>
> Hope this helps.
>
>
> On Wed, Aug 6, 2008 at 4:07 PM, Corey Ashford <[EMAIL PROTECTED]>
wrote:
> > Hello Stephane,
> >
> > Fairly recently, the following lines were added to pfm_initialize() in
> > pfm_common.c in libpfm:
> >
> > ...
> > while(*p) {
> > + /*
> > + * check for forced_pmu
> > + * pmu_type can never be zero
> > + */
> > + if ((*p)->pmu_type == forced_pmu) {
> > + __pfm_vbprintf("PMU forced to %s\n", (*p)->pmu_name);
> > + goto found;
> > + }
> >
> > if (!forced_pmu && (*p)->pmu_detect() == PFMLIB_SUCCESS)
> > goto found;
> > p++;
> > }
> > }
> > ...
> >
> >
> > (note: above is not a real patch, it's just for illustration)
> >
> > These new lines are causing libpfm on POWER to fail because at the
point
> > where (*p)->pmu_type is checked, it is zero. It is set only by
> > (*p)->pmu_detect(). Because the first if-statement's condition is
true,
> > pmu_detect() is never called.
> >
> > I'm not sure what the right solution here, because I don't know what
the
> > intention of forced_pmu is, exactly. Maybe the order of these two
> > if-statements should be reversed?
> >
> > To work around this for now, I'm going to comment out the first
> > if-statement.
> >
> > Thanks for your consideration.
> > - Corey
> >
> > --
> > Corey Ashford
> > Software Engineer
> > IBM Linux Technology Center, Linux Toolchain
> > Beaverton, OR
> > 503-578-3507
> > [EMAIL PROTECTED]
> >
> >-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
