On Wed, Oct 4, 2023, at 3:04 PM, Kienan Stewart wrote: > Hi Chris, > > On 2023-10-04 12:56, Christopher Harvey via lttng-dev wrote: >> Hi all, >> >> I'm just getting started with lttng and have a couple of questions. My >> target is getting userspace tracepoints to work in a c++ application I >> control. I don't need kernel or system tracing. The target is running in a >> docker container I have control over as well. Running with --privileged is >> possible in my setup. I could run lttng inside the target container, outside >> on the host, or in another container on the same host. It's all the same to >> me. I don't know which setup is best, or if it even matters given that I >> don't need system or kernel traces. >> >> I am using: >> lttng-tools-2.13.11/ and lttng-ust-2.13.6/ >> with userspace-rcu-0.14.0/ >> >> There is a slight version mismatch there, I just downloaded the "-lastest" >> from the links in the guide. >> >> Here is my tracepoint provider header: >> ----- [SNIP] >> -------- >> >> and the cpp: >> ------- [SNIP] >> ---- >> >> I'm suspicious of a couple of things in my setup. >> >> First, if I omit the DEFINE_LTTNG_UST_SIGBUS_STATE(); line, my program fails >> to compile with the following error: >> liblttng-ust-ctl.so: undefined reference to `lttng_ust_sigbus_state' >> > > I wasn't able to reproduce the compilation error you are seeing. Could > you describe in more detail how you are compiling and linking your > tracepoint provider and application?
I just create a .o from the tracepoint provider compilation unit. I'm not making shared libraries or anything like that. More on this below. >> The getting started guide doesn't say anything about needing >> DEFINE_LTTNG_UST_SIGBUS_STATE so it makes me wonder if I have done something >> else wrong somewhere else. I ran a find *.so | xargs nm -D | grep >> lttng_ust_sigbus_state and nothing in lttng-ust provides that symbol, so it >> looks like the target application has to define it. Is that normal? >> > > If the application is actually using liblttng-ust-ctl, then it would be > normal to do the define. The header file explains that this is done to > avoid unnecessarily pre-allocating space in the thread-local storage. > https://github.com/lttng/lttng-ust/blob/master/include/lttng/ust-sigbus.h#L39 > > Traced applications typically don't link against liblttng-ust-ctl. > This ended up being one of the main problems. My final linking flags are -llttng-ust -llttng-ust-common -llttng-ust-tracepoint I didn't have a particular reason for linking against liblttng-ust-ctl before. It was a mistake. >> If I leave DEFINE_LTTNG_UST_SIGBUS_STATE in then my program compiles. If I >> run lttng-sessiond in the target container, then run lttng list --userspace >> I see no tracepoints in the list. >> > > Is your application actively running while you run `lttng list --userspace`? yes I was reading some lttng-sessiond source code and discovered -vvv as well as LTTNG_UST_DEBUG. I'm still not seeing the tracepoints show up in lttng list --userspace, but I found more hints as to why. Here is some output from my target application: liblttng_ust[454/467]: Info: sessiond not accepting connections to local apps socket (in ust_listener_thread() at lttng-ust-comm.c:1884) liblttng_ust[454/467]: Waiting for local apps sessiond (in wait_for_sessiond() at lttng-ust-comm.c:1758 These prints only happen periodically when lttng-sessiond is running. If I stop lttng-sessiond then the prints stop so there is clearly some communication happening. Apparently this gets printed when there is an ECONNREFUSED from lttng-sessiond. I haven't gotten much further than that right now. I have pasted the output from sessiond -vvv here: https://pastebin.com/raw/ayJJ2J9p thank you for your time, Chris _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
