Call start/stop API in non-main thread

[Artem Shcherbak]

Hello, @derekbruening

I'm experimenting with starting DR from the application. Using start/stop API described here https://dynamorio.org/dr__app_8h.html#abcdedd068a4d264401c31767355ec218 it was possible to make a global start and stop.
main() {
    dr_set();
    dr_start();

    some_function();

    dr_stop();
    dr_clean();
}

But if I calls to these functions in the thread function, there is a freeze. The logs show that start is called 2 times and stop never once(for 8 threads). join in the main waits for all threads.

pthread_finction(){
    pthread_mutex_lock(&lock);
    if (count == 0) {
         dr_set();
         count+=1;
     }
    dr_start();
    pthread_mutex_unlock(&lock);

    some_function();

    pthread_mutex_lock(&lock);
    dr_stop();
    if (count == THREAD_NUM) {
         dr_clean();
     }
    pthread_mutex_unlock(&lock);
}

As I understand from the description of start/stop API functions they are called globally.

Q: If I want to trace functions in a thread, like I showed in the example, can I use the start/stop API (maybe I used it incorrectly for this) or should I go to the annotation approach?

BR,

Artem

[Artem Shcherbak]

In the code above, the counter is incremented outside of if. (I made a mistake in copying)

if (count == 0) {
         dr_set();
 }

 count+=1;

BTW, if I start and stop once, then the trace from all threads is going, and dr_clean finishes successfully, but the application freezes.

pthread_finction(){
    pthread_mutex_lock(&lock);
    if (count == 0) {
         dr_set();

         dr_start();
     }
     count+=1;
    pthread_mutex_unlock(&lock);

    some_function();

    pthread_mutex_lock(&lock);
    if (count == THREAD_NUM) {

         dr_stop();
         dr_clean();
     }
    pthread_mutex_unlock(&lock);
}

понедельник, 17 февраля 2025 г. в 18:05:27 UTC+3, Artem Shcherbak:

[Doug Evans]

Just to be clear, dr_start is spelled dr_app_start, and same for the others.
ref: https://dynamorio.org/dr__app_8h.html#abcdedd068a4d264401c31767355ec218

It is not possible to use start/stop on individual threads.
One alternative is to trace all threads and then only examine particular threads when processing the trace.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/804a1aaa-6f74-4f2a-8d30-beb54d72eb02n%40googlegroups.com.

[Doug Evans]

By dr_clean do you mean dr_app_cleanup?
The docs for the latter say "This should be invoked at application exit, after joining with application threads. If the application wants to continue executing significant code or executing additional threads after cleanup, it should use dr_app_stop_and_cleanup() instead."

--

You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/92d63ef8-c3a8-434d-bcf3-9e98132269ccn%40googlegroups.com.

[Artem Shcherbak]

Thanks for reply!

Yes, dr_start and other dr_*  functions is a wrappers for dr_app_start and other dr_app* functions.
Ok, I understood that  It is not possible to use start/stop on individual threads.

So, instead of start/stop API I insert instructions into the code of workload, which I will then recognize in the client(drcachesim) and make a trace record only inside such labels. I will have to somehow, when recognizing such an instruction, ask the dynamorio not to cache the BB with this instruction, to recognize it next time.

BR,

Artem

четверг, 20 февраля 2025 г. в 08:35:58 UTC+3, d...@google.com:

[Derek Bruening]

If the goal is to only trace certain threads, drmemtrace has a feature precisely for that purpose, if you can tell whether to trace by the thread id: https://dynamorio.org/namespacedynamorio_1_1drmemtrace.html#a0c628011b0f875bb8dc3397052b4d0b5

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/05e8f70a-1900-4e3f-98d6-a441bb4e4e9en%40googlegroups.com.

[Artem Shcherbak]

The main goal is to collect() the trace in a set of marks (start, end), which are placed inside a function that can be called many times in different threads.
Now I run app. under DR and inside drcachesim tracer make a clean call for each such mark (start, end), in which I set the flag for starting recording and stopping the trace, which is then processed in output.cpp(for decachesim) and turns the trace recording on and off(change flag do_write). This is done globally, so now I'm thinking about how to remake it to a thread-by-thread version.

BR,

Artem

четверг, 20 февраля 2025 г. в 20:20:32 UTC+3, Derek Bruening:

[Derek Bruening]

Annotations may be the best fit there.  Using annotations to delineate tracing regions is https://github.com/DynamoRIO/dynamorio/issues/3107.  For enabling/disabling tracing you would want to use the drbbdup on/off, instead of just dropping the i/o which still incurs the instrumentation overhead: i.e., using the operation modes currently used by -trace_instr_intervals_file, etc.  This would be useful to others as well so please consider contributing it back upstream.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/04426d06-0074-4377-9c8c-f970e7f6c51dn%40googlegroups.com.

[Artem Shcherbak]

Thanks for reply.

Yes, thank you, Annotations fit here. I looked at annotations_api.h in general it is clear how to use. What about drbbdup on/off, as I understood, before and after the window I need to set the mode BBDUP_MODE_NOP, and between the labels BBDUP_MODE_TRACE. 

But, if I want for each thread the stopping of the trace record to be independent of other threads, is it possible to do it?

четверг, 20 февраля 2025 г. в 22:53:13 UTC+3, Derek Bruening:

[Derek Bruening]

For per-thread control you would have to store the mode in TLS.  That doesn't work well with global mode switches so you would have two different schemes probably picked at init time with no support for mixing. This seems an unusual use case: filtering out some threads completely is a use case we have encountered; but tracing different threads at different times is not.  You could file a feature request explaining the use case and send a PR implementing the two-scheme solution.  An alternative if trace size or overhead is less of a concern is to filter the trace offline for the desired thread regions; the record_filter tool can even be used to create a new trace if desired.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/820dbb2b-2ca6-42cc-ba32-dd08120940fen%40googlegroups.com.