I am currently trying to perform a detailed analysis of a dynamic C library's "mimalloc" behavior when loaded by a specific program in a Linux environment. Specifically, I want to comprehensively understand which functions within the mimalloc library's source code are called, how many times each function is called, and what arguments are passed to them during the execution of a test program. how do I trace functions of library source code?

After researching methods to achieve this, I have identified the following tools as potential candidates: strace ltrace utrace ftrace etrace

• My environment and library details are as follows: OS: Linux (Ubuntu)
• Library Executable Path: /home/user/mimalloc-2.1.7/out/release/libmimalloc.so.2
• Library Source Code Path: /home/user/mimalloc-2.1.7/src/
• Test Program: A simple C program linked with the mimalloc library, designed to call functions such as mi_malloc and mi_free.

Add information

• Library "Mimalloc " Document and Source code[/?tab=readme-ov-file#using-the-library]

My primary goal is to trace in detail within libmimalloc.so itself how functions call other functions (e.g., helper functions called within the implementation of mi_malloc), how many times they are called, and what arguments are passed.

In my situation, there is no separate library like libX.so for which I don't have the source code. The scope of my investigation involves only libmimalloc.so (for which I do have the source code).

As pointed out, since I have the source code for mimalloc, I can rebuild it with debug symbols (e.g., using -g).

Regarding the suggestion of ltrace from a previous comment: I tried using it. While it successfully traced calls from my test program to libmimalloc.so functions (like mi_malloc), it did not trace the function calls internal to the library (e.g., calls from mi_malloc to its internal helper functions) as I had hoped.

Therefore, I am looking for more effective tracing methods to gain detailed insight into the internal behavior of the mimalloc library. GDB is not suitable for this purpose due to its slow execution speed during debugging.