RE: Re: bogus values of variables in userspace probes

["平松雅巳 / HIRAMATU，MASAMI" <masami.hiramatsu.pt@hitachi.com>]

From: Michael Petlan [mailto:mpetlan@redhat.com]
>
>On Tue, 2015-11-24 at 16:16 -0300, Arnaldo Carvalho de Melo wrote:
>>
>> > I have met this when writing new tests for perf-probe into the testsuite
>> > I had been speaking about some time ago [1]. But if needed, I may add it
>> > as a perf-test entry as you wish.
>>
>> Please :-)
>>
>
>Hi,
>
>after a short discussion with Jiri Olsa I think that perf-test entry is
>not an ideal way to add a testcase such as this one. While perf-test
>aims on testing internal functions, here you need to use multiple tools
>in order to reproduce the issue:
>
>1) build a custom C example
>2) add a userspace probe in the example
>3) record some perf.data of it
>4) analyze the perf.data by perf script
>
>So in order to have this testcase in perf.test we'd need to call all the
>mentioned functionality within a C function. That's why I think that
>better approach is to use the shell based tests that I am collecting in
>my suite for now:
>
>
># for running the particular testcase for this issue you just need to:
>git clone https://github.com/rfmvh/perftool-testsuite.git
>cd perftool-testsuite/base_probe
>./setup.sh
>./test_advanced.sh
>
>
>The overall approach of that testsuite is to test the tool as it is. So
>both approaches are necessary; both testing of the internal functions by
>perf-test and testing the tool as such from the outside by the suite.
>I am not against extending perf-test set, but I don't think this is the
>right case for it.

Yeah, I agreed, and perf-probe definitely needs it :)
I hope that this is included into the kernel tree so that it can
be synchronously evolving with perf itself.

Thanks!

>
>> - Arnaldo
>
>Regards,
>Michael
>
>
>