I want to trace all the functions which an application calls. Here, I am not looking for system calls, but the library API's mainly.
I have tried truss, it is not showing some library API's which I am expecting. Is there any tool in solaris like 'ltrace' in linux which traces library calls? Does dtrace gives this info?
There are two ways to get what you want:
sotrussThe sotruss utility
The sotruss utility documentation:
sotruss
- trace shared library procedure calls
Synopsis
/usr/bin/sotruss [-f] [-F bindfromlist] [-T bindtolist] [-o outputfile] executable [executable arguments...]Description
sotrussexecutes the specified command and produces a trace of the library calls that it performs. Each line of the trace output reports what bindings are occurring between dynamic objects as each procedure call is executed.sotrusstraces all of the procedure calls that occur between dynamic objects via the Procedure Linkage Table, so only those procedure calls which are bound via the Procedure Linkage Table will be traced. See Linker and Libraries GuideOptions
DTrace pid provider
Per the Solaris 10 DTrace guide:
pidProviderThe
pidprovider enables you to trace any instruction in a process. Unlike most other providers,pidprobes are created on demand based on the probe descriptions found in your D programs. As a result, no pid probes are listed in the output ofdtrace -luntil you have enabled them yourself.User Function Boundary Tracing
The simplest mode of operation for the pid provider is as the user space analogue to the fbt provider. The following example program traces all function entries and returns that are made from a single function. The
$1macro variable (the first operand on the command line) is the process ID for the process to trace. The$2macro variable (the second operand on the command line) is the name of the function from which to trace all function calls....
Also see Brendan Gregg's blog for some more DTrace information:
DTrace pid Provider
The DTrace “pid” provider allows you to trace the internal execution of processes such as a web browser or a database. It’s documented in the original DTrace Guide and in the forthcoming DTrace Book. It is also powerful and unstable, and is the provider you’re most likely to shoot yourself in the foot with.
Here I’ll introduce the pid provider and discuss the stability of probe names, including tips and gotchas. This should be useful background for anyone using DTrace, which includes running other people’s pid provider-based DTrace scripts. For further reading, see my full list of pid provider posts.
While truss defaults to only showing system calls, it can also show library function calls if you use the -u option to request them. -u :: will show all function calls, or you can supply other arguments to filter which ones it shows.
