zmalloc: attribute always_inline

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Add --no-as-needed to the demo example's Makefile

Some distributions now ship with the --as-needed linker flag
set by default (Ubuntu 13.04). This will cause the linker to
remove the references to lttng-ust from the provider objects
thus causing the application to fail when preloading them.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: segfault when print invalid command

Fixes #556

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
lttng-gen-tp: Fix include guard name with file using non valid characters

Now, the include guard will be generated with all the non
alpha-numeric characters replace with an '_'

Fixes #511

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add mising include in ust.h

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Check C++ designated initializers support before compiling 'hello.cxx' test

Tested on a Ububtu system with g++ 4.6, g++ 4.7 and clang++.

Fixes #557

Signed-off-by: Zifei Tong <soariez@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Clarify probe registration documentation/errors

Fixes #513

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Remove unused assert.h from bitfield.h

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Tracepoint.h: replace assertion by fprintf and abort()

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
doc/examples: support BSD make

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
doc/examples: build gen-tp example by default

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
tests/hello.cxx: rename tp.cpp into tp-cpp.cpp

Takes care of autotools issue caused by renaming tp.c to tp.cpp. make
distclean was required when switching between old and newer versions.
It's not needed anymore.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Allow #include in template (.tp) file

The #include directive won't be parsed, but will be copied to the
generated .h files.

Also add a verbose (-v) mode to display some debugging output

Signed-off-by: Yannick Brosseau <yannick.brosseau@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: lttng-events VPATH build

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cleanup: ring buffer: remove lib_ring_buffer_switch_new_end()

lib_ring_buffer_switch_new_end() is a leftover from the days where an
event that would exactly fill the current sub-buffer would automatically
trigger a sub-buffer switch into the next sub-buffer.

Even before the ring buffer code has been moved into lttng-modules, this
behavior had been changed: an event that exactly fills a sub-buffer only
fills this current sub-buffer, and does not need to switch into the
next one to populate the sub-buffer header. This change had been done so
periodical timer switch, which shares the same semantic as an event
exactly filling a sub-buffer, would not create tons of empty
sub-buffers.

However, when doing this change, lib_ring_buffer_switch_new_end() has
not been removed, but clearly should have been. Its job is now performed
by the event "commit".

lib_ring_buffer_switch_new_end() has no effect, since padding_size is
always 0.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: handle writes of length 0

lib_ring_buffer_write() could be passed a length of 0. This typically
has no side-effect as far as writing into the buffers is concerned,
except for one detail: in overwrite mode, there is a check to make sure
the sub-buffer can be written into. This check is performed even if
length is 0. In the case where this would fall exactly at the end of a
sub-buffer, the check would fail, because the offset would fall exactly
at the beginning of the next sub-buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Revert "Cleanup: ring buffer: remove lib_ring_buffer_switch_new_end()"

This reverts commit 019fbcb65ec7eec2c86019ad1afce8fa47dc1269.

Breaks regression tests of lttng-tools.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: doc/examples: gen-tp path

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cleanup: lib_ring_buffer_switch_new_end() only calls subbuffer_set_data_size()

lib_ring_buffer_switch_new_end() is always called when an event exactly
fills a sub-buffer, which makes padding_size always 0. However, there is
one side-effect that lib_ring_buffer_switch_new_end() needs to have: it
calls subbuffer_set_data_size() to update the size of the data to be
read from the sub-buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: ring buffer: handle concurrent update in nested buffer wrap around check

With stress-test loads that trigger sub-buffer switch very frequently
(small 4kB sub-buffers, frequent flush) in lttng-modules, we currently
observe this kind of warnings once every few minutes:

[65335.896208] ring buffer relay-overwrite-mmap, cpu 5: records were lost. Caused by:
[65335.896208]   [ 0 buffer full, 1 nest buffer wrap-around, 0 event too big ]

It appears that the check for nested buffer wrap-around does not take
into account that a concurrent execution contexts (either nested for
per-cpu buffers, or from another CPU or nested for global buffers) can
update the commit_count value concurrently.

What we really want to do with this check is to ensure that if we enter
a sub-buffer that had an unbalanced reserve/commit count, assuming there
is no hope that this gets rebalanced promptly, we detect this and drop
the current event. However, in the case where the commit counter has
been concurrently updated by another reserve or a switch, we want to
retry the entire reserve operation.

One way to detect this is to sample the reserve offset twice, around the
commit counter read, along with the appropriate memory barriers.
Therefore, we can detect if the mismatch between reserve and commit
counter is actually caused by a concurrent update, which necessarily has
updated the reserve counter.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>