[lttng-dev] Known working version of libust for the latest bundle ?
Hello, Is there a version of libust that is known to build/work with the latest lttng 2.x bundle available at http://lttng.org/files/bundles/20110930/ ? The latest libust from Git does not build against the liburcu from the bundle, I've tried to bump liburcu to a more recent version, but ran into different build problems (I can report in detail those problems if you are interested). By the way, will there be more "bundles" published in the future? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Known working version of libust for the latest bundle ?
Hello Yannick, Le Mon, 12 Dec 2011 08:57:39 -0500, Yannick Brosseau a écrit : > We plan to release a new bundle somewhere this week if everything go > well. Thanks. Will this new bundle version include libust? (The latest available version of the bundle does not contain libust). > For now, if you use the git HEAD for all the component, you shall get > something that work with UST. > (Be sure to use the "lttng-ust" git and not the "ust" one) Ok, thanks. I'll try this. I think when I tried recent version of libust against a recent version of libucru, I had undefined symbols of rcu_deference_bp() or something like that. But I'll try again and report back. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [lttng-modules PATCH] makefile: check kernel version and config token
Le Wed, 21 Dec 2011 14:30:23 +0100, Gerlando Falauto a écrit : > b) When configuration token CONFIG_TRACEPOINTS is not enabled, >display a warning I definitely agree with this. At the moment, lttng-modules silently builds nothing if CONFIG_TRACEPOINTS is not enabled. Moreover, since CONFIG_TRACEPOINTS is an hidden kconfig option, it'd be great to document which visible kconfig options should be selected to get lttng running. So far, I'm enabling things like the "kernel function tracer" which has the effect of selecting CONFIG_TRACEPOINTS, but I'm not sure if it's the minimal set of options required to get lttng working. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH] Define _GNU_SOURCE to access CPU_ZERO() macro in uClibc
Signed-off-by: Thomas Petazzoni --- tests/urcutorture.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tests/urcutorture.c b/tests/urcutorture.c index 5e9b059..35096a6 100644 --- a/tests/urcutorture.c +++ b/tests/urcutorture.c @@ -1,3 +1,4 @@ +#define _GNU_SOURCE #include #include #include -- 1.7.4.1 ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Port to Android Linux
Hello, Le Mon, 20 Feb 2012 14:54:12 -0500, Anson Ho a écrit : > Did anyone successfully port LTTng to Android Linux? > > I tried couple methods but there is no luck. For example, I tried to > put the ust and urcu and Android's external folder with a customized > Android.mk. I also tried to cross compile it independently. > However, both methods failed due to lack of some glibc features, such > as *splice*. > > If any one can give me an hint on how to port LTTng to Android, that > would be helpful. Thanks. Interestingly, last week, Karim Yaghmour has given a presentation titled "Leveraging Android's Linux heritage" at the Android Builders Summit. One of his demonstration was LTT running on Android (Karim is one of the initial developer of the original Linux Trace Toolkit, not the -ng one). See slide 28 at http://www.slideshare.net/opersys/leveraging-androids-linux-heritage. It doesn't give a lot of information, only announces a demonstration, but since I attended the talk, I can confirm that the demonstration was working. Basically, you have several choices : * Extend the bionic C library used in Android so that it supports all the C library functions used by lttng * Modify lttng so that it uses only C library functions that are provided by the bionic C library * Integrate the glibc C library to your Android system, it can perfectly live next to the bionic C library in the same system. This is the approach used by Karim. You can also look at Karim's new initiative called Cyborgstack, it provides a mechanism to integrate glibc in an Android system. See http://www.cyborgstack.org/. It is probably the easiest solution, and opens the door to integrating other open-source components that do not work with bionic. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] LTTng support in Buildroot
Hello, Just a quick e-mail to tell the LTTng developers and users that I have added support for LTTng in the Buildroot embedded Linux build system (http://buildroot.org). Buildroot can generate a cross-compilation toolchain, a kernel image and a root filesystem with various user-space applications and libraries, for a wide variety of hardware architectures. I have created packages for liburcu, lttng-modules, lttng-libust, lttng-tools and lttng-babeltrace. All packages are built for the target, except babeltrace which by default is compiled for the host, since this is where we expect the user to do the analysis of the traces (but it is also possible to build babeltrace for the target). All those packages will be available in the 2012.02 version of Buildroot which will be released later today, and are anyway already available in 2012.02-rc3 or through the Git repository of Buildroot. For the moment, the package versions correspond to the 2011-12-14 bundle, but I intend to upgrade everything to LTTng 2.0 once it is released at the end of March. If any LTTng user on the list needs help in getting this integration of LTTng in Buildroot working, do not hesitate to ask. Best regards, Thomas Petazzoni -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH] Expose kernel tracer to user-space (version 7)
Hello, Le Tue, 3 Jul 2012 15:29:12 +0200, Francis Giraldeau a écrit : > By writing to the file /proc/lttng_uevent, a user-space application creates a > kernel event. The event's payload is by default UTF-8 text, but any data can > be > written. The maximum size of the data is at most the size of a packet defined > for the trace session. Null-character is optional and is not enforced. The > event uses sequence for space efficiency and to store any data as payload. Shouldn't this be in the debugfs filesystem rather than the proc filesystem? The debugfs filesystem already has entries for various tracing facilities of the Linux kernel, and adding entries in /proc that are not process-related is frowned upon these days. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH 1/2] Do not call posix_fallocate() on uClibc
uClibc does not implement posix_fallocate(), and posix_fallocate() is
mostly only an hint to the kernel that we will need such or such
amount of space inside a file. So we just don't call posix_fallocate()
when building against uClibc.
Signed-off-by: Thomas Petazzoni
---
formats/ctf/ctf.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/formats/ctf/ctf.c b/formats/ctf/ctf.c
index bb94e52..77aef28 100644
--- a/formats/ctf/ctf.c
+++ b/formats/ctf/ctf.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -723,9 +724,11 @@ void ctf_packet_seek(struct bt_stream_pos *stream_pos,
size_t index, int whence)
}
pos->content_size = -1U;/* Unknown at this point */
pos->packet_size = WRITE_PACKET_LEN;
+#ifndef __UCLIBC__
off = posix_fallocate(pos->fd, pos->mmap_offset,
pos->packet_size / CHAR_BIT);
assert(off >= 0);
+#endif
pos->offset = 0;
} else {
read_next_packet:
--
1.7.9.5
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH 2/2] Support old compilers
Some old compilers do not use C99 as their default C language variant, for example gcc 4.3.x, which is used on some old machines. When such a compiler is used, by default, ULLONG_MAX is not visible. Adding -std=gnu99 is needed to make this definition visible. In autoconf speak, this translates into the need of using AC_PROC_CC_STDC instead of AC_PROG_CC. See http://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/C-Compiler.html for more details. Signed-off-by: Thomas Petazzoni --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 83822d6..3ddcb7c 100644 --- a/configure.ac +++ b/configure.ac @@ -17,7 +17,7 @@ AC_CONFIG_HEADERS([config.h]) AC_SYS_LARGEFILE # Checks for programs. -AC_PROG_CC +AC_PROG_CC_STDC AC_PROG_MAKE_SET LT_INIT AC_PROG_YACC -- 1.7.9.5 ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [LTTNG][LTTng-ust] "Out of system" building patches.
Dear Jimmy Durand, On Sat, 24 Aug 2013 17:34:16 +0200, Jimmy Durand wrote: > > What feature is this patchset adding that is not covered by the usual > > approach ? Or what is it fixing ? > > > Actually, this is enough for a regular system build, but if you wish to > build > it in another directory with --prefix=, which is the case for cross- > compiling, this not enough. When I hear someone say that --prefix=... is needed for cross-compilation, it's usually an indication that the cross-compilation is done incorrectly. --prefix indicates the location where the software will be *executed* on the target. So even when you're cross-compiling, the default of --prefix=/usr or --prefix=/usr/local is fine. All what you need to do is pass DESTDIR=/your/temporary/location/on/your/build/machine when doing make install. Buildroot (http://buildroot.org), which some of your colleagues at OpenWide are using, does cross-compile LTTng without such changes to LTTng build system. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [LTTNG][LTTng-ust] "Out of system" building patches.
Dear Jimmy Durand Wesolowski,
On Mon, 26 Aug 2013 09:43:49 +0200, Jimmy Durand Wesolowski wrote:
> Here is a quick test, without any of my modifications. I had to pass both
> CFLAGS and LDFLAGS to "./configure", as said earlier, which can be
> considered
> a normal process:
> CFLAGS="-I/include" \
> CPPFLAGS="-I/include" \
> LDFLAGS="-L/lib" \
> ./configure --prefix=${PWD}/build
As said previously, if you're cross-compiling, doing
--prefix=${PWD}/build is completely wrong. --prefix is the directory
where the software will be located when executed on the target, not the
location where the software will be installed when doing 'make install'.
Please document yourself on the difference between --prefix at
configure time and DESTDIR at install time.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH liburcu 2/5] Dont link pthread on Android
Dear Charles Briere, On Wed, 27 Nov 2013 07:48:30 -0800, Charles Briere wrote: > #Add the -version-info directly here since we are only building > # library that use the version-info > -AM_LDFLAGS=-lpthread -version-info $(URCU_LIBRARY_VERSION) > +AM_LDFLAGS=-version-info $(URCU_LIBRARY_VERSION) > +if !TARGET_IS_ANDROID > +AM_LDFLAGS += -lpthread > +endif Instead of making that conditional on Android, wouldn't it make more sense to make it conditional on whether linking with pthread is necessary or not? I can at least think of one other C library than Bionic that has everything in libc instead of things split in several libraries: the Musl C library (http://www.musl-libc.org). Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] lttng-tools 2.9.0 build failures
Hello, In the Buildroot project, we recently updated to lttng-tools 2.9.0, and we're experiencing two build failures: * With a uClibc based toolchain: prog.c:24:15: error: 'LM_ID_BASE' undeclared (first use in this function) h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY); I believe dlmopen() is not implemented in uClibc and musl, so perhaps this should be handled in lttng-tools by making the code conditional. See http://autobuild.buildroot.net/results/d87/d8745ef5c8c7d71f993edf2a8f3f107d2d1b35fc/build-end.log for the full build log. * With a musl based toolchain: In file included from health.c:26:0: ../../../src/common/defaults.h:370:1: error: unknown type name 'pthread_attr_t' pthread_attr_t *default_pthread_attr(void); See http://autobuild.buildroot.net/results/255/2556b3266b913964bea25c21d014f4b1b25b6808/build-end.log for the full build log. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ 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] Fix: Add missing pthread.h include
Hello, On Mon, 5 Dec 2016 15:39:26 -0500, Michael Jeanson wrote: > Some libc like musl and uClibc requires explicit includes of pthread.h > > Signed-off-by: Michael Jeanson Tested-by: Thomas Petazzoni This is indeed needed to fix the build on musl, I've integrated your patch in Buildroot for the time being. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [RFC PATCH lttng-ust 2/2] dl instrumentation: add dlmopen event, trace dlopen flags
Hello, On Mon, 4 Jul 2016 18:53:48 -0400, Mathieu Desnoyers wrote: > Add missing dlmopen(3) instrumentation, and add the "flags" field to > dlopen instrumentation. > > Link: http://man7.org/linux/man-pages/man3/dlopen.3.html > Signed-off-by: Mathieu Desnoyers FYI, this commit (7b0fdd83c137bea1d7302df1a45252dfdccd8172) breaks the build with the musl C library, because it doesn't implement the dlmopen() extension. Perhaps there should be an autoconf test to check if the C library provides dlmopen() functionality or not? Best regards, Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [RFC PATCH lttng-ust 2/2] dl instrumentation: add dlmopen event, trace dlopen flags
Hello, On Tue, 21 Feb 2017 14:08:08 + (UTC), Mathieu Desnoyers wrote: > My expectation is that the dlmopen override symbol gets generated, > but it is never invoked in builds where the libc does not implement > it, so we never have to look it up dynamically through dlsym(). The main issue is that the Lmid_t type doesn't exist I believe. > How does the build fail with musl ? Can you provide the build > output ? Sure: http://autobuild.buildroot.net/results/113/113fa95a054df183014b43ec36b329f9c59bd356/build-end.log If you want to reproduce: $ git clone git://git.busybox.net/buildroot $ cd buildroot/ $ git checkout 2017.02-rc2 $ cat > .config BR2_arm=y BR2_cortex_a9=y BR2_ARM_ENABLE_VFP=y BR2_TOOLCHAIN_EXTERNAL=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-cortex-a9-musl-2017.02-rc1-2-g133c5ac.tar.bz2"; BR2_TOOLCHAIN_EXTERNAL_GCC_5=y BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_9=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM_MUSL=y BR2_TOOLCHAIN_EXTERNAL_CXX=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_LTTNG_LIBUST=y # BR2_TARGET_ROOTFS_TAR is not set $ make olddefconfig $ make Takes ~5 minutes maybe for the all build to proceed until it breaks on lttng-ust. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] lttng-tools build failure with uClibc due to dlmopen()
Hello, First of all, thanks for having fixed the dlmopen issue with musl in lttng-ust. Now, there is another dlmopen issue, this time in lttng-tools, and this time with uClibc: CC prog.o prog.c: In function 'main': prog.c:24:7: warning: implicit declaration of function 'dlmopen' [-Wimplicit-function-declaration] h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY); ^ prog.c:24:15: error: 'LM_ID_BASE' undeclared (first use in this function) h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY); ^ prog.c:24:15: note: each undeclared identifier is reported only once for each function it appears in See http://autobuild.buildroot.net/results/c07/c07b5bac6146d83c3224de147da3798d3e7b527f/build-end.log for the full build log. So, the ust regression test case in lttng-tools doesn't test if dlmopen() is provided by the C library before using it. I guess some additional autoconf/automake conditional is needed here. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] lttng-tools build failure with uClibc due to dlmopen()
Hello, On Wed, 1 Mar 2017 00:09:45 +0100, Thomas Petazzoni wrote: > First of all, thanks for having fixed the dlmopen issue with musl in > lttng-ust. Now, there is another dlmopen issue, this time in > lttng-tools, and this time with uClibc: > > CC prog.o > prog.c: In function 'main': > prog.c:24:7: warning: implicit declaration of function 'dlmopen' > [-Wimplicit-function-declaration] > h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY); >^ > prog.c:24:15: error: 'LM_ID_BASE' undeclared (first use in this function) > h1 = dlmopen(LM_ID_BASE, "libfoo.so", RTLD_LAZY); >^ > prog.c:24:15: note: each undeclared identifier is reported only once for each > function it appears in > > See > http://autobuild.buildroot.net/results/c07/c07b5bac6146d83c3224de147da3798d3e7b527f/build-end.log > for the full build log. > > So, the ust regression test case in lttng-tools doesn't test if > dlmopen() is provided by the C library before using it. Any feedback on this issue? We're still seeing it in Buildroot when building lttng-tools against uClibc. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] lttng-tools build failure with uClibc due to dlmopen()
Hello, Thanks for your feedback! On Fri, 5 May 2017 15:42:52 -0400, Jérémie Galarneau wrote: > This patch is available: > https://github.com/alpinelinux/aports/blob/master/testing/lttng-tools/musl-has-no-dlmopen.patch > > However, I won't merge it as-is since it disables all dlmopen tests > outright. I'd rather disable them only when it is not available. Since AlpineLinux is using musl only, they often use solutions that work fine for musl, but are not necessarily applicable in a more general way. Buildroot provides support for glibc, uclibc and musl, so AlpineLinux's solution is not suitable as-is. For now, we have simply disabled lttng-tools for uclibc and musl toolchains in Buildroot. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
