Skip Navigation Links | |
Exit Print View | |
man pages section 3: Library Interfaces and Headers Oracle Solaris 11.1 Information Library |
Library Interfaces and Headers
SMHBA_GetAdapterAttributes(3LIB)
SMHBA_GetAdapterPortAttributes(3LIB)
SMHBA_GetBindingCapability(3LIB)
SMHBA_GetDiscoveredPortAttributes(3LIB)
SMHBA_GetFCPhyAttributes(3LIB)
SMHBA_GetPersistentBinding(3LIB)
SMHBA_GetPortAttributesByWWN(3LIB)
SMHBA_GetProtocolStatistics(3LIB)
SMHBA_GetSASPhyAttributes(3LIB)
SMHBA_GetVendorLibraryAttributes(3LIB)
SMHBA_GetWrapperLibraryAttributes(3LIB)
SMHBA_RegisterForAdapterAddEvents(3LIB)
SMHBA_RegisterForAdapterEvents(3LIB)
SMHBA_RegisterForAdapterPhyStatEvents(3LIB)
SMHBA_RegisterForAdapterPortEvents(3LIB)
SMHBA_RegisterForAdapterPortStatEvents(3LIB)
SMHBA_RegisterForTargetEvents(3LIB)
SMHBA_RemoveAllPersistentBindings(3LIB)
SMHBA_RemovePersistentBinding(3LIB)
- threads debugging library
cc [ flag ... ] file ... -lc_db [ library... ] #include <proc_service.h> #include <thread_db.h>
The libc_db library provides support for monitoring and manipulating threads-related aspects of a multithreaded program. There are at least two processes involved, the controlling process and one or more target processes. The controlling process is the libc_db client, which links with libc_db and uses libc_db to inspect or modify threads-related aspects of one or more target processes. The target processes must be multithreaded processes that use libc. The controlling process mignt or might not be multithreaded itself.
The most commonly anticipated use for libc_db is that the controlling process will be a debugger for a multithreaded program, hence the “db” in libc_db.
The libc_db library is dependent on the internal implementation details of libc. It is a “friend” of libc in the C++ sense, which is precisely the “value added” by libc_db. It encapsulates the knowledge of libc internals that a debugger needs to manipulate the threads-related state of a target process.
To be able to inspect and manipulate target processes, libc_db makes use of certain process control primitives that must be provided by the process using libc_db. The imported interfaces are defined in proc_service(3PROC). In other words, the controlling process is linked with libc_db and calls routines in libc_db. In turn, libc_db calls certain routines that it expects the controlling process to provide. These process control primitives allow libc_db to:
Look up symbols in a target process.
Stop and continue individual lightweight processes ( LWPs) within a target process.
Stop and continue an entire target process.
Read and write memory and registers in a target process.
Initially, a controlling process obtains a handle for a target process. Through that handle it can then obtain handles for the component objects of the target process, its threads, its synchronization objects, and its thread-specific-data keys.
When libc_db needs to return sets of handles to the controlling process, for example, when returning handles for all the threads in a target process, it uses an iterator function. An iterator function calls back a client-specified function once for each handle to be returned, passing one handle back on each call to the callback function. The calling function also passes another parameter to the iterator function, which the iterator function passes on to the callback function. This makes it easy to build a linked list of thread handles for a particular target process. The additional parameter is the head of the linked list, and the callback function simply inserts the current handle into the linked list.
Callback functions are expected to return an integer. Iteration terminates early if a callback function returns a non-zero value. Otherwise, iteration terminates when there are no more handles to pass back.
The shared object libc_db.so.1 provides the public interfaces defined below. See Intro(3) for additional information on shared object interfaces.
|
shared object
64-bit shared object
See attributes(5) for description of the following attributes:
|