Yes, that sounds like a better solution.  I will table this issue for now, since there are probably other problems with those two examples as well.

It might not be a bad idea to put some sort of warning in the code so that people are not surprised if the program doesn't work.  Something like:

"This program is in need of updating and has known problems.  It's quite likely this program will not work on any given platform, but that is not an indication of an improper implementation of perfmon"

Or that could go in a README.

at least until you can get the needed changes in.


Thanks,

- Corey

"stephane eranian" <eran...@googlemail.com> wrote on 01/09/2009 09:36:06 AM:

> Corey,
>
> On Fri, Jan 9, 2009 at 1:29 AM, Corey Ashford
> <cjash...@linux.vnet.ibm.com> wrote:
> > Hi Stephan,
> >
> > As you might have guessed, one of our goals has been to be able to run the
> > libpfm examples cleanly on Power.
> >
> > multiplex.c gives odd error messages about calls to pfm_write_pmds and
> > pfm_write_pmcs depending on the options given.  I tracked this down to the
> > allocation of the all_pmcs array on line 1146:
> >
> >      all_pmcs   = calloc(1, sizeof(pfarg_pmc_t)*total_events);
> >
> Yes, that's way too simplistic. I am not surprised it does not work.
> It won't even
> work on Pentium 4.
>
> multiplex.c is a very old program. It was added to demonstrate how one could
> do user-level multiplexing. Obviously, it needs a serious refresh.
>
> As a workaround, we could use pfm_get_num_pmcs() for the multiplier:
>
>
>  all_pmcs = calloc(pfm_get_num_pmcs() * num_sets, sizeof(parg_pmc_t))
>
> And do something similar for the other vectors.
>
>
>
>
> > The number of PKCs on to allocate on Power is not directly related to the
> > total events.  In this case, there are four total events, but we need 6 pmc
> > registers (3 for each set).  On Power, it's always 3 registers per set.  I
> > would guess that other architectures might have similar issues.
> >
> > Because not enough space is allocated, we end up overwriting memory that  is
> > located after the array, causing corruption of memory.  This results in
> > various bad things happening, as you might imagine.
> >
> > As a temporary work-around, I changed the multiplier from total_events to
> > just '20'.  This fixed the problem and the test runs correctly, at least
> > with the default options.
> >
> > Any ideas about a better fix than this?
> >
> > Regards,
> >
> > - Corey
> >
> > Corey Ashford
> > Software Engineer
> > IBM Linux Technology Center, Linux Toolchain
> > Beaverton, OR
> > 503-578-3507
> > cjash...@us.ibm.com
> >
> >
>
> ------------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to