Re: [lttng-dev] [babeltrace2]about python self-defined plugin loading

On 2024-04-26 09:56, Wu, Yannan via lttng-dev wrote: > Hihi, Kienan, > > I finally find a workaround. I could success with the following code: > file_name = "bt_plugin_latency_filter.py" > current_directory=os.getcwd() > > file_path = os.path.join(current_directory, file_name) >

Re: [lttng-dev] Debugging Libaries in Babeltrace 2

On 10/25/23 03:29, Seidl, Aron via lttng-dev wrote: > Hi Simon, > Thanks for your quick answer! > I run GDB like this: > gdb --args ./babeltrace2 /home/aron/Schreibtisch/kernel4 -o text > (I'm in src/cli/.libs) Don't do that (try to debug the binary in .libs directly). > I don't think I've ever

Re: [lttng-dev] Debugging Libaries in Babeltrace 2

On 10/24/23 11:52, Seidl, Aron via lttng-dev wrote: > Hello guys, > I’m currently a student at the company Carl Zeiss in Oberkochen Germany. I’d > like to trace the Kernel from our CMM-Controller with CTF and convert it to > plain text, like Babeltrace 2 does. To understand how Babeltrace 2

Re: [lttng-dev] C API message iterator example for libbabeltrace2

On 8/20/22 12:14, Maksim Khmelevskiy via lttng-dev wrote: > Hi Simon, > thanks for the reply! > What I came up with for now is this example > . > It's probably has a lot of design mistakes but it's at least

Re: [lttng-dev] C API message iterator example for libbabeltrace2

On 8/12/22 09:19, Maksim Khmelevskiy via lttng-dev wrote: > Hi, > > there is a nice py message iterator example > but for C > API only plugins are covered with examples, do you think it would make > sense to create an example of a

Re: [lttng-dev] [PATCH lttng-tools] Copyright ownership transfer

On 2022-01-14 3:48 p.m., Jérémie Galarneau via lttng-dev wrote: > Apply copyright ownership transfer from David Goulet, Julien Desfossez, > and Simon Marchi to EfficiOS Inc. > > Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030087.html > Link: https://lists.lttn

Re: [lttng-dev] Transfer of LTTng copyright ownership: Simon Marchi

rly affects the lttng-tools files with copyright: > > Copyright (C) 201N Simon Marchi > > Thank you! > > Mathieu Yes. Thanks, Simon ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: [lttng-dev] Babeltrace trimmer segfaults on custom trace

On 2021-05-04 9:57 p.m., Simon Marchi via lttng-dev wrote: > I tried to see if it would be possible for you > to just not use packets, but unfortunately I stumbled on what looks like > a bug in the CTF metadata parser, it hardcodes whether streams classes > have packets to true: >

Re: [lttng-dev] Babeltrace trimmer segfaults on custom trace

On 2021-05-04 10:21 a.m., Dimitri Scheftelowitsch via lttng-dev wrote: > > Hi, > > as mentioned on the IRC channel, babeltrace2 (both HEAD and current release > in the lttng Ubuntu 20 repo) aborts with a violated precondition in > `bt_clock_snapshot_get_ns_from_origin` on some custom traces we

Re: [lttng-dev] Babeltrace2 sink.ctf.fs creating many subdirectories

On 2020-04-03 8:50 a.m., Muresan, Heman via lttng-dev wrote: > Hi, > >   > > I’m using bt2 to combine multiple archives and I’m noticing some weird > behavior. Not sure if its something on my end. > >   > > I have a bunch of ctf trace archives and I am trying to combine them into one > ctf

Re: [lttng-dev] babletrace2 graph performance considerations

On 2020-03-30 6:34 p.m., Rocky Dunlap via lttng-dev wrote: > Each graph would parse the whole stream?  What if I only connect one of the > outputs from the source.ctf.fs?  I would think it would only access that one > stream file. Hmm yeah perhaps, I didn't think of that. Give it a try! Simon

Re: [lttng-dev] babletrace2 graph performance considerations

On 2020-03-30 1:30 p.m., Rocky Dunlap wrote: > In my case I have CTF trace where some analyses can be performed on a > per-stream basis (no need to mux the streams together).  In this case, I was > thinking that it would make sense to thread over the streams.  However, I > think can easily do

Re: [lttng-dev] bt2 python - accessing component instances added to graph

On 2020-03-30 1:24 a.m., Rocky Dunlap via lttng-dev wrote: > I noticed that when I add a component to a bt2 graph, e.g.: > > sink = g.add_component(SinglePETSink, "sink"+str(idx)) > > The return value "sink" is not actually an instance of SinglePETSink (which > has been defined as a local

Re: [lttng-dev] babletrace2 graph performance considerations

On 2020-03-30 12:10 a.m., Rocky Dunlap via lttng-dev wrote: > A couple of questions on performance considerations when setting up bt2 > processing graphs. > > 1.  Do parts of the processing graph that can execute concurrently do so?  > Does the user have any control over this, e.g., by creating

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-23 12:56 p.m., Rocky Dunlap wrote: > Simon, > > Success!  This change worked and I was able to build and install with icc.  > Thank you! Ok, thanks. Out of curiosity, did run a "make check"? That would validate that the Python bindings (and everything else) works properly. > I

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-23 12:05 p.m., Rocky Dunlap wrote: > Simon, > > Yes, I will be happy to give this a try.  What's the easiest way to get this > patch?  (Sorry, I'm less familiar with Gerrit...) > > Rocky You need a babeltrace git repository. If you don't already have one, you can clone it from

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-20 11:12 p.m., Simon Marchi via lttng-dev wrote: > So since distutils really wants to compile the Python native modules using > all the same > flags as the Python interpreter was built with, I presume that they really > assume that > you'll be using the exact same too

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-20 6:32 p.m., Rocky Dunlap via lttng-dev wrote: > Simon, > > Thanks for this - so after I updated to gcc 9.2, the shared libraries command > ran correctly and the build finished. All the tests pass and I was able to > read in a CTF trace from a python script.   > > The issue was

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-20 5:55 p.m., Rocky Dunlap wrote: > Simon, > > I was able to get past the issue by passing "--enable-compile-warnings=yes" > to configure. > > It get a lot further, then fails here: > > gcc -pthread -shared -L/apps/intel/intelpython3/lib >

Re: [lttng-dev] Babeltrace2 - compilation error with intel18

On 2020-03-20 5:10 p.m., Rocky Dunlap via lttng-dev wrote: > I am trying to compile BT2 with Python bindings using Intel18.  I receive the > following error during the build: Hi Rocky, I don't think we claim to support the Intel compiler, so you might be a bit on your own here. Although if you

Re: [lttng-dev] bt2 Python quick start/examples?

/ > > Slowly getting there. > >> >> In lieu of that, where is the best place to find at least a few examples of >> using the bt2 Python API for basic trace processing tasks? > > Simon Marchi have some examples [1] that have been used in his talk [2][3]. > > Hope this h

Re: [lttng-dev] [babeltrace][PATCH] fs.c: initialize the other_entry variable

On 2020-03-11 9:39 a.m., mingli...@windriver.com wrote: > From: Mingli Yu > > Initialize the pointer other_entry to fix the below error: > | ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function > 'ds_index_insert_ds_index_entry_sorted': > |

Re: [lttng-dev] [PATCH v2 lttng-ust] Introduce vtracef

On 2020-02-05 9:55 p.m., Simon Marchi wrote: > Ok, so I poked Phil the doc guy about this, and he spotted that the problem > is actually in the > asciidoc -> docbook conversion. He provided the patch provided below. I'll > try to clean up > that patch and send it formally to

[lttng-dev] [PATCH lttng-ust] Fix: generation of man pages with multiple refnames

tps://lists.lttng.org/pipermail/lttng-dev/2020-February/029524.html Signed-off-by: Simon Marchi Signed-off-by: Philippe Proulx --- doc/man/Makefile.am | 6 -- doc/man/asciidoc.conf | 20 2 files changed, 4 insertions(+), 22 deletions(-) diff --git a/doc/man/Makefile.a

Re: [lttng-dev] [PATCH v2 lttng-ust] Introduce vtracef

On 2020-02-05 8:17 p.m., Simon Marchi wrote: > On 2020-02-05 6:36 p.m., Maxime Roussin-Belanger wrote: >> vtracef accepts a va_list argument to simplify tracing >> functions which use a va_list >> >> Here's an example from wpa_supplicant that I wanted to >> trac

Re: [lttng-dev] [PATCH v2 lttng-ust] Introduce vtracef

On 2020-02-05 6:36 p.m., Maxime Roussin-Belanger wrote: > vtracef accepts a va_list argument to simplify tracing > functions which use a va_list > > Here's an example from wpa_supplicant that I wanted to > trace: > > void wpa_debug(int level, const char* fmt, ...) { > > va_list ap; >

Re: [lttng-dev] [PATCH] Introduce vtracef

On 2020-01-31 6:17 p.m., Maxime Roussin-Bélanger wrote: >> On 2020-01-31 4:55 p.m., Maxime Roussin-Belanger wrote: >> > vtracef accepts a va_list argument to simplify tracing >> > functions which use a va_list >> > >> > Here's an example from wpa_supplicant that I wanted to >> > trace: >> > >> >

Re: [lttng-dev] [PATCH] Introduce vtracef

Hi Maxime, Tip for next time: this mailing is used for many projects, so it helps to include the project name in the patch prefix. You can do so by using --subject-prefix="PATCH lttng-ust" on you git-send-email command line. On 2020-01-31 4:55 p.m., Maxime Roussin-Belanger wrote: > vtracef

Re: [lttng-dev] lttng-tools - 2.11 failed: checking for _cds_lfht_new in -lurcu-cds... no configure: error: Userspace RCU (liburcu) >= 0.9.0 is needed

On 2020-01-13 5:47 p.m., bhanu kiran chaluvadi wrote: > Hi, > > I am trying to cross compile lttng-tools to host: i686-pc-linux-gnu(dedian 8 > - jessie )  from build: x86_64-pc-linux-gnu (ubuntu - 18.04). > > > export PATH=/opt/x-tools/bin:$PATH > export

Re: [lttng-dev] [PATCH lttng-tools] configure.ac: Remove duplicated CMD_DESCR_ROTATE definition

On 2019-08-19 9:47 p.m., Simon Marchi wrote: > On 2019-05-27 11:52 a.m., Simon Marchi wrote: >> CMD_DESCR_ROTATE is defined twice by configure. This breaks configuring >> with "-Werror -Wall", as some test programs don't compile due to: >> >> configure

[lttng-dev] [PATCH lttng-ust] doc: fix build failure due to wrong whitespace character

local] Error 1 I inadvertently inserted a character that looks like a space, but that is not a space. make tries to interpret it as a target name, which obviously fails. Replace it with a proper space. Signed-off-by: Simon Marchi --- doc/examples/Makefile.am | 2 +- 1 file changed, 1 insertion(+),

Re: [lttng-dev] [PATCH 1/2] doc: pass AR when building examples

On 2019-11-18 12:15 p.m., Mathieu Desnoyers wrote: > Both patches merged into lttng-ust master branch (only). > > If you need those backported, please submit separate patches for stable > branches, as those do not apply cleanly because the following commit is > in master but not in stable

[lttng-dev] [PATCH 2/2] doc: reformat long lines in doc/examples/Makefile.am

t a new subshell, so it's unnecessary to do "cd .." before the subshell exits. I'm not too sure what's the best way to indent it, feel free to modify it before changing the patch. Signed-off-by: Simon Marchi --- doc/examples/Makefile.am | 56 ++--

[lttng-dev] [PATCH 1/2] doc: pass AR when building examples

esn't hurt to have it there. [1] https://lists.lttng.org/pipermail/lttng-dev/2019-November/029388.html Reported-by: Rolf Eike Beer Signed-off-by: Simon Marchi --- configure.ac | 1 + doc/examples/Makefile.am | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/conf

Re: [lttng-dev] Wrong "ar" used when cross-building lttng

On 2019-11-15 3:18 a.m., Rolf Eike Beer wrote: > Simon Marchi wrote: >> On 2019-11-14 11:24 a.m., Rolf Eike Beer wrote: > >>> I have not checked latest git, but maybe you may want to fix this warning, >>> too? >>> >>> With 2.11.0 release tarball: &g

