Re: [lttng-dev] I'm still getting empty ust traces using tracef

[Brian Hutchinson via lttng-dev <lttng-dev@lists.lttng.org>]

On Wed, Jun 21, 2023 at 4:21 PM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> On 6/20/23 18:02, Brian Hutchinson wrote:
> > On Thu, May 11, 2023 at 2:14 PM Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com> wrote:
> >>
> >> On 2023-05-11 14:13, Mathieu Desnoyers via lttng-dev wrote:
> >>> On 2023-05-11 12:36, Brian Hutchinson via lttng-dev wrote:
> >>>> ... more background.  I've always used ltt in the kernel so I don't
> >>>> have much experience with the user side of it and especially
> >>>> multi-threaded, multi-core so I'm probably missing some fundamental
> >>>> concepts that I need to understand.
> >>>
> >>> Which are the exact versions of LTTng-UST and LTTng-Tools you are using
> >>> now ? (2.13.N or which git commit ?)
> >>>
> >>
> >> Also, can you try using lttng-ust stable-2.13 branch, which includes the following commit ?
> >>
> >> commit be2ca8b563bab81be15cbce7b9f52422369f79f7
> >> Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> >> Date:   Tue Feb 21 14:29:49 2023 -0500
> >>
> >>       Fix: Reevaluate LTTNG_UST_TRACEPOINT_DEFINE each time tracepoint.h is included
> >>
> >>       Fix issues with missing symbols in use-cases where tracef.h is included
> >>       before defining LTTNG_UST_TRACEPOINT_DEFINE, e.g.:
> >>
> >>        #include <lttng/tracef.h>
> >>        #define LTTNG_UST_TRACEPOINT_DEFINE
> >>        #include <provider.h>
> >>
> >>       It is caused by the fact that tracef.h includes tracepoint.h in a
> >>       context which has LTTNG_UST_TRACEPOINT_DEFINE undefined, and this is not
> >>       re-evaluated for the following includes.
> >>
> >>       Fix this by lifting the definition code in tracepoint.h outside of the
> >>       header include guards, and #undef the old LTTNG_UST__DEFINE_TRACEPOINT
> >>       before re-defining it to its new semantic. Use a new
> >>       _LTTNG_UST_TRACEPOINT_DEFINE_ONCE include guard within the
> >>       LTTNG_UST_TRACEPOINT_DEFINE defined case to ensure symbols are not
> >>       duplicated.
> >>
> >>       Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> >>       Change-Id: I0ef720435003a7ca0bfcf29d7bf27866c5ff8678
> >>
> >
> > I applied this patch and if I use "tracef" type calls in our
> > application that is made up of a bunch of static libs ... the UST
> > trace calls work.  I verified that traces that were called from
> > several different static libs all worked.
> >
> > But as soon as I include a "tracepoint" style tracepoint (that uses
> > trace provider include files etc.) then doing a "lttng list -u"
> > returns "None" for UST events.
> >
> > Is there some kind of rule that says a file can't use both tracef and
> > tracepoint calls?  Is there something special you have to do to use
> > tracef and tracepoints in same file?  Doing so appears to have broken
> > everything.
>
> It should just work.
>
> Can you provide a minimal example of the compile unit having this
> issue ?
>
> Also you mention "static libs". Make sure you do *not* define
> "LTTNG_UST_TRACEPOINT_PROBE_DYNAMIC_LINKAGE" in this case. See the
> lttng-ust(3) man page for details (section "Statically linking the
> tracepoint provider").

About that.  It's a big project so all of our components are compiled
as static libs and linked into one big executable at the end, I'm not
using lttng-ust static libs.  I'm linking final executable with
-llttng-ust and -ldl

I also have another question I just thought of regarding trace provider code.

We've got a bunch of C code that is being compiled with g++.  I
initially had problems getting anything tracepoint related to work
(with 2.11) and read somewhere that the trace provider code needed to
be compiled with gcc so I built that by hand since our cmake build
system is pretty complicated and just copied the resulting C .obj into
our build directory structure for cmake to pick up and that worked.  I
basically copied the gcc .obj over the broken one that cmake/g++
generated.

I'm not doing that now and am wrapping the -tp.h TRACEPOINT_EVENT
definitions with #ifdef __cplusplus extern "C" {} #endif /*
__cplusplus */

I'll have to go back and check my results as I've been on/off working
on this for a while but if I stub out tracepoint calls and just do
tracef it appears everything works.  If I stub out tracef calls and
just do tracepoint calls I think that works too.  The problem I have
is when I try to do both tracef and tracepoint in same file.  That's
when nothing works.

Is there an order to the includes?

In the C source file in question I do:

#include <lttng/tracef.h>
then later ...
#define TRACEPOINT_DEFINE
#include "my-tp.h"

Hmm, now that I pay more attention, I don't see any mention of
traceprovider code needing to be compiled with gcc vs g++ in the 2.13
documentation.

... and it looks like the traceprovider header changed to use
LTTNG_UST_ in front of everything and I'm still using lttng 2.11
style!  So I think my problem is probably associated with needing to
re-do my traceprovider code to update to 2.13 style.  Don't know if
the C++ thing is still an issue.

Regards,

Brian
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev