Re: [lttng-dev] Error: Unable to list kernel events: Kernel tracer not available
Thanks for response. Please check console logs here: https://paste.debian.net/1054148 Thanks in advance for further support. Szymon sob., 1 gru 2018 o 01:05 Jonathan Rajotte-Julien < jonathan.rajotte-jul...@efficios.com> napisał(a): > Hi Szymon, > > First thing to validate is if the modules compilation worked. > > Please give us the output of the following command: > >ls -la /lib/modules/`uname -r`/extra > > Since you installed lttng-tools via the package repo, a service was > installed > to spawn lttng-sessiond. > > You can control the service using systemctl: > >sudo systemctl stop lttng-sessiond.service >sudo systemctl start lttng-sessiond.service >sudo systemctl restart lttng-sessiond.service > > The output you gave us indicate that a sessiond is already running (the one > started by the systemd service). Which is of no use. > > A colleague suggested that since you might have installed the modules > package > after the lttng-tools package, the modules were not present when > lttng-sessiond > service was started thus could not have been loaded. > > To test this hypothesis you can issue the following command followed by > your > test. > >sudo systemctl restart lttng-sessiond.service >sleep 1 >sudo lttng list -k > > If it doesn't work, stop the service and start a sessiond in verbose mode > manually. > >sudo systemctl stop lttng-sessiond.service >sudo lttng-sessiond -vvv --verbose-consumer > > This should give us more information. > > You can use a service like https://paste.debian.net/ to give us any of the > output if it ends up being more than ~20 lines. > > Thanks for using the mailing list instead of Stack Overflow. Once we find > the > problem we can update you SO thread with the solution. > > Cheers > > On Sat, Dec 01, 2018 at 12:22:05AM +0100, Szymon Rąpała wrote: > > Hello, > > > > I'm new to lttng so I tried to follow the 'Quick Start' tutorial from > > lttng.org. > > > > I have installed LTTng Stable 2.10 PPA (lttng-tools, lttng-modules-dkms, > > liblttng-ust-dev). At very beginning I am facing a problem with kernel > > tracking: > > > > ~/lttng_train$ sudo lttng create my > > Session my created. > > Traces will be written in /home/szymon/lttng-traces/my-20181130-222008 > > ~/lttng_train$ sudo lttng list --kernel > > Error: Unable to list kernel events: Kernel tracer not available > > Error: Command error > > > > Any ideas? Thanks for support! > > > > Additional info: > > > > ~/lttng_train$ dpkg -l | grep lttng > > ii liblttng-ctl0:amd64 > > 2.10.5-1~ubuntu16.04.1 amd64LTTng > > control and utility library > > ii liblttng-ust-ctl4:amd64 > > 2.10.2-1~ubuntu16.04.1 amd64LTTng 2.0 > > Userspace Tracer (trace control library) > > ii liblttng-ust-dev:amd64 > > 2.10.2-1~ubuntu16.04.1 amd64LTTng 2.0 > > Userspace Tracer (development files) > > ii liblttng-ust-python-agent0:amd64 > > 2.10.2-1~ubuntu16.04.1 amd64LTTng 2.0 > > Userspace Tracer (Python agent native library) > > ii liblttng-ust0:amd64 > > 2.10.2-1~ubuntu16.04.1 amd64LTTng 2.0 > > Userspace Tracer (tracing libraries) > > ii lttng-modules-dkms > > 2.10.8-1~ubuntu16.04.1 all Linux Trace > > Toolkit (LTTng) kernel modules (DKMS) > > ii lttng-tools > > 2.10.5-1~ubuntu16.04.1 amd64LTTng > > control and utility programs > > > > ~$ uname -a > > Linux szymon 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC > > 2017 x86_64 x86_64 x86_64 GNU/Linux > > > > ~$ lsb_release -a > > No LSB modules are available. > > Distributor ID: Ubuntu > > Description:Ubuntu 16.04.5 LTS > > Release:16.04 > > Codename: xenial > > > > ~/lttng_train$ ps aux | grep lttng-sessiond > > root 7862 0.0 0.3 859960 10880 ?Ssl 19:12 0:00 > > /usr/bin/lttng-sessiond > > szymon 14853 0.0 0.0 15440 936 pts/1S+ 22:21 0:00 grep > > --color=auto lttng-sessiond > > > > ~/lttng_train$ lsmod | grep lttng > > ~/ > > > > ~/lttng_train$ sudo lttng-sessiond -vvv > > DEBUG1 - 00:16:41.328643679 [16578/16578]: [sessiond configuration] > > DEBUG1 - 00:16:41.328715142 [16578/16578]:verbose: > 3 > > DEBUG1 - 00:16:41.328723618 [16578/16578]:verbose consumer: > 0 > > DEBUG1 - 00:16:41.328729230 [16578/16578]:quiet mode: > False > > DEBUG1 - 00:16:41.328735428 [16578/16578]:agent_tcp_port: > > [5345, 5354] > > DEBUG1 - 00:16:41.328741084 [16578/16578]:application socket > timeout:5 > > DEBUG1 - 00:16:41.328761096 [16578/16578]:no-kernel: > False > > DEBUG1 - 00:16:41.328776829 [16578/16578]:background: > False > > DEBUG1 - 00:16:41.328788328 [16578/16578]:daemonize: > False > > DEBUG1 - 00:16:41.328800092 [16578/16578]:signal parent on start: > False > > DEBUG1 - 00:16:41.328812153 [16578/16578]:tracing group nam
Re: [lttng-dev] Error: Unable to list kernel events: Kernel tracer not available
Hi Szymon, Based on the sessiond logs and the content of "/lib/modules/`uname -r`/extra" there was clearly a problem on lttng-modules-dkms installation. Most of the time, the culprit is the lack of memory at compile time. How much memory is installed on your system? Please reinstall the package: sudo apt-get install --reinstall lttng-modules-dkms Make sure to take a good look at the logs. Cheers On Mon, Dec 03, 2018 at 12:30:18PM +0100, Szymon Rąpała wrote: > Thanks for response. > Please check console logs here: https://paste.debian.net/1054148 > > Thanks in advance for further support. > Szymon > -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Error: Unable to list kernel events: Kernel tracer not available
Hi Jonathan, Regarding memory: ~$ free -m totalusedfree shared buff/cache available Mem: 351816011063 105 853 1524 Swap: 3655 203635 I reinstaled dkms, but still there is no kernel tracer. Full logs: https://paste.debian.net/1054193/ This part looks strange: DKMS: uninstall completed. -- Deleting module version: 2.10.8 completely from the DKMS tree. -- Done. Unpacking lttng-modules-dkms (2.10.8-1~ubuntu16.04.1) over (2.10.8-1~ubuntu16.04.1) ... Setting up lttng-modules-dkms (2.10.8-1~ubuntu16.04.1) ... Loading new lttng-modules-2.10.8 DKMS files... Building for 4.4.0-98-generic and 4.4.0-139-generic Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed. Building initial module for 4.4.0-139-generic Done. Regards, pon., 3 gru 2018 o 15:36 Jonathan Rajotte-Julien < jonathan.rajotte-jul...@efficios.com> napisał(a): > Hi Szymon, > > Based on the sessiond logs and the content of "/lib/modules/`uname > -r`/extra" there was clearly a problem on lttng-modules-dkms installation. > > Most of the time, the culprit is the lack of memory at compile time. How > much memory > is installed on your system? > > Please reinstall the package: > sudo apt-get install --reinstall lttng-modules-dkms > > Make sure to take a good look at the logs. > > Cheers > > On Mon, Dec 03, 2018 at 12:30:18PM +0100, Szymon Rąpała wrote: > > Thanks for response. > > Please check console logs here: https://paste.debian.net/1054148 > > > > Thanks in advance for further support. > > Szymon > > > > -- > Jonathan Rajotte-Julien > EfficiOS > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Error: Unable to list kernel events: Kernel tracer not available
> Done. > Unpacking lttng-modules-dkms (2.10.8-1~ubuntu16.04.1) over > (2.10.8-1~ubuntu16.04.1) ... > Setting up lttng-modules-dkms (2.10.8-1~ubuntu16.04.1) ... > Loading new lttng-modules-2.10.8 DKMS files... > Building for 4.4.0-98-generic and 4.4.0-139-generic > Module build for the currently running kernel was skipped since the > kernel source for this kernel does not seem to be installed. I would bet that you are missing the kernel header for the 4.4.0-98-generic kernel. sudo apt-get install linux-headers-4.4.0-98-generic I'm not sure if dkms triggers on header install but if I were you I would simply force a reinstall of the lttng-modules-dkms package and make sure that the modules are installed for both the 98 and 139 kernel. Cheers -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Videos of the Tracing Summit 2018
Hi, The videos of the Tracing Summit 2018 are now online: https://www.youtube.com/playlist?list=PLuo4E47p5_7aBCdobf_XpEPcDFNPhpRNs You can also access them from the schedule here: https://tracingsummit.org/wiki/TracingSummit2018#Schedule -- On behalf of the Diagnostic and Monitoring Workgroup, Francis Deslauriers ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] making liburcu and lttng coexist in a LGPL'ed program
On Wed, 2018-11-28 at 17:06 -0500, Mathieu Desnoyers wrote: > - On Nov 27, 2018, at 1:17 PM, Jeff Layton jlay...@redhat.com wrote: > > > The nfs-ganesha project has used lttng for quite some time to handle > > tracing. Recently though, we decided to start building liburcu in as a > > mandatory component, with an eye toward using it in certain areas. > > > > Before this change, the code linked in liburcu-bp directly, but now we > > just use liburcu. Unfortunately, when we enable tracepoints in the build > > now, we get errors like this at link time: > > > > 8< > > [ 96%] Linking C executable ganesha.nfsd > > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference > > to > > symbol 'rcu_gp_bp' > > /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO missing > > from > > command line > > collect2: error: ld returned 1 exit status > > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: > > MainNFSD/ganesha.nfsd] Error 1 > > make[1]: *** [CMakeFiles/Makefile2:2740: > > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 > > make: *** [Makefile:152: all] Error 2 > > 8< > > > > nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the > > redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all > > builds as expected. > > > > I found a similar bug here: > > > >https://bugs.lttng.org/issues/1156 > > > > Any thoughts on the right fix for this? We'd like to eat our cake and > > have it too, so that we can have _LGPL_SOURCE defined, lttng enabled, > > and the urcu flavor be determined at runtime. > > Hi! > > It's great to hear that feedback. Indeed you are not the first one > to hit this unfortunate limitation of liburcu API. > > The use-case involves using many liburcu flavors within the same > compile unit _with_ _LGPL_SOURCE defined. All the tricks done > in urcu/map/*.h to map all flavors to a single API conflict > with that use-case. And the fact that the "mb", memb", and > signal flavors all share the same header prevents this > even further. This becomes a real issue when trying to use > the lttng-ust tracer instrumentation (which includes urcu-bp.h) > along with other liburcu flavors in a compile unit. > > So, I took the day to hack something out: beware, it's a complete > overhaul of the liburcu tree. You can try it out in this private > development branch: > > https://github.com/compudj/userspace-rcu-dev/tree/multiflavor > > Note: don't even try to follow the git commit history at the > moment, this will need editing. ;) > > A new unit test shows how it works: > > https://github.com/compudj/userspace-rcu-dev/blob/multiflavor/tests/unit/test_urcu_multiflavor_single_unit.c > > And while I was there, I did a lot of namespacing cleanups for the > APIs, so we'll _definitely_ need to bump the major soname for this. > However, I'm keeping the main use-cases of the API backward compatible > (those which relied on the API mapping). Here is a dev branch of > lttng-ust adapting to those API changes: > > https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor > > Those who want to be able to use many liburcu flavors in a single > compile unit would need to define URCU_NO_API_MAP, and use each flavor > namespace directly, as done in the new unit test. I'm not particularly > fond of the URCU_NO_API_MAP name. We could perhaps name it "URCU_MULTI_FLAVOR" > or something else... > > Please try it out and let me know how it goes. > > Thanks, > > Mathieu > Thanks Mathieu, Sorry for the delay, but this was rather difficult to test. I ended up building a userspace-rcu package from this tree, but was unable to build lttng-ust as a package from your tree, and so had to just do a make/make install of it on the build host. Ditto for lttng-tools. With all of that, I reran the ganesha build and got the same error: [ 97%] Linking C executable ganesha.nfsd /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference to symbol 'urcu_bp_register' /usr/bin/ld: //usr/lib64/liburcu-bp.so.7: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:288: MainNFSD/ganesha.nfsd] Error 1 make[1]: *** [CMakeFiles/Makefile2:2396: MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 Should we be passing in both -lurcu and -lurcu-bp on the link here? -- Jeff Layton ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] making liburcu and lttng coexist in a LGPL'ed program
- On Dec 3, 2018, at 12:58 PM, Jeff Layton jlay...@redhat.com wrote: > On Wed, 2018-11-28 at 17:06 -0500, Mathieu Desnoyers wrote: >> - On Nov 27, 2018, at 1:17 PM, Jeff Layton jlay...@redhat.com wrote: >> >> > The nfs-ganesha project has used lttng for quite some time to handle >> > tracing. Recently though, we decided to start building liburcu in as a >> > mandatory component, with an eye toward using it in certain areas. >> > >> > Before this change, the code linked in liburcu-bp directly, but now we >> > just use liburcu. Unfortunately, when we enable tracepoints in the build >> > now, we get errors like this at link time: >> > >> > 8< >> > [ 96%] Linking C executable ganesha.nfsd >> > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference >> > to >> > symbol 'rcu_gp_bp' >> > /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO >> > missing from >> > command line >> > collect2: error: ld returned 1 exit status >> > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: >> > MainNFSD/ganesha.nfsd] Error 1 >> > make[1]: *** [CMakeFiles/Makefile2:2740: >> > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 >> > make: *** [Makefile:152: all] Error 2 >> > 8< >> > >> > nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the >> > redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all >> > builds as expected. >> > >> > I found a similar bug here: >> > >> >https://bugs.lttng.org/issues/1156 >> > >> > Any thoughts on the right fix for this? We'd like to eat our cake and >> > have it too, so that we can have _LGPL_SOURCE defined, lttng enabled, >> > and the urcu flavor be determined at runtime. >> >> Hi! >> >> It's great to hear that feedback. Indeed you are not the first one >> to hit this unfortunate limitation of liburcu API. >> >> The use-case involves using many liburcu flavors within the same >> compile unit _with_ _LGPL_SOURCE defined. All the tricks done >> in urcu/map/*.h to map all flavors to a single API conflict >> with that use-case. And the fact that the "mb", memb", and >> signal flavors all share the same header prevents this >> even further. This becomes a real issue when trying to use >> the lttng-ust tracer instrumentation (which includes urcu-bp.h) >> along with other liburcu flavors in a compile unit. >> >> So, I took the day to hack something out: beware, it's a complete >> overhaul of the liburcu tree. You can try it out in this private >> development branch: >> >> https://github.com/compudj/userspace-rcu-dev/tree/multiflavor >> >> Note: don't even try to follow the git commit history at the >> moment, this will need editing. ;) >> >> A new unit test shows how it works: >> >> https://github.com/compudj/userspace-rcu-dev/blob/multiflavor/tests/unit/test_urcu_multiflavor_single_unit.c >> >> And while I was there, I did a lot of namespacing cleanups for the >> APIs, so we'll _definitely_ need to bump the major soname for this. >> However, I'm keeping the main use-cases of the API backward compatible >> (those which relied on the API mapping). Here is a dev branch of >> lttng-ust adapting to those API changes: >> >> https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor >> >> Those who want to be able to use many liburcu flavors in a single >> compile unit would need to define URCU_NO_API_MAP, and use each flavor >> namespace directly, as done in the new unit test. I'm not particularly >> fond of the URCU_NO_API_MAP name. We could perhaps name it >> "URCU_MULTI_FLAVOR" >> or something else... By the way, with the updated liburcu tree, there is no more need to define URCU_NO_API_MAP. >> >> Please try it out and let me know how it goes. >> >> Thanks, >> >> Mathieu >> > > Thanks Mathieu, > > Sorry for the delay, but this was rather difficult to test. I ended up > building a userspace-rcu package from this tree, but was unable to > build lttng-ust as a package from your tree, and so had to just do a > make/make install of it on the build host. Ditto for lttng-tools. You will need lttng-ust from this tree: https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor to build against the liburcu branch. This is causing your missing symbol error. Thanks, Mathieu > > With all of that, I reran the ganesha build and got the same error: > > [ 97%] Linking C executable ganesha.nfsd > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference to > symbol 'urcu_bp_register' > /usr/bin/ld: //usr/lib64/liburcu-bp.so.7: error adding symbols: DSO missing > from > command line > collect2: error: ld returned 1 exit status > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:288: > MainNFSD/ganesha.nfsd] Error 1 > make[1]: *** [CMakeFiles/Makefile2:2396: > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 > make: *** [Makefile:152: all] Error 2 > > Should we be passing in both -lurcu and -l
Re: [lttng-dev] making liburcu and lttng coexist in a LGPL'ed program
On Mon, 2018-12-03 at 13:25 -0500, Mathieu Desnoyers wrote: > - On Dec 3, 2018, at 12:58 PM, Jeff Layton jlay...@redhat.com wrote: > > > On Wed, 2018-11-28 at 17:06 -0500, Mathieu Desnoyers wrote: > > > - On Nov 27, 2018, at 1:17 PM, Jeff Layton jlay...@redhat.com wrote: > > > > > > > The nfs-ganesha project has used lttng for quite some time to handle > > > > tracing. Recently though, we decided to start building liburcu in as a > > > > mandatory component, with an eye toward using it in certain areas. > > > > > > > > Before this change, the code linked in liburcu-bp directly, but now we > > > > just use liburcu. Unfortunately, when we enable tracepoints in the build > > > > now, we get errors like this at link time: > > > > > > > > 8< > > > > [ 96%] Linking C executable ganesha.nfsd > > > > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined > > > > reference to > > > > symbol 'rcu_gp_bp' > > > > /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO > > > > missing from > > > > command line > > > > collect2: error: ld returned 1 exit status > > > > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: > > > > MainNFSD/ganesha.nfsd] Error 1 > > > > make[1]: *** [CMakeFiles/Makefile2:2740: > > > > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 > > > > make: *** [Makefile:152: all] Error 2 > > > > 8< > > > > > > > > nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the > > > > redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all > > > > builds as expected. > > > > > > > > I found a similar bug here: > > > > > > > >https://bugs.lttng.org/issues/1156 > > > > > > > > Any thoughts on the right fix for this? We'd like to eat our cake and > > > > have it too, so that we can have _LGPL_SOURCE defined, lttng enabled, > > > > and the urcu flavor be determined at runtime. > > > > > > Hi! > > > > > > It's great to hear that feedback. Indeed you are not the first one > > > to hit this unfortunate limitation of liburcu API. > > > > > > The use-case involves using many liburcu flavors within the same > > > compile unit _with_ _LGPL_SOURCE defined. All the tricks done > > > in urcu/map/*.h to map all flavors to a single API conflict > > > with that use-case. And the fact that the "mb", memb", and > > > signal flavors all share the same header prevents this > > > even further. This becomes a real issue when trying to use > > > the lttng-ust tracer instrumentation (which includes urcu-bp.h) > > > along with other liburcu flavors in a compile unit. > > > > > > So, I took the day to hack something out: beware, it's a complete > > > overhaul of the liburcu tree. You can try it out in this private > > > development branch: > > > > > > https://github.com/compudj/userspace-rcu-dev/tree/multiflavor > > > > > > Note: don't even try to follow the git commit history at the > > > moment, this will need editing. ;) > > > > > > A new unit test shows how it works: > > > > > > https://github.com/compudj/userspace-rcu-dev/blob/multiflavor/tests/unit/test_urcu_multiflavor_single_unit.c > > > > > > And while I was there, I did a lot of namespacing cleanups for the > > > APIs, so we'll _definitely_ need to bump the major soname for this. > > > However, I'm keeping the main use-cases of the API backward compatible > > > (those which relied on the API mapping). Here is a dev branch of > > > lttng-ust adapting to those API changes: > > > > > > https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor > > > > > > Those who want to be able to use many liburcu flavors in a single > > > compile unit would need to define URCU_NO_API_MAP, and use each flavor > > > namespace directly, as done in the new unit test. I'm not particularly > > > fond of the URCU_NO_API_MAP name. We could perhaps name it > > > "URCU_MULTI_FLAVOR" > > > or something else... > > By the way, with the updated liburcu tree, there is no more need to > define URCU_NO_API_MAP. > > > > Please try it out and let me know how it goes. > > > > > > Thanks, > > > > > > Mathieu > > > > > > > Thanks Mathieu, > > > > Sorry for the delay, but this was rather difficult to test. I ended up > > building a userspace-rcu package from this tree, but was unable to > > build lttng-ust as a package from your tree, and so had to just do a > > make/make install of it on the build host. Ditto for lttng-tools. > > You will need lttng-ust from this tree: > > https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor > > to build against the liburcu branch. This is causing your missing symbol > error. > > Thanks, > > Mathieu > That's the branch I'm using [1]. I basically checked out that branch, and did: configure --prefix=/usr make make install ...and then did the same with lttng-tools (which ganesha also requires). After that, I pulled down nfs-ganesha tree, checked out the "next" branch and tried to build it
Re: [lttng-dev] making liburcu and lttng coexist in a LGPL'ed program
- On Dec 3, 2018, at 1:43 PM, Jeff Layton jlay...@redhat.com wrote: > On Mon, 2018-12-03 at 13:25 -0500, Mathieu Desnoyers wrote: >> - On Dec 3, 2018, at 12:58 PM, Jeff Layton jlay...@redhat.com wrote: >> >> > On Wed, 2018-11-28 at 17:06 -0500, Mathieu Desnoyers wrote: >> > > - On Nov 27, 2018, at 1:17 PM, Jeff Layton jlay...@redhat.com wrote: >> > > >> > > > The nfs-ganesha project has used lttng for quite some time to handle >> > > > tracing. Recently though, we decided to start building liburcu in as a >> > > > mandatory component, with an eye toward using it in certain areas. >> > > > >> > > > Before this change, the code linked in liburcu-bp directly, but now we >> > > > just use liburcu. Unfortunately, when we enable tracepoints in the >> > > > build >> > > > now, we get errors like this at link time: >> > > > >> > > > 8< >> > > > [ 96%] Linking C executable ganesha.nfsd >> > > > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined >> > > > reference to >> > > > symbol 'rcu_gp_bp' >> > > > /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO >> > > > missing from >> > > > command line >> > > > collect2: error: ld returned 1 exit status >> > > > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: >> > > > MainNFSD/ganesha.nfsd] Error 1 >> > > > make[1]: *** [CMakeFiles/Makefile2:2740: >> > > > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 >> > > > make: *** [Makefile:152: all] Error 2 >> > > > 8< >> > > > >> > > > nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the >> > > > redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all >> > > > builds as expected. >> > > > >> > > > I found a similar bug here: >> > > > >> > > >https://bugs.lttng.org/issues/1156 >> > > > >> > > > Any thoughts on the right fix for this? We'd like to eat our cake and >> > > > have it too, so that we can have _LGPL_SOURCE defined, lttng enabled, >> > > > and the urcu flavor be determined at runtime. >> > > >> > > Hi! >> > > >> > > It's great to hear that feedback. Indeed you are not the first one >> > > to hit this unfortunate limitation of liburcu API. >> > > >> > > The use-case involves using many liburcu flavors within the same >> > > compile unit _with_ _LGPL_SOURCE defined. All the tricks done >> > > in urcu/map/*.h to map all flavors to a single API conflict >> > > with that use-case. And the fact that the "mb", memb", and >> > > signal flavors all share the same header prevents this >> > > even further. This becomes a real issue when trying to use >> > > the lttng-ust tracer instrumentation (which includes urcu-bp.h) >> > > along with other liburcu flavors in a compile unit. >> > > >> > > So, I took the day to hack something out: beware, it's a complete >> > > overhaul of the liburcu tree. You can try it out in this private >> > > development branch: >> > > >> > > https://github.com/compudj/userspace-rcu-dev/tree/multiflavor >> > > >> > > Note: don't even try to follow the git commit history at the >> > > moment, this will need editing. ;) >> > > >> > > A new unit test shows how it works: >> > > >> > > https://github.com/compudj/userspace-rcu-dev/blob/multiflavor/tests/unit/test_urcu_multiflavor_single_unit.c >> > > >> > > And while I was there, I did a lot of namespacing cleanups for the >> > > APIs, so we'll _definitely_ need to bump the major soname for this. >> > > However, I'm keeping the main use-cases of the API backward compatible >> > > (those which relied on the API mapping). Here is a dev branch of >> > > lttng-ust adapting to those API changes: >> > > >> > > https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor >> > > >> > > Those who want to be able to use many liburcu flavors in a single >> > > compile unit would need to define URCU_NO_API_MAP, and use each flavor >> > > namespace directly, as done in the new unit test. I'm not particularly >> > > fond of the URCU_NO_API_MAP name. We could perhaps name it >> > > "URCU_MULTI_FLAVOR" >> > > or something else... >> >> By the way, with the updated liburcu tree, there is no more need to >> define URCU_NO_API_MAP. >> >> > > Please try it out and let me know how it goes. >> > > >> > > Thanks, >> > > >> > > Mathieu >> > > >> > >> > Thanks Mathieu, >> > >> > Sorry for the delay, but this was rather difficult to test. I ended up >> > building a userspace-rcu package from this tree, but was unable to >> > build lttng-ust as a package from your tree, and so had to just do a >> > make/make install of it on the build host. Ditto for lttng-tools. >> >> You will need lttng-ust from this tree: >> >> https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor >> >> to build against the liburcu branch. This is causing your missing symbol >> error. >> >> Thanks, >> >> Mathieu >> > > That's the branch I'm using [1]. I basically checked out that branch, > and did: > > conf
Re: [lttng-dev] making liburcu and lttng coexist in a LGPL'ed program
On Mon, 2018-12-03 at 14:13 -0500, Mathieu Desnoyers wrote: > > - On Dec 3, 2018, at 1:43 PM, Jeff Layton jlay...@redhat.com wrote: > > > On Mon, 2018-12-03 at 13:25 -0500, Mathieu Desnoyers wrote: > > > - On Dec 3, 2018, at 12:58 PM, Jeff Layton jlay...@redhat.com wrote: > > > > > > > On Wed, 2018-11-28 at 17:06 -0500, Mathieu Desnoyers wrote: > > > > > - On Nov 27, 2018, at 1:17 PM, Jeff Layton jlay...@redhat.com > > > > > wrote: > > > > > > > > > > > The nfs-ganesha project has used lttng for quite some time to handle > > > > > > tracing. Recently though, we decided to start building liburcu in > > > > > > as a > > > > > > mandatory component, with an eye toward using it in certain areas. > > > > > > > > > > > > Before this change, the code linked in liburcu-bp directly, but now > > > > > > we > > > > > > just use liburcu. Unfortunately, when we enable tracepoints in the > > > > > > build > > > > > > now, we get errors like this at link time: > > > > > > > > > > > > 8< > > > > > > [ 96%] Linking C executable ganesha.nfsd > > > > > > /usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined > > > > > > reference to > > > > > > symbol 'rcu_gp_bp' > > > > > > /usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO > > > > > > missing from > > > > > > command line > > > > > > collect2: error: ld returned 1 exit status > > > > > > make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: > > > > > > MainNFSD/ganesha.nfsd] Error 1 > > > > > > make[1]: *** [CMakeFiles/Makefile2:2740: > > > > > > MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2 > > > > > > make: *** [Makefile:152: all] Error 2 > > > > > > 8< > > > > > > > > > > > > nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the > > > > > > redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all > > > > > > builds as expected. > > > > > > > > > > > > I found a similar bug here: > > > > > > > > > > > >https://bugs.lttng.org/issues/1156 > > > > > > > > > > > > Any thoughts on the right fix for this? We'd like to eat our cake > > > > > > and > > > > > > have it too, so that we can have _LGPL_SOURCE defined, lttng > > > > > > enabled, > > > > > > and the urcu flavor be determined at runtime. > > > > > > > > > > Hi! > > > > > > > > > > It's great to hear that feedback. Indeed you are not the first one > > > > > to hit this unfortunate limitation of liburcu API. > > > > > > > > > > The use-case involves using many liburcu flavors within the same > > > > > compile unit _with_ _LGPL_SOURCE defined. All the tricks done > > > > > in urcu/map/*.h to map all flavors to a single API conflict > > > > > with that use-case. And the fact that the "mb", memb", and > > > > > signal flavors all share the same header prevents this > > > > > even further. This becomes a real issue when trying to use > > > > > the lttng-ust tracer instrumentation (which includes urcu-bp.h) > > > > > along with other liburcu flavors in a compile unit. > > > > > > > > > > So, I took the day to hack something out: beware, it's a complete > > > > > overhaul of the liburcu tree. You can try it out in this private > > > > > development branch: > > > > > > > > > > https://github.com/compudj/userspace-rcu-dev/tree/multiflavor > > > > > > > > > > Note: don't even try to follow the git commit history at the > > > > > moment, this will need editing. ;) > > > > > > > > > > A new unit test shows how it works: > > > > > > > > > > https://github.com/compudj/userspace-rcu-dev/blob/multiflavor/tests/unit/test_urcu_multiflavor_single_unit.c > > > > > > > > > > And while I was there, I did a lot of namespacing cleanups for the > > > > > APIs, so we'll _definitely_ need to bump the major soname for this. > > > > > However, I'm keeping the main use-cases of the API backward compatible > > > > > (those which relied on the API mapping). Here is a dev branch of > > > > > lttng-ust adapting to those API changes: > > > > > > > > > > https://github.com/compudj/lttng-ust-dev/tree/urcu-multiflavor > > > > > > > > > > Those who want to be able to use many liburcu flavors in a single > > > > > compile unit would need to define URCU_NO_API_MAP, and use each flavor > > > > > namespace directly, as done in the new unit test. I'm not particularly > > > > > fond of the URCU_NO_API_MAP name. We could perhaps name it > > > > > "URCU_MULTI_FLAVOR" > > > > > or something else... > > > > > > By the way, with the updated liburcu tree, there is no more need to > > > define URCU_NO_API_MAP. > > > > > > > > Please try it out and let me know how it goes. > > > > > > > > > > Thanks, > > > > > > > > > > Mathieu > > > > > > > > > > > > > Thanks Mathieu, > > > > > > > > Sorry for the delay, but this was rather difficult to test. I ended up > > > > building a userspace-rcu package from this tree, but was unable to > > > > build lttng-ust as a package from your tree, and s
