[lttng-dev] [barectf] Building /w. Microsoft Visual Studio

[Jean-Francois MONESTIER]

Hello Tracers !

I'm currently having hard times, trying to build a barectf-generated CTF
writer with Microsoft Visual Studio 2008.

Problem resides in the .._bitfield.h file, macro
.._bt_bitfield_write_le( .. ) as __type__( .. ) is a gcc extension :

  warning C4013: '__typeof__' undefined; assuming extern returning int

Are there any M$ compatible bitfield macros/functions around here ? Or
am I on the way to port these myself ?

For what I've seen, I'm only writing 8/16/32/64b data into my stream, so
that the macros should rewrite in a much more simpler way.

I'm currently using barectf v2.1.3


Any help appreciated,
Thanks in advance
-- 
Jean-Francois Monestier
041-6766
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [barectf] Building /w. Microsoft Visual Studio

[Philippe Proulx]

On Thu, Nov 10, 2016 at 12:17 PM, Jean-Francois MONESTIER
 wrote:
> Hello Tracers !
>
> I'm currently having hard times, trying to build a barectf-generated CTF
> writer with Microsoft Visual Studio 2008.
>
> Problem resides in the .._bitfield.h file, macro
> .._bt_bitfield_write_le( .. ) as __type__( .. ) is a gcc extension :
>
>   warning C4013: '__typeof__' undefined; assuming extern returning int
>

That's actually listed in the limitations of barectf (README file):

The current generated C code is not strictly C99 compliant:
statement expressions and the typeof keyword GCC extensions are used
in the generated bitfield macros. The generated C code is known to
be compiled with no warnings using both GCC and Clang.

> Are there any M$ compatible bitfield macros/functions around here ? Or
> am I on the way to port these myself ?
>
> For what I've seen, I'm only writing 8/16/32/64b data into my stream, so
> that the macros should rewrite in a much more simpler way.

Those macros expand to pretty much what you would expect when compiler
optimizations are enabled.

Can you try this branch?

pip3 install
git+https://github.com/efficios/barectf@remove-gnu-dep --upgrade
--force-reinstall

I removed the dependency on __typeof__() and statement expressions,
which are GNU extensions, however I know that MSVC does not support C99,
so there might be other C99 stuff left in there.

Phil

>
> I'm currently using barectf v2.1.3
>
>
> Any help appreciated,
> Thanks in advance
> --
> Jean-Francois Monestier
> 041-6766
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [PATCH lttng-tools v4] Create a dedicated test suite for Perf

[Jérémie Galarneau]

Merged in master and stable-2.9.

Thanks!
Jérémie

