On Wed, Jun 21, 2023 at 4:21 PM Mathieu Desnoyers
<mathieu.desnoy...@efficios.com> wrote:
>
> On 6/20/23 18:02, Brian Hutchinson wrote:
> > On Thu, May 11, 2023 at 2:14 PM Mathieu Desnoyers
> > <mathieu.desnoy...@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.desnoy...@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.desnoy...@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