Re: [lttng-dev] Wrong "ar" used when cross-building lttng

On 2019-11-14 11:24 a.m., Rolf Eike Beer wrote: > Works for me. Thanks. > I have not checked latest git, but maybe you may want to fix this warning, > too? > > With 2.11.0 release tarball: > > -./configure: line 24663: test: -eq: unary operator expected > > Greetings, > > Eike Hmm I don't

Re: [lttng-dev] Wrong "ar" used when cross-building lttng

t doc/examples/hello-static-lib/Makefile is not directly influenced by the configure checks. It will not pick up the right tools if you run "make" directly in doc/examples/hello-static-lib, but only if you run it from a directory above. Simon From cb819ba1e9dbba612dd22d143c4fb57185b6ac7b M

[lttng-dev] [PATCH lttng-modules] Make bitfield.h C++-friendly

This patch changes bitfield.h to be usable in C++11. It will probably never be compiled as C++ in the context of lttng-modules, but this is just to keep things sync'ed across projects. Signed-off-by: Simon Marchi --- lib/bitfield.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion

[lttng-dev] [PATCH lttng-ust] Make bitfield.h C++-friendly

This patch changes bitfield.h to be usable in C++11. It will probably never be compiled as C++ in the context of lttng-ust, but this is just to keep things sync'ed across projects. Signed-off-by: Simon Marchi --- include/lttng/bitfield.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion

Re: [lttng-dev] [PATCH lttng-tools] configure.ac: Remove duplicated CMD_DESCR_ROTATE definition

On 2019-05-27 11:52 a.m., Simon Marchi wrote: > CMD_DESCR_ROTATE is defined twice by configure. This breaks configuring > with "-Werror -Wall", as some test programs don't compile due to: > > configure:16990: gcc -o conftest -Wall -Werror conftest.c >&am

Re: [lttng-dev] [PATCH lttng-tools] Fix: fix compilation errors when using --disable-epoll

On 2019-05-27 12:28 p.m., Simon Marchi wrote: > I get this error: > > CC compat-poll.lo > /home/smarchi/src/lttng-tools/src/common/compat/compat-poll.c: In > function ‘compat_poll_wait’: > /home/smarchi/src/lttng-tools/src/common/compat/compat-poll.c:353:

[lttng-dev] [PATCH] Fix: fix compilation errors when using --disable-epoll

". I'll tackle this issue separately. I only built-tested the proposed change, and I don't know anything about this code, so please check carefully that it is right. Signed-off-by: Simon Marchi --- src/common/compat/compat-poll.c | 2 +- tests/unit/test_utils_compat_poll.c | 12 +++-

[lttng-dev] [PATCH] configure.ac: Remove duplicated CMD_DESCR_ROTATE definition

efined [-Werror] #define CONFIG_CMD_DESCR_ROTATE "Archive a tracing session’s current trace chunk" conftest.c:154: note: this is the location of the previous definition #define CONFIG_CMD_DESCR_ROTATE "Archive a tracing session's current trace chunk" cc1: all warnings being

Re: [lttng-dev] [PATCH v5 babeltrace 1/1] Fix: bitfield: shift undefined/implementation defined behaviors

On 2019-05-13 4:20 p.m., Mathieu Desnoyers wrote: > bitfield.h uses the left shift operator with a left operand which > may be negative. The C99 standard states that shifting a negative > value is undefined. > > When building with -Wshift-negative-value, we get this gcc warning: > > In file

Re: [lttng-dev] [PATCH babeltrace 2/2] Extend test-bitfield coverage

On 2019-05-10 1:47 p.m., Mathieu Desnoyers wrote: > test-bitfield was mainly testing various write unit size. Add > variations of read unit size as well. > > Previously, the test was only covering input from a 32-bit integer. > Additionally test source and destination of 64-bit. > > Change-Id:

Re: [lttng-dev] [PATCH babeltrace v3] Fix: bitfield: left shift undefined behavior

On 2019-05-09 10:02 a.m., Simon Marchi wrote: > I might have more cases for you to investigate :) > > Can you try building with -fsanitize=undefined and run test_bitfield? I get > some: > > /home/smarchi/src/babeltrace/tests/lib/test_bitfield.c:222:4: runtime error: > l

Re: [lttng-dev] [PATCH babeltrace v3] Fix: bitfield: left shift undefined behavior

On 2019-05-08 6:23 p.m., Mathieu Desnoyers wrote: > bitfield.h uses the left shift operator with a left operand which > may be negative. The C99 standard states that shifting a negative > value is undefined. > > When building with -Wshift-negative-value, we get this gcc warning: > > In file

Re: [lttng-dev] [PATCH babeltrace v2] Fix: bitfield: left shift undefined behavior

On 2019-05-08 11:59 a.m., Mathieu Desnoyers wrote: > What compiler do you use, and which compilation flags ? > (it works here) "gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0", which is the system compiler on Ubuntu 18.04. I just built with ./configure 'CFLAGS=-g3 -O0 -fsanitize=address -Wall' and

Re: [lttng-dev] [PATCH babeltrace v2] Fix: bitfield: left shift undefined behavior

On 2019-05-08 10:39 a.m., Mathieu Desnoyers wrote: > bitfield.h uses the left shift operator with a left operand which > may be negative. The C99 standard states that shifting a negative > value is undefined. > > When building with -Wshift-negative-value, we get this gcc warning: > > In file

Re: [lttng-dev] [PATCH babeltrace] Fix: bitfield: left shift undefined behavior

On 2019-05-07 4:40 p.m., Mathieu Desnoyers wrote: > bitfield.h uses the left shift operator with a left operand which > may be negative. The C99 standard states that shifting a negative > value is undefined. Please add a reference to the original problem that prompted you to do this change in the

Re: [lttng-dev] [PATCH lttng-tools] Fix: nsec diff can be negative leading to expeditive connection timeout

On 2018-11-08 17:17, Simon Marchi wrote: On 2018-11-08 17:08, Jonathan Rajotte wrote: The nanoseconds part of the timespec struct time_a is not always bigger than time_b since it wrap around each seconds. Use the absolute value of the nanosecond difference to perform unsigned long operation

Re: [lttng-dev] [PATCH lttng-tools] Fix: nsec diff can be negative leading to expeditive connection timeout

On 2018-11-08 17:08, Jonathan Rajotte wrote: The nanoseconds part of the timespec struct time_a is not always bigger than time_b since it wrap around each seconds. Use the absolute value of the nanosecond difference to perform unsigned long operation. Signed-off-by: Jonathan Rajotte ---

Re: [lttng-dev] [RELEASE] Babeltrace 2.0.0-pre1

On 2017-06-13 20:38, Jérémie Galarneau wrote: FYI, the in-tree plugins are embed-able by setting BT_BUILT_IN_PLUGINS=1 at configure time. I was wondering why this was an environment variable and not a command line flag to configure. I find env var-related problems more difficult to diagnose

Re: [lttng-dev] Problem with Babeltrace

On 2016-10-24 11:31, Nathan Lynch wrote: On 10/24/2016 03:30 AM, Tim Tannert wrote: Hey, everytime when I start babeltrace: *babeltrace --version* or *lttng view *I'll get following message: babeltrace: symbol lookup error: babeltrace: undefined symbol: opt_debug_info_full_path Seems your

Re: [lttng-dev] [PATCH lttng-modules] Add support for i2c tracepoints

d". But it's your call, just tell me which one you prefer. > I think we should keep it at the probe level, like you do in your prototype. > >> >> >> From 69aa1c3d73b5b0dbf031b90c6e38d4b2a0ad8699 Mon Sep 17 00:00:00 2001 >> From: Simon Marchi <simon.mar.

Re: [lttng-dev] [PATCH lttng-modules] Add support for i2c tracepoints

On 16-10-03 06:21 PM, Mathieu Desnoyers wrote: > - On Oct 3, 2016, at 2:21 PM, Simon Marchi simon.mar...@ericsson.com > wrote: > >> This patch teaches lttng-modules about the i2c tracepoints in the Linux >> kernel. >> >> It contains the followin

[lttng-dev] [PATCH lttng-modules] Add support for i2c tracepoints

building this module against a kernel without CONFIG_I2C, and it built fine (the required types are unconditionally defined). So I don't think any "#if CONFIG_I2C" or similar are required. Signed-off-by: Simon Marchi <simon.mar...@ericsson.com> --- instrumentation/events/lttng-m

[lttng-dev] [PATCH babeltrace] debug info: Call register_event_debug_infos for all events

d", func = "trace_bin_info_cb+0xfa" } }, ... ... lttng_ust_statedump:build_id: { cpu_id = 1 }, { vpid = 28991, ip = 0x7FD266656656, debug_info = { bin = "liblttng-ust.so.0.0.0+0x35656", func = "trace_build_id_cb+0xbc" } }, ... which seems more reasonnable. Signe

[lttng-dev] [PATCH babeltrace 2/2] CTF writer: Add function to add an integer environment field value

, whereas it will now produce an integer version. However, I think it will now behave more closely to the expectation of a lambda user. Example: w.add_environment_field("foo", 2) Result before: env { foo = "2"; }; Result after: env { foo = 2; }; Signed-

[lttng-dev] [PATCH babeltrace 1/2] python: Add stream event context support

example. Signed-off-by: Simon Marchi <simon.mar...@polymtl.ca> --- bindings/python/babeltrace/examples/ctf_writer.py | 7 +++ bindings/python/babeltrace/nativebt.i | 8 +++ bindings/python/babeltrace/writer.py | 61 +++ 3 files changed, 76 inse

[lttng-dev] Segfault when dlopening/dlclosing instrumented shared libraries

Hi, I'd like to know if I am doing anything wrong, or if this is expected not to work. I made a mini program that does dlopen/dlsym/call/dlclose with two shared libraries that are instrumented with LTTng (each shared object is its own tracepoint provider). The program segfaults when

Re: [lttng-dev] [PATCH babeltrace] Don't use the .so extension on test assets

On 2016-05-04 12:25, Michael Jeanson wrote: Some packaging system like dpkg-source in native mode used by our daily build system will filter out files considered unclean prior to the build. This behavior results in our test assets being deleted and the subsequent fails the make check. Since we

Re: [lttng-dev] [PATCH babeltrace] Don't use the .so extension on test assets

On 2016-05-04 13:15, Michael Jeanson wrote: - On May 4, 2016, at 1:12 PM, Simon Marchi sim...@simark.ca wrote: On 2016-05-04 12:25, Michael Jeanson wrote: Some packaging system like dpkg-source in native mode used by our daily build system will filter out files considered unclean prior

Re: [lttng-dev] [PATCH 1/3] tests/lib/Makefile.am: Remove test_seek_empty_packet and test_seek_big_trace from SCRIPT_LIST

On 2016-04-28 14:28, Michael Jeanson wrote: - On Apr 28, 2016, at 12:44 PM, Simon Marchi simon.mar...@polymtl.ca wrote: Ok thanks. Just an idea: I find it quite cumbersome to add a new entry in configure.ac for each test script that we want autoconf to process (such as in patch 3/3). I

Re: [lttng-dev] [PATCH 1/3] tests/lib/Makefile.am: Remove test_seek_empty_packet and test_seek_big_trace from SCRIPT_LIST

On 2016-04-28 12:16, Michael Jeanson wrote: - On Apr 27, 2016, at 11:04 PM, Simon Marchi simon.mar...@polymtl.ca wrote: On 2016-04-27 22:52, Simon Marchi wrote: Since these files are generated by autoconf, they shouldn't be included in SCRIPT_LIST, which is the list of scripts to copy

Re: [lttng-dev] [PATCH 1/3] tests/lib/Makefile.am: Remove test_seek_empty_packet and test_seek_big_trace from SCRIPT_LIST

On 2016-04-27 22:52, Simon Marchi wrote: Since these files are generated by autoconf, they shouldn't be included in SCRIPT_LIST, which is the list of scripts to copy from the source directory to the build directory. This gets rid of these warnings when building: cp: cannot stat '/home/simark

[lttng-dev] [PATCH 3/3] tests/lib: Make test_dwarf and test_bin_info tests work out-of-tree

When building out of tree, these tests fail to find the test data. This patch makes them (their _complete wrappers, actually) generated by Autoconf, so the proper path to the test data (which is in the source directory) can be written. Signed-off-by: Simon Marchi <simon.mar...@polymtl

[lttng-dev] [PATCH 2/3] tests/lib/Makefile.am: use DISTCLEANFILES instead of CLEANFILES

. Signed-off-by: Simon Marchi <simon.mar...@polymtl.ca> --- tests/lib/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/lib/Makefile.am b/tests/lib/Makefile.am index a08cbf6..b39bd34 100644 --- a/tests/lib/Makefile.am +++ b/tests/lib/Makefile.am @@ -43,7

[lttng-dev] [PATCH 1/3] tests/lib/Makefile.am: Remove test_seek_empty_packet and test_seek_big_trace from SCRIPT_LIST

/test_seek_big_trace': No such file or directory cp: cannot stat '/home/simark/src/babeltrace/tests/lib/test_seek_empty_packet': No such file or directory Signed-off-by: Simon Marchi <simon.mar...@polymtl.ca> --- tests/lib/Makefile.am | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a

Re: [lttng-dev] [barectf] Support for empty payload ?

On 2016-03-25 10:14, Jean-François Monestier wrote: Hello Tracers, Does anyone know whether barectf supports some sort of empty payloads for events specified in the .yaml configuration file ? Something such as the well-known lttng_ust_statedump:start event : event { name =

Re: [lttng-dev] [PATCH urcu] Fix CPU_{SET, ZERO} configure checks when using -Werror

On 1 December 2015 at 11:39, Simon Marchi <simon.mar...@ericsson.com> wrote: > I noticed a build failure in the tests when building with > CFLAGS="-Werror". > > In file included from test_urcu.c:38:0: > ../../tests/common/cpuset.h:38:0: error: "CPU_ZER

Re: [lttng-dev] [PATCH urcu] Fix CPU_{SET, ZERO} configure checks when using -Werror

On 1 December 2015 at 15:45, Simon Marchi <simon.mar...@polymtl.ca> wrote: > Please note that this patch is for urcu. The subject prefix I had set > ([PATCH urcu]) appears in the message source, but not in the real > subject, I am not sure why. Ah, please disregard. I think

Re: [lttng-dev] URCU on the Xeon Phi

On 15 November 2015 at 14:58, Michel Dagenais <michel.dagen...@polymtl.ca> wrote: > Simon Marchi worked on the Xeon Phi. He should be able to tell you more. > Basically the Phi is compatible with older "pentium" presumably a design > decision to put simpler cores but

Re: [lttng-dev] Ubuntu Package for LTTng-UST Compiled with Debug Logging On By Default

On 22 October 2015 at 19:35, Brian Robbins wrote: > Hello, > > > > The Linux build of CoreCLR now supports tracing using LTTng-UST. One > artifact that we noticed when running on Ubuntu 14.04 in our CI is that apps > running on CoreCLR all have an LTTng warning written to

Re: [lttng-dev] babeltrace foreign builds broken by 384246569494

satisfaction, I'll > gladly accept an alternative solution as I may have failed to address > the problem in the most efficient way. The fix you suggest is very much what I had in mind. Yours truly, Simon Marchi ___ lttng-dev mailing list lttng-

Re: [lttng-dev] babeltrace foreign builds broken by 384246569494

oded path in their build description file. If top_srcdir and top_builddir were willfully chosen, then please ignore this comment. Best Regards, Simon Marchi ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [PATCH ust] Add missing --record in Python's Makefile

local' failed make[1]: *** [install-exec-local] Error 1 make[1]: Leaving directory '/home/simark/src/lttng-ust/liblttng-ust-python-agent' Makefile:594: recipe for target 'install-am' failed make: *** [install-am] Error 2 Signed-off-by: Simon Marchi <simon.mar...@polymtl.ca> --- liblttng-ust-py

[lttng-dev] [RFC PATCH lttng-ust] Produce section with tracepoint callsite addresses

There used to be an integration between lttng-ust 0.x and gdb, where gdb could list locations of ust tracepoints and put its own tracepoints there. That means that this old-style lttng-ust marker: trace_mark(ust, bar33, "str %s", "FOOBAZ"); could be used to set a gdb tracepoint like this:

Re: [lttng-dev] [RFC PATCH lttng-ust] Produce section with tracepoint callsite addresses

On 2 September 2015 at 17:49, Simon Marchi <simon.mar...@polymtl.ca> wrote: > so that it's possible to determine where each tracepoint is used (and > supporting tracepoints being called at multiple locations). I made a > prototype of gdb that reads the content of this section,

Re: [lttng-dev] Printing bit fields with LTTng

On 10 June 2015 at 17:28, Simon Marchi simon.mar...@polymtl.ca wrote: On 10 June 2015 at 17:16, Chidhu R chid1...@gmail.com wrote: Hello, I am getting compilation issues while trying to print bit field values with LTTng. Error: hello.c: In function ‘main’: hello.c:36:1: error: ‘typeof

Re: [lttng-dev] Printing bit fields with LTTng

On 10 June 2015 at 17:16, Chidhu R chid1...@gmail.com wrote: Hello, I am getting compilation issues while trying to print bit field values with LTTng. Error: hello.c: In function ‘main’: hello.c:36:1: error: ‘typeof’ applied to a bit-field hello.c:36:1: error: ‘typeof’ applied to a

Re: [lttng-dev] No kernel tracer available

Hello, I'm a student at Polytechnique Montreal and we are trying to use lttng on ubuntu(Ubuntu 14.04.2 LTS) but always encounter the same problem : Error: Unable to list kernel events: Kernel tracer not available This happens even though we are root using the command line : sudo su We

Re: [lttng-dev] (no subject)

Ah, this is because we need to add abi-debian-version.sh to the Ubuntu package. I don't have time to do it right away, but perhaps Alexandre (in CC) does :). On 14 May 2015 at 15:33, Francis Rivest francis.rives...@gmail.com wrote: Hello again, We tried to install the lttng-modules-dkms

Re: [lttng-dev] [PATCH] Provide tcsh completion

On 24 April 2015 at 10:14, Marc Khouzam marc.khou...@gmail.com wrote: The new script 'lttng-tcsh_completion' is provided to allow command-completion for the tcsh shell. The approach taken by this script is to to re-use the advanced bash completion script and use its result for tcsh

Re: [lttng-dev] Crash on 3.19.3 kernel

On 23 April 2015 at 18:33, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: It should be fixed now, can you confirm ? Thanks, Mathieu After a quick test, it's certainly better than it was. Thanks! Simon ___ lttng-dev mailing list

Re: [lttng-dev] Crash on 3.19.3 kernel

On 16 April 2015 at 14:26, Sébastien Lorrain sebastien.lorrai...@gmail.com wrote: Hello LTTng folks, I'am using Archlinux with stock 3.19.3 kernel and I'am experiencing a crash with the latest and greatest lttng. I compiled lttng-tools without UST support. $uname -a Linux redwind

[lttng-dev] [PATCH] Update regmap instrumentation for Linux 3.19.4 and 4.0

This is necessary after commit c6b570d97c0e77f570bb6b2ed30d372b2b1e9aae in the kernel. Signed-off-by: Simon Marchi simon.mar...@polymtl.ca --- instrumentation/events/lttng-module/regmap.h | 123 +-- 1 file changed, 116 insertions(+), 7 deletions(-) diff --git

[lttng-dev] [PATCH lttng-tools] Fix python bindings' Makefile for out-of-tree builds

Signed-off-by: Simon Marchi simon.mar...@polymtl.ca --- extras/bindings/swig/python/Makefile.am | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/extras/bindings/swig/python/Makefile.am b/extras/bindings/swig/python/Makefile.am index ec35930..3b71171 100644 --- a/extras

Re: [lttng-dev] Addition of the return address to liblttng-ust-libc-wrapper

On 16 January 2015 at 15:13, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: From: Olivier Delbeke olivier.delb...@awtce.be To: lttng-dev@lists.lttng.org Sent: Tuesday, January 13, 2015 10:50:38 AM Subject: [lttng-dev] Addition of the return address

Re: [lttng-dev] c/c++ wrappers for lttng commands

On 14 January 2015 at 14:02, Anand Neeli anand.ne...@gmail.com wrote: Hi All, Is there any code (or did anyone implement) c/c++ wrappers API's to create,delete, add event to lttng session. The conventional way to create, add event, delete lttng sessions is through lttng shell commands, i'm

Re: [lttng-dev] Bug in LTTng-UST

Actually, I think the problem comes from UST not handling when a program dlcloses a lib. There is a simpler way to show the problem. Just have an app dlopen a .so that has a tracepoint and dlclose it. When the app quits, UST will try to unregister the tracepoint and read/write in the memory

Re: [lttng-dev] Bug in LTTng-UST

On 12 December 2014 at 23:59, Philippe Proulx eeppelitel...@gmail.com wrote: On Fri, Dec 12, 2014 at 11:21 PM, Simon Marchi simon.mar...@polymtl.ca wrote: Actually, I think the problem comes from UST not handling when a program dlcloses a lib. There is a simpler way to show the problem. Just

[lttng-dev] [PATCH lttng-modules] Update compaction instrumentation for 3.14.x stable kernels

Conditional compilation introduced by lttng-modules commit 0007344741ef65259bc52dea72259173dfbf96c0 needs to be applied to kernels 3.14.25 and up in the 3.14.x branch. Signed-off-by: Simon Marchi simon.mar...@polymtl.ca Reported-by: Bjørn Forsman bjorn.fors...@gmail.com --- instrumentation

Re: [lttng-dev] lttng-modules not building against latest linux 3.14.x

Hi Bjørn, On 7 December 2014 at 08:38, Bjørn Forsman bjorn.fors...@gmail.com wrote: Hi list, (I'm not subscribed, please CC me.) I'm a maintainer of lttng-modules in NixOS[1]. Since the update from Linux 3.14.24 to 3.14.25, lttng-modules fail to build:

Re: [lttng-dev] [RELEASE] LTTng-Tools 2.6.0-rc1 - Gaia

Note that there are now new lines for parsing efficiency. You can find the XML I think you meant there are _no_ new lines! With the typo, it means the exact opposite. :) A small tip for those who are going to work with the MI, use xmllint to format the output nicely when you want to read it

Re: [lttng-dev] [PATCH lttng-ust] Rename public structure to avoid collisions

On 13 August 2014 19:10, Simon Marchi simon.mar...@ericsson.com wrote: From: Simon Marchi simon.mar...@polymtl.ca Since nobody raised any concern about this, I submit the patch for merging. You can find the original discussion here: http://lists.lttng.org/pipermail/lttng-dev/2014-July

[lttng-dev] [PATCH lttng-tools] Fix out-of-tree build

Signed-off-by: Simon Marchi simon.mar...@polymtl.ca --- tests/regression/tools/mi/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/regression/tools/mi/Makefile.am b/tests/regression/tools/mi/Makefile.am index 4c77f56..c4081db 100644 --- a/tests/regression

Re: [lttng-dev] [PATCH lttng-tools] Load modules through kmod

On 3 September 2014 15:10, David Goulet dgou...@efficios.com wrote: On 26 Aug (16:27:46), Umut Tezduyar Lindskog wrote: Instead of forking processes, load modules through libkmod. This adds a package dependency to kmod but can be disabled by --disable-kmod option in ./configure. First,

[lttng-dev] [PATCH lttng-ust] Rename public structure to avoid collisions

From: Simon Marchi simon.mar...@polymtl.ca Since nobody raised any concern about this, I submit the patch for merging. You can find the original discussion here: http://lists.lttng.org/pipermail/lttng-dev/2014-July/023364.html (the rest of the message is identical to the RFC post) When

Re: [lttng-dev] [PATCH lttng-tool] Mi save/load: add option to indent or not on config writer creation

On 6 August 2014 10:13, Jonathan Rajotte Julien jonathan.r.jul...@gmail.com wrote: The presence of tabulation and newline in mi is irrelevant and can impact client performance. The parsing processing of a lot of data from mi with many /t and /n impact performance. This aim to fix the problem

  1   2   >