On 12 September 2016 at 16:57, Julien Desfossez  wrote:
> Introduce the perf_regression test suite that must be run manually to
> check if the support for the Perf-related features are available on the
> current machine. This test cannot be run automatically since there are
> some platforms where it can fail (VMs, some SoCs, etc).
>
> For now, the test only makes sure that we can trace events with perf
> contexts enabled by raw ID in kernel and user-space. The test only works
> if libpfm is installed on the system and fails if it is not installed.
>
> Signed-off-by: Julien Desfossez 
> ---
>  .gitignore  |   2 +
>  README.md   |   2 +
>  configure.ac|  10 
>  tests/Makefile.am   |   8 +--
>  tests/perf/Makefile.am  |   6 ++
>  tests/perf/find_event.c |  84 ++
>  tests/perf/test_perf_raw.in | 139 
> 
>  tests/perf_regression   |   1 +
>  8 files changed, 248 insertions(+), 4 deletions(-)
>  create mode 100644 tests/perf/Makefile.am
>  create mode 100644 tests/perf/find_event.c
>  create mode 100644 tests/perf/test_perf_raw.in
>  create mode 100644 tests/perf_regression
>
> diff --git a/.gitignore b/.gitignore
> index 263b2a0..93ef389 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -107,6 +107,8 @@ tests/regression/ust/python-logging/test_python_logging
>  /tests/utils/testapp/gen-ust-tracef/gen-ust-tracef
>  /tests/regression/tools/live/live_test
>  /tests/unit/ini_config/ini_config
> +/tests/perf/find_event
> +/tests/perf/test_perf_raw
>
>  # man pages
>  /doc/man/*.1
> diff --git a/README.md b/README.md
> index 22de252..4d72ed4 100644
> --- a/README.md
> +++ b/README.md
> @@ -57,6 +57,8 @@ The following items are _optional_ dependencies:
>  pages with the `--help` option or with the `lttng help` command.
>  Note that without `man`, you cannot get offline help with
>  LTTng-tools commands, not even their usage.
> +  - **libpfm >= 4.0**: needed to run the perf regression test suite.
> +- Debian/Ubuntu package: `libpfm4-dev`
>
>  LTTng-tools supports both the [LTTng Linux Kernel tracer](https://lttng.org)
>  and [LTTng user space tracer](https://lttng.org) released as part of the same
> diff --git a/configure.ac b/configure.ac
> index 5cfe973..d4e12a7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -480,6 +480,13 @@ AC_CHECK_LIB([c], [open_memstream],
>  ]
>  )
>
> +# check for libpfm
> +AC_CHECK_LIB([pfm], [pfm_initialize],
> +[
> + have_libpfm=yes
> + ])
> +AM_CONDITIONAL([LTTNG_TOOLS_BUILD_WITH_LIBPFM], [test "x$have_libpfm" = 
> "xyes"])
> +
>  AC_ARG_ENABLE([git-version],
>[AC_HELP_STRING([--disable-git-version],
>[Do not use the git version for the build])],
> @@ -1022,6 +1029,7 @@ AC_CONFIG_FILES([
> tests/stress/Makefile
> tests/unit/Makefile
> tests/unit/ini_config/Makefile
> +   tests/perf/Makefile
> tests/utils/Makefile
> tests/utils/tap/Makefile
> tests/utils/testapp/Makefile
> @@ -1032,6 +1040,8 @@ AC_CONFIG_FILES([
>
>  # Inject variable into python test script.
>  
> AC_CONFIG_FILES([tests/regression/ust/python-logging/test_python_logging],[chmod
>  +x tests/regression/ust/python-logging/test_python_logging])
> +# Inject LTTNG_TOOLS_BUILD_WITH_LIBPFM variable in test script.
> +AC_CONFIG_FILES([tests/perf/test_perf_raw],[chmod +x 
> tests/perf/test_perf_raw])
>
>  AC_OUTPUT
>
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 3600e99..d460fb6 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -1,8 +1,8 @@
>  SUBDIRS =
> -DIST_SUBDIRS = utils regression unit stress destructive
> +DIST_SUBDIRS = utils regression unit stress destructive perf
>
>  if BUILD_TESTS
> -SUBDIRS += . utils regression unit stress destructive
> +SUBDIRS += . utils regression unit stress destructive perf
>  if HAS_PGREP
>  check-am:
> $(top_srcdir)/tests/utils/warn_processes.sh $(PGREP)
> @@ -14,8 +14,8 @@ else
>  endif
>
>
> -dist_noinst_SCRIPTS = run.sh fast_regression long_regression root_regression 
> root_destructive_tests
> -EXTRA_DIST = run.sh fast_regression long_regression root_regression README 
> root_destructive_tests
> +dist_noinst_SCRIPTS = run.sh fast_regression long_regression root_regression 
> root_destructive_tests perf_regression
> +EXTRA_DIST = run.sh fast_regression long_regression root_regression README 
> root_destructive_tests perf_regression
>
>  all-local:
> @if [ x"$(srcdir)" != x"$(builddir)" ]; then \
> diff --git a/tests/perf/Makefile.am b/tests/perf/Makefile.am
> new file mode 100644
> index 000..40bb754
> --- /dev/null
> +++ b/tests/perf/Makefile.am
> @@ -0,0 +1,6 @@
> +if LTTNG_TOOLS_BUILD_WITH_LIBPFM
> +LIBS += -lpfm
> +
> +noinst_PROGRAMS = find_event
> +find_event_SOURCES = find_event.c
> +endif
> di

Re: [lttng-dev] [PATCH lttng-tools v2] Fix: test cases now rely on explicit workloads

[Francis Deslauriers]

Agreed. Let me send this in a final version of this patch.

Thanks,
Francis

2016-11-08 16:07 GMT-05:00 Mathieu Desnoyers :

> - On Nov 8, 2016, at 3:46 PM, Francis Deslauriers <
> francis.deslauri...@efficios.com> wrote:
>
> 2016-11-08 15:06 GMT-05:00 Nathan Lynch :
>
>> On 11/08/2016 01:49 PM, Francis Deslauriers wrote:
>> > Run a process explicitly in the tracing session to generate the enabled
>> events
>> > rather than relying on the events generated by the lttng CLI.
>>
>> [...]
>>
>> > diff --git a/tests/regression/kernel/test_all_events
>> b/tests/regression/kernel/test_all_events
>> > index 50002f4..80a8020 100755
>> > --- a/tests/regression/kernel/test_all_events
>> > +++ b/tests/regression/kernel/test_all_events
>> > @@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
>> >  TESTDIR=$CURDIR/../..
>> >  NUM_TESTS=8
>> >
>> > +TESTCMD="grep -V -q > /dev/null"
>> > +
>>
>> What was wrong with /bin/true, as in v1 of this patch?
>
> I used grep because the configure script looks for it already
> At the moment, we don't check if /bin/true is installed on the machine
> using the configure script.
>
>
>> FYI, Busybox grep doesn't know -V:
>>
>> # grep -V -q >/dev/null
>> grep: invalid option -- 'V'
>> BusyBox v1.24.1 (2016-11-08 12:59:13 CST) multi-call binary.
>>
>> Usage: grep [-HhnlLoqvsriwFE] [-m N] [-A/B/C N] PATTERN/-e PATTERN.../-f
>> FILE [FILE]...
>>
>> # echo $?
>> 1
>>
>> It looks like the testcases don't care about the exit status of TESTCMD,
>> but you may want to redirect stderr to /dev/null as well.
>>
> Good point.
> I could do: grep "foo" /dev/null
>
>
> utils/utils.sh:45:# We set the default lttng-sessiond path to /bin/true to
> prevent the spawning
> utils/utils.sh:49:export LTTNG_SESSIOND_PATH="/bin/true"
>
> already used.
>
> So unless anyone complain about it, let's use it.
>
> If someone complains, then we need to fix the configure detection.
>
> Thanks,
>
> Mathieu
>
>
> Thank you,
> --
> Francis Deslauriers
> Software developer
> EfficiOS inc.
>
>>
>> ___
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>
>
>
>
>
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>



-- 
Francis Deslauriers
Software developer
EfficiOS inc.
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH lttng-tools v3] Fix: test cases now rely on explicit workloads

[Francis Deslauriers]

Run a process explicitly in the tracing session to generate the enabled events
rather than relying on the events generated by the lttng CLI.
---
 tests/regression/kernel/test_all_events  |  6 ++
 tests/regression/kernel/test_event_basic | 14 --
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/tests/regression/kernel/test_all_events 
b/tests/regression/kernel/test_all_events
index 50002f4..713c717 100755
--- a/tests/regression/kernel/test_all_events
+++ b/tests/regression/kernel/test_all_events
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
 TESTDIR=$CURDIR/../..
 NUM_TESTS=8
 
+TESTCMD="/bin/true"
+
 source $TESTDIR/utils/utils.sh
 
 function test_all_event()
@@ -33,6 +35,10 @@ function test_all_event()
lttng_enable_kernel_event $SESSION_NAME
 
start_lttng_tracing_ok
+
+   # Running a process and waiting for its completion forces the 
triggering of a
+   # sched_switch event
+   eval ${TESTCMD}
stop_lttng_tracing_ok
 
validate_trace "sched_switch" $TRACE_PATH
diff --git a/tests/regression/kernel/test_event_basic 
b/tests/regression/kernel/test_event_basic
index aeca02b..1a10a2c 100755
--- a/tests/regression/kernel/test_event_basic
+++ b/tests/regression/kernel/test_event_basic
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
 TESTDIR=$CURDIR/../..
 NUM_TESTS=20
 
+TESTCMD="/bin/true"
+
 source $TESTDIR/utils/utils.sh
 
 function test_event_basic()
@@ -32,14 +34,18 @@ function test_event_basic()
 
lttng_enable_kernel_event $SESSION_NAME "sched_switch"
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
-   lttng_enable_kernel_event $SESSION_NAME "sched_process_free"
+   lttng_enable_kernel_event $SESSION_NAME "sched_process_fork"
 
start_lttng_tracing_ok
+
+   # Running a process and waiting for its completion forces the 
triggering of
+   # fork, sched_switch and exit events
+   eval ${TESTCMD}
stop_lttng_tracing_ok
 
validate_trace "sched_switch" $TRACE_PATH
validate_trace "sched_process_exit" $TRACE_PATH
-   validate_trace "sched_process_free" $TRACE_PATH
+   validate_trace "sched_process_fork" $TRACE_PATH
 
destroy_lttng_session_ok $SESSION_NAME
 
@@ -57,6 +63,10 @@ function test_enable_after_start()
 
start_lttng_tracing_ok
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
+
+   # Running a process and waiting for its completion forces the 
triggering of
+   # sched_switch and exit events
+   eval ${TESTCMD}
stop_lttng_tracing_ok
 
validate_trace "sched_switch" $TRACE_PATH
-- 
2.7.4

___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] [barectf] Building /w. Microsoft Visual Studio

[Philippe Proulx]

On Thu, Nov 10, 2016 at 1:25 PM, Philippe Proulx
 wrote:
> On Thu, Nov 10, 2016 at 12:17 PM, Jean-Francois MONESTIER
>  wrote:
>> Hello Tracers !
>>
>> I'm currently having hard times, trying to build a barectf-generated CTF
>> writer with Microsoft Visual Studio 2008.
>>
>> Problem resides in the .._bitfield.h file, macro
>> .._bt_bitfield_write_le( .. ) as __type__( .. ) is a gcc extension :
>>
>>   warning C4013: '__typeof__' undefined; assuming extern returning int
>>
>
> That's actually listed in the limitations of barectf (README file):
>
> The current generated C code is not strictly C99 compliant:
> statement expressions and the typeof keyword GCC extensions are used
> in the generated bitfield macros. The generated C code is known to
> be compiled with no warnings using both GCC and Clang.
>
>> Are there any M$ compatible bitfield macros/functions around here ? Or
>> am I on the way to port these myself ?
>>
>> For what I've seen, I'm only writing 8/16/32/64b data into my stream, so
>> that the macros should rewrite in a much more simpler way.
>
> Those macros expand to pretty much what you would expect when compiler
> optimizations are enabled.
>
> Can you try this branch?
>
> pip3 install
> git+https://github.com/efficios/barectf@remove-gnu-dep --upgrade
> --force-reinstall
>
> I removed the dependency on __typeof__() and statement expressions,
> which are GNU extensions, however I know that MSVC does not support C99,
> so there might be other C99 stuff left in there.

I just tested with VS2010 with this branch as of a845de1 and it builds
and works! I'll wait for your response anyway as for VS2008. You can
also install from a Zip file that you download on GitHub,
:

pip3 install remove-gnu-dep.zip --upgrade --force-reinstall

Phil

>
> Phil
>
>>
>> I'm currently using barectf v2.1.3
>>
>>
>> Any help appreciated,
>> Thanks in advance
>> --
>> Jean-Francois Monestier
>> 041-6766
>> ___
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev