6    Development Environment Notes

This chapter contains notes about issues and known problems with the development environment software and, whenever possible, provides solutions or ways to avoid the problems. The following topics are discussed:

6.1    General Programming

The following notes apply to general programming.

6.1.1    Change to bcopy, bcmp, and bzero

The argument types for the bcopy, bcmp, and bzero system functions have been changed to conform to the ANSI specification. The new interface prototypes are as follows: 

int bcmp __((const void *, const void *, size_t);
int bcopy __((const void *, void *, size_t);
int bzero __((void *, size_t);

You can access the old prototype definitions by compiling applications using the -D__V40_OBJ_COMPAT compile flag. For example: 


> cc -D__V40_OBJ_COMPAT test.c

6.1.2    Change in struct utmp, struct utmpx, and struct lastlog

To bring them into compliance with several UNIX and Internet standards, the struct utmp, struct utmpx, and struct lastlog structures have been changed. These changes affect the /usr/include/utmp.h, /usr/include/utmpx.h, and /usr/include/lastlog.h files :

These changes also affect the format of the /var/adm/utmp, /var/adm/wtmp, and /var/adm/lastlog files. The following conversion programs are supplied:

The programs enable you to convert your existing /var/adm/wtmp and /var/adm/lastlog files to the new format or convert new format files to the old format for use by existing programs. See the corresponding reference pages for more information.

6.1.3    Segmentation Fault in gprof

When you run the gprof call-graph profiler with the -F or -f filtering options on an executable that contains a procedure with no name in the symbol table (for example, a static function compiled with the default -g0 debug information), it core dumps with a segmentation fault.

To avoid this problem, do not use the -F and -f options. Instead use -E or -e filtering options.

6.2    POSIX Threads Library (pthreads)

DECthreads has been renamed the POSIX Threads Library. Compaq has made enhancements to the library to improve the performance of some classes of threaded applications.

The following notes apply to POSIX Threads Library.

6.2.1    Problems with Use of the stackaddr Thread Creation Attribute

Using the stackaddr thread creation attribute, which allows you to allocate your own stack for a thread, is not recommend. The semantics of this attribute are poorly defined by POSIX and the Single UNIX Specification, Version 2. As a result, code using the attribute is unlikely to be portable between implementations. The attribute is difficult to use reliably, because you must, by intimate knowledge of the machine architecture and implementation, know the correct address to specify relative to the allocated stack. The implementation cannot diagnose an incorrect value because the interface does not provide sufficient information. Using an incorrect value might result in program failure, possibly in obscure ways.

Alternatively, if you want to supply your own thread stacks, consider using the pthread_attr_setstackaddr_np() routine. Callers specify the thread stack using a base address and size, which avoids the worst problems with the standard interface.

6.2.2    Memory Alignment Issue

Although older Alpha processors (prior to the 21264 chip) can only access memory in units of at least a quadword (8 bytes), multiple variables, each of which is less than 8 bytes, can occupy the same quadword in memory. In such cases, multithreaded programs might experience a problem if two or more threads read the same quadword, update different parts of it, then independently write their respective copies back to memory. The last thread to write the quadword overwrites any data previously written to other parts of the quadword. This can happen even though each thread protects its part of the quadword with its own mutex.

The Tru64 UNIX C compiler protects scalar variables against this problem by aligning them in memory on quadword (8-byte) boundaries. However, in composite data objects such as structures or arrays, the compiler aligns members on their natural boundaries. For example, a 2-byte member is aligned on a 2-byte boundary. Because of this, any adjacent members of the composite object that total 8 bytes or less could occupy the same quadword in memory.

Inspect your multithreaded application code to determine if you have a composite data object in which adjacent members could share the same quadword in memory. If you do and if your project allows, it is recommended that you force alignment of each such member variable to a quadword boundary by redefining the variable to be at least 8 bytes, or by defining sufficient padding storage after the variable to total 8 bytes.

Alternatively, you can create one mutex for each composite data object in which adjacent members can share the same quadword in memory. Then use this single mutex to protect all write accesses by all threads to the composite data object. This technique might be less desirable because of performance considerations.

For more information, see the Granularity Considerations section in the Guide to the POSIX Threads Library.

6.2.3    POSIX Threads Library pthread_debug() and pthread_debug_cmd() Routines

In order to allow for the possibility of a more comprehensive and robust threads debugging environment, it has become necessary to remove the pthread_debug() and pthread_debug_cmd() routines. To prevent existing binaries from failing, the routines will continue to be recognized. However, a call to either routine now results in an immediate return to the calling program. The pthread_debug_cmd() routine returns a zero (0) indicating success. Debuggers such as Ladebug and TotalView provide functionality formerly provided by these routines.

6.2.4    POSIX Threads Library SIGEV_THREAD Notification Mechanism

Using the SIGEV_THREAD notification mechanism, a user-defined function is called to perform notification of an asynchronous event. The function runs as though it were the start routine of a thread and can make full use of the POSIX Threads Library synchronization objects.

The SIGEV_THREAD notification mechanism and the function to be called are specified in the sigevent structure. This mechanism is useful for programming with the POSIX 1.b realtime signal interfaces, such as timers and asynchronous I/O. For information and cautions concerning the use of signals in a multithreaded environment, see the Guide to the POSIX Threads Library. For more information about using SIGEV_THREAD, see the IEEE POSIX 1003.1-1996 standard and The Open Group Single UNIX Specification, Version 2.

6.2.5    POSIX Threads Library Change in the Default Stack Size

POSIX Threads Library now supports using uncommitted memory for thread stacks. As part of this new support, the default thread stack size has been raised to 5 MB. This means that it should rarely, if ever, be necessary to override the default. However, you should change any existing code that determines the default dynamically by fetching from an initialized attributes object and multiplying it to avoid allocating more address space than the application needs. If you do not, the application could also encounter ulimit problems.

Also, code that specifies literal sizes usually allocates stacks sizes that are smaller than the default. Therefore, it is recommended that these applications use the default stack size.

6.2.6    Process-Shared Synchonization Objects and Debugging

The POSIX Threads Library (pthread) interface now supports the sharing of certain synchronization objects (mutexes, condition variables, and read-write locks) among threads running in multiple cooperating processes. Such objects are termed process-shared objects.

For this release, process-shared objects are not visible to the Ladebug debugger. For example, the show mutex Ladebug command lists process-private mutexes but not process-shared mutexes.

6.3    Changes to the ATM Kernel Programming Interface

To support features needed for point-to-multipoint virtual circuits (VCs) and to provide for future enhancements, the parameters to the atm_cmm_register_cvg() and atm_cmm_register_sig() routines have been changed.

Binary compatibility with previously compiled modules has been maintained. Convergence and signaling modules require minor source code changes when recompiled under Tru64 UNIX 5.0A.

See the Asynchronous Transfer Mode manual for more information.