Solaris tool to trace library API's

Question

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?

Answer 1

There are two ways to get what you want:

• sotruss
• DTrace pid provider

The 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

sotruss executes 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. sotruss traces 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 Guide

Options

DTrace pid provider

Per the Solaris 10 DTrace guide:

pid Provider

The pid provider enables you to trace any instruction in a process. Unlike most other providers, pid probes 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 of dtrace -l until 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 $1 macro variable (the first operand on the command line) is the process ID for the process to trace. The $2 macro 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.

Answer 2

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.