Strace for library calls

Conceptually, a library function is part of your process.

At run-time, your executable code and the code of any libraries (such as libc.so) it depends on, get linked into a single process. So, when you call a function in such a library, it executes as part of your process, with the same resources and privileges. It's the same idea as calling a function you wrote yourself (with possible exceptions like PLT and/or trampoline functions, which you can look up if you care).

Conceptually, a system call is a special interface used to make a call from your code (which is generally unprivileged) to the kernel (which has the right to escalate privileges as necessary).

For example, see the Linux man brk. When a C program calls malloc to allocate memory, it is calling a library function in glibc.

If there is already enough space for the allocation inside the process, it can do any necessary heap management and return the memory to the caller.

If not, glibc needs to request more memory from the kernel: it (probably) calls the brk glibc function, which in turn calls the brk syscall. Only once control has passed to the kernel, via the syscall, can the global virtual memory state be modified to reserve more memory, and map it into your process' address space.

Have you looked at LTTng? It is a kernelspace/userspace tracing framework that works on several architectures, including ARM.

You can set up tracing for userspace code with LTTng-UST. But you'd have to recompile the shared libraries you want to trace, with your LTTng tracepoints added in.

Here is a guide from the official lttng docs on setting up userspace tracing: Tracing your own user application

I don't know if this would be helpful in your case, but there is also a Stack Overflow thread on compiling/installing lttng on embedded platforms (including ARM): How do I build and deploy LTTng to an embedded Linux system?