![[Return to Library]](BOOKSHELF.GIF){kind=small}
![[Contents]](TOC.GIF){kind=small}
![[Previous Chapter]](http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/AA-QTLMB-TE_html/REW.GIF)
![[Next Section]](http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/AA-QTLMB-TE_html/NEXT.GIF)
![[Next Chapter]](FF.GIF){kind=small}
![[Index]](INDEX.GIF){kind=small}
![[Help]](HELP.GIF){kind=small}
This chapter contains notes about issues and known problems with the development environment software and, whenever possible, provides solutions or workarounds to those problems.
DEC Ada is now supported on Digital UNIX Version 4.0B with DEC Ada V3.3 for Digital UNIX.
![[Previous Section]](http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/AA-QTLMB-TE_html/PREV.GIF)
In this release of Digital UNIX, the following C library functions exist in two versions due to conflicts between previous versions of Digital UNIX (to maintain binary compatibility these interfaces remain the default in this version of Digital UNIX as well) and the recent X/Open Single UNIX Specification. The Single UNIX Specification interfaces will be used when the c89 command is used or when the C preprocessor symbol _XOPEN_SOURCE_EXTENDED is defined.
a64l dbm_forder getsockname readv sigaction accept dbm_nextkey l64a recvfrom signal basename dbm_store nftw recvmsg sigpause dbm_delete dirname pipe sendmsg sigset dbm_fetch ftw putmsg setpgrp ttyslot dbm_firstkey getpeername putpmsg setrlimit
The Single UNIX Specification interfaces are recommended for new designs and implementations. They will ensure portability of code on all UNIX platforms. In most cases the changes in the function will not require changes to the application source code using the function, just a recompilation.
When using the -g flag with the C compiler, debug information is not produced for small integer types (8-bit and 16-bit) in old-style function definitions. Correct code is generated, it is only the debugger information that is incomplete. The following example illustrates the types of definitions that will result in the missing information:
"int sub1(a, b, c)"
"int a;"
"short b;"
"char c;"
"{ ... }"
In this example, both b and c are small integer types, and sub1 has an old-style definition. The following example uses the new prototype-style definition, so there is no missing information:
"int sub1(int a, short b, char c)"
"{ ... }"
You will notice the missing information when using the where command in dbx as follows:
% cc -g dbx.c % dbx a.out (dbx) where > 0 sub1(a = 1) ["dbx.c":1, 0x1200011c4] 1 main() ["dbx.c":11, 0x120001220]
The missing information can also cause a problem if using the dbx call command, as the debugger interprets sub1 as only having a single parameter:
(dbx) call sub1(5, 6, 7) too many parameters in call to sub1
It is possible to work around this problem by converting to the ANSI C prototype style function definitions or by avoiding the small integer types as parameters in old-style function definitions. Alternatively, use the -oldc option when compiling.
The CMPDEVALT410 subset contains an alternate application compiler suite. The README file contained in the subset explains its use.
There is a restriction with the DEC C compiler in that a single object file cannot contain more than 4093 external address references. The compiler will issue the following error message when compiling a module that exceeds this limit:
GP-relative section overflows limit of 32752 bytes
To workaround this problem break your module into smaller compilation units or use the -oldc compiler option.
When using the -ifo switch in DEC C, symbol information for external variables may be incorrect. For example:
% cat simple.c
int global_array[100][4];
main() { int local_array[100][4]; }
% cc -O1 -g2 -ifo simple.c % dbx a.out (dbx) whatis global_array int global_array; (dbx) whatis local_array local_array[100][4] of int ;
Note that the global array is reported as int and the local array is a two dimensional array of ints. Both should report the same thing.
If this program is executed without -ifo, the results are as expected. The problem is in the generation of the symbol table, not the debugger.
The libraries libxti.a, libtli.a, libxti.so, and libtli.so now support multithreaded applications. New xti.h (for XTI) and tiuser.h (for TLI) are available to be included by applications. Binary backwards compatibility has been preserved and unithreaded applications built with previous include files will still run.
The following notes apply to general programming.
Digital Fortran Version 4.0 uses a threaded run-time-library on Digital UNIX Version 4.0 and later. To run nonthreaded applications nonshared, the libc_r.a library must be linked in to resolve the thread routines used by the RTL. The Digital UNIX Version 4.0 f77 and f90 drivers determine if this is the case by recognizing the -threads command line option; if it is not present and -non_shared is, then -qlc_r is added to the line passed to ld.
Digital UNIX Version 4.0 and later added the -pthread switch to support POSIX 1003.1c-conformant DECthreads interfaces in libpthread. Drivers f77 and f90 do not recognize -pthread as requiring the same handling by them as -threads in Digital UNIX Version 4.0 and later. To use -pthread (as in the KAP product on Digital UNIX Version 4.0), you must compile using the -c switch to produce .o files and then explicitly invoke ld with the same switches that f77 or f90 would use, omitting -qlc_r.
The dbx and ladebug debuggers are not able to stop at a breakpoint inside of the _exit() routine. If you attempt to set a breakpoint in this routine, the debugger will continue past it without stopping. Should you need to stop your application just before it exits, try setting a breakpoint in exit() instead of _exit(). Another workaround is to use the dbx debugger with the -noproc switch or the ladebug debugger with the -ptrace switch. For example:
%
dbx -noproc myapp
or
%
ladebug -ptrace myapp
A patch for this problem will be available soon, check with the customer service center for details.
If you use the atom command's -g switch to debug an atom tool's analysis code, you may not be able to set debugger breakpoints in ProgramAfter or ObjAfter analysis routines. If you attempt to set such a breakpoint, the debugger will continue past it without stopping and may then report a false segmentation violation in your analysis code. To avoid this problem, use the dbx debugger with the -noproc switch or the ladebug debugger with the -ptrace switch. For example:
%
dbx -noproc hw.atom
or
%
ladebug -ptrace hw.atom
A patch for this problem will be available soon, check with the customer service center for details.
The following notes apply to real time programming.
The symbol SA_SIGINFO, defined in sys/signal.h, is not visible under certain namespace conditions when _POSIX_C_SOURCE is explicitly defined in the application or on the compile line.
The SA_SIGINFO symbol will be visible if you do not explicitly define _POSIX_C_SOURCE. For most applications, unistd.h provides the standards definitions needed, including _POSIX_C_SOURCE. As a general rule, avoid explicitly defining standards macros in your application or on the compile line. If you do explicitly define _POSIX_C_SOURCE then beSA_SIGINFOwill visible if you also explicitly define _OSF_SOURCE
POSIX 1003.1b synchronized I/O using file status flags does not apply to file truncation. When file status flags are used to control I/O synchronization, no synchronization occurs for file truncation operations.
The fsync() or fdatasync() function can be used to explicitly synchronize truncation operations.
A problem occurs when fcntl() is called with the F_GETFL request, and the file operated on has the O_DSYNC file status flag set. The return mask incorrectly indicates O_SYNC instead of O_DSYNC.
The following notes apply to DECthreads.
DECthreads Exception Handling now relies on the DEC C exception handling capabilities. Threaded applications must now link with libexc. Note that if you are compiling your threaded application as Digital recommends (using the -thread or -pthreads switch) this change will not affect the building of your application.
If you are using the DECthreads Exception Package with POSIX 1003.1c threads interface, you must include pthread_exception.h in your source file. This does not apply to applications that use the CMA or draft 4 POSIX threads interfaces.
The following notes apply to DECthreads:
The localtime_r() and pthread_self() function declarations are missing from the system header files. No extern definitions are available. This affects applications that are compiled using C++.
If a multithreaded process calls fork() after having called pthread_cond_destroy(), the child process will core dump with a segmentation violation. There is no workaround for this problem.
If a multithreaded process calls fork() with threads blocked on a mutex, the child process will be unable to destroy the mutex. The routine pthread_mutex_destroy() will return EBUSY. There is no work around for this problem.
Full support of the POSIX 1003.1c signal model may cause a binary compatability problem for applications using threads. This is not an API change but a change in run-time behavior. A thread that was never interrupted before may now be interrupted.
You cannot use dbx to debug threads (pthreads) in this release. Use the Ladebug debugger to debug threaded applications.
This release contains substantial changes to threads that will likely expose programming errors in existing applications that use DECthreads. Such errors include, but are not limited to, the following:
The following routines are not provided in this release:
If you use an application that requires one of these routines, do not migrate to Digital UNIX Version 4.0B.
Note that applications using pthread_bind_to_cpu_np are using the draft 4 POSIX interface which is scheduled for retirement. These applications should be migrated as soon as possible to the POSIX 1003.1c compliant interface. (See the retirement notice in this volume for pthreads draft 4).
The following static libraries for DECthreads have not been provided in this release:
The libraries will be provided in a future release.
Threaded applications that require system cancellation points must use the POSIX 1003.1c DECthreads interface. Cancellation points are not supported for the CMA or draft POSIX DECthreads interfaces. See the Guide to DECthreads for the list of supported cancellation points.
In this release, the metering capabilities of DECthreads may not be reliable in a process which forks.
In releases of Digital UNIX prior to Version 4.0, thread scheduling attributes were system wide. In this release, all thread policies and priorities are now local to the process. Thread priorities between processes cannot be controlled. No artificial limit now exists on thread priorities: the full priority range is now accessible by every thread. See the IEEE POSIX 1003.1c standard or Appendix A of the Guide to DECthreads for further discussion of contention scopes.
Use the current minimum firmware revisions for Digital UNIX Version 4.0B to get the best DECthreads performance. The correct firmware revisions for your processor are identified in the firmware documentataion.
Signal handling in the POSIX 1003.1c (pthread) interface of DECthreads is substantially different than signal handling is for the draft 4 POSIX and the CMA interfaces of DECthreads. When migrating your application from the draft 4 POSIX or CMA interfaces to the POSIX 1003.1c interface, please see the IEEE POSIX 1003.1c standard or the Guide to DECthreads for a discussion of signal handling in threaded applications.
Previously, Digital has supplied the none.c example driver in the /usr/examples/devdriver area. In this release, the none.c and none100 kit examples have been replaced by the ed100 driver example now in /usr/examples/devdriver. The file ed100 is a directory that contains the driver source and the associated files required to configure the driver. Refer to the Guide to Writing Device Drivers: Tutorial and the Guide to Writing Device Drivers: Advanced Tutorial for more information about writing device drivers.
Although existing VMEbus device drivers are compatible with the current version of Digital UNIX, you should plan on updating your device drivers to take advantage of the single binary module technology. Refer to Writing Device Drivers: Tutorial for more information on the single binary module technology, and for previous device driver mechanisms that are not being supported in this release, such as the config.file, stanza.static, and stanza.loadable files. The syntax in the files file fragment also has changed to accommodate the single binary module in this release of Digital UNIX.
For device driver information specific to VMEbus, refer to the Version 4.0B revision of Writing VMEbus Device Drivers, which supplements the tutorial.