Corey,
On Wed, Aug 6, 2008 at 5:08 PM, Corey J Ashford <[EMAIL PROTECTED]> wrote:
> 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.
>
Ok, I see your problem. I think what you are doing in detect is not
quite how this
was expected to work. I think you are trying to dynamic adjust that
single gen_powerpc_support
structure, yet you have multiple PFMLIB_*_PMU. This is where the
problem is coming from.
For each PFMLIB_*_PMU you need to have a DISTINCT pfm_pmu_support_t
structure. Take
a look at pfmlib_gen_ia32.c, this is how we handle architectural
perfmon vs. Core Duo.
Once you create a pfm_pmu_support_t structure for POWER[3-6]*, then
your problem will go away.
Alternatively, we could also pick another value to mean no forced_pmu.
> 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
