Add thapi_start()/stop() for localized profiling

[thilinarmtb]

I created lttng_ust_profiler lttng_ust_toggle event category and namespace'd user API
with thapi_profiler_* thapi_ (in a similar spirit to cudaProfilerStart() etc.). The library
which the user has to link against is named libThapiProfiler.so libThapi.so.

Usage of the API is as follows:

#include <thapi.h>
//
// code
//
thapi_start();
// code to be profiled
thapi_stop();
//
// more code
//

If libThapiProfiler.so libThapi.so is linked, thapi_profiler_stop() thapi_stop() is called
automatically during the library load time using __attribute__((constructor)). I added a check in
configure.ac to check if the compiler supports __attribute__((constructor)).

P.S: This feature requires lttng-ust >= 2.12.8. Specifically, this fix.

TODO

• Respect lttng_ust_profiler_* lttng_ust_toggle_* events when calculating statistics
• Fix failing checks
• Add the filter.toggle.toggle to babeltrace graph

[TApplencourt]

Please fix the distcheck : )

I think we can shorten the name to thapi_start and thapi_stop, same for the header and the lib. Hopefully. we will expose only one header and one lib

For the name of the event, I think I prefer thapi_toogle_start than thapi_profiler_start. As if we don't receive it, we still trace. So it's really a toogle

[TApplencourt]

Also if you don't mind adding a tests in integration tests. Just to verify that we can link, and then run. (maybe do a babeltrace2 | grep and check the event exists

Easier than to put a "real" test (aka make tests, those one are pretty hard to modify / extend)

[TApplencourt]

Nice! You may just need to specify the --output for the integration tests so the filter will be correct.

[thilinarmtb]

So the following general.bats works for me locally (in the sense that bats runs tests):

#!/usr/bin/env bats

setup_file() {
   export THAPI_HOME=$PWD/ici
   export IPROF=$THAPI_HOME/bin/iprof
   export THAPI_INC_DIR=$THAPI_HOME/include
   export THAPI_LIB_DIR=$THAPI_HOME/lib
}

teardown_file() {
   rm -rf $THAPI_HOME/thapi-traces
}

@test "thapi_start_stop" {
  cc -I${THAPI_INC_DIR} ./integration_tests/thapi_start_stop.c -o thapi_start_stop \
    -Wl,-rpath,${THAPI_LIB_DIR} -L${THAPI_LIB_DIR} -lThapi
  $IPROF --no-analysis -- ./thapi_start_stop

  start_count=`babeltrace2 $THAPI_HOME/thapi-traces | grep lttng_ust_toggle:start | wc -l`
  [ "$start_count" -eq 1 ]

  stop_count=`babeltrace2 $THAPI_HOME/thapi-traces | grep lttng_ust_toggle:stop | wc -l`
  [ "$stop_count" -eq 2 ]
}

Then I do:

bats general.bats

and I get:

general.bats
 ✗ thapi_start_stop
   (in test file general.bats, line 23)
     `[ "$stop_count" -eq 2 ]' failed
   THAPI: Trace location: /home/thilina/thapi/THAPI/ici/thapi-traces/thapi--2025-03-06T17:53:33+00:00

1 test, 1 failure

So, the __attribute__((constructor)) doesn't seem to work (not sure why, this worked before :)).
I will debug that -- but the integration test failure in GitHub CI is due to a different issue it seems.

[TApplencourt]

So, the attribute((constructor)) doesn't seem to work (not sure why, this worked before :)).

I guess it is me who told you to merge the two definitions? But yeah, this is why we have a CI. So easy to introduce a bug!

[thilinarmtb]

So, the attribute((constructor)) doesn't seem to work (not sure why, this worked before :)).

I guess it is me who told you to merge the two definitions? But yeah, this is why we have a CI. So easy to introduce a bug!

Haha -- but I doubt that is the issue -- but I will take a closer look.

[TApplencourt]

(don't worry about the failing test)

[thilinarmtb]

I played a bit with metababel filters. I could successfully drop the messages until we see a
thapi_start() trace, then resume pushing messages downstream until we see a thapi_stop()
trace again (and repeat).

I didn't register any callbacks and only made the following changes in the generated boilerplate
code in btx_filter/btx_main.c:

index cdec2b5..902e148 100644
--- a/./btx_filter/btx_main.c
+++ b/../btx_filter_main.c
@@ -22,6 +22,9 @@
  *   |_ o ._   _. | o _   _
  *   |  | | | (_| | | /_ (/_
  */
+
+static bool toggle_on = false;
+
 static inline bt_message_iterator_class_next_method_status
 filter_message_iterator_next_finalizing(
     bt_self_message_iterator *self_message_iterator,
@@ -109,14 +112,12 @@ static inline void filter_message_iterator_next_call_dispatchers(

   /* Event dispatcher */
   const char *class_name = bt_event_class_get_name(event_class);
-  name_to_dispatcher_t *s = NULL;
-  HASH_FIND_STR(common_data->name_to_dispatcher, class_name, s);
-  if (s) {
-    (*((dispatcher_t(*))(s->dispatcher)))(s->callbacks, common_data,
-                                          upstream_message);
+  bool toggle = (strncmp(class_name, "lttng_ust_toggle", 16) == 0);
+  if (toggle) {
     /* Drop message */
+    toggle_on = (strncmp(class_name, "lttng_ust_toggle:start", 32) == 0);
     bt_message_put_ref(upstream_message);
-  } else {
+  } else if (toggle_on) {
     /* Push upstream message to downstream */
     btx_downstream_push_message(message_iterator_private_data,
                                 upstream_message);

Seems like we can avoid having to generate a thapi_stop() trace with __attribute__((constructor))
when we use this filter if we initialize toggle_on to false. But this leads to logic being split in
filter source and the actual traces (and probably a bad idea).

[thilinarmtb]

Closing this in favor of #454.