|
CodeCenter v4.2.1 Platform Guide
Last Reviewed: 8/99 |
Copyright © 1999 by CenterLine Systems, Inc. |
CodeCenter Platform Guide
|
This Platform Guide describes the supported compilers, supported windowing systems, library functions replaced by CodeCenter for run-time error checking, shared library support, and potential SUN and HP anomalies when using CodeCenter version 4.2.1.
For CodeCenter's memory, swap space, and disk space requirements, please see the CodeCenter Release Bulletin on the main CodeCenter page of CenterLine's website.
SUN System Requirements |
This version of CodeCenter supports the following platforms, compilers, and windowing systems for SUN architectures. | |||
Supported SUN Platforms |
For a list of the platforms supported by CodeCenter Version 4.2.1, refer to the "Supported Platforms" section of the CodeCenter Release Bulletin. Additionally, you can review CenterLine's Product Compatibility Matrix which summarizes platform, compiler, etc. support for all CenterLine products. |
|||
Supported SUN Compilers |
CodeCenter supports the following compilers on SunOS and Solaris operating systems:
CodeCenter supports the following compilers on SunOS and Solaris but with limitations to browsing and source level debugging. CenterLine-C is link compatible with them.
|
|||
Supported Windowing Systems |
CodeCenter supports both the Motif and OPEN LOOK windowing systems on SunOS and Solaris platforms. OPEN LOOK is the default on the Sun platform. You can choose Motif at startup with the -motif switch on the codecenter command line. CodeCenter also supports the Common Desktop Environment (found on some SUN platforms). |
|||
HP System Requirements |
This version of CodeCenter supports the following platforms, compilers, and windowing systems for HP architectures. | |||
Supported HP Platforms |
For a list of the platforms supported by CodeCenter Version 4.2.1, refer to the "Supported Platforms" section of the CodeCenter Release Bulletin. Additionally, you can review CenterLine's Product Compatibility Matrix which summarizes platform, compiler, etc. support for all CenterLine products. |
|||
Supported HP Compilers |
CodeCenter supports the following compilers on HP-UX operating systems:
CodeCenter on the HP platform does NOT support source-level debugging of object modules compiled by gcc, the GNU C compiler available from the Free Software Foundation. You can also load FORTRAN object files that are in either of the following categories:
|
|||
Supported Windowing Systems |
CodeCenter supports both the Motif and OPEN LOOK windowing systems. Motif is the default on the HP platform. You can choose OPEN LOOK at startup with the -openlook switch on the codecenter command line. CodeCenter also supports the Common Desktop Environment (found on some HP platforms). |
|||
SUN C Library Functions Replaced |
To do its run-time error checking and to make its environment behave like a standard UNIX process, CodeCenter replaces many C library functions and system calls with its own version of them. For some of these functions, you can substitute your own version. However, CodeCenter cannot provide run-time error checking on your substituted function. To use your own version of a function, load the function in a source or object file before linking your program. If your program has already been linked, you must quit, and then start a new CodeCenter session to substitute your function for one of the CodeCenter replacements. The following three tables list functions that CodeCenter replaces. The three tables apply to:
Table 1: CodeCenter replaces these C Library functions on SunOS (Solaris 1.0):
Name of Can You | Name of Can You
Function Substitute | Function Substitute
Your Own | Your Own
Function? | Function?
------------------------------+------------------------------
|
__builtin_alloc() no | shmdt() no
_exit() no | shmget() no
_longjmp() no | shmctl() no
_setjmp() no | sigaction() no
alloca() no | sigaddset() yes
bcopy() yes | sigblock() no
brk() no | sigdelset() yes
bzero() yes | sigemptyset() yes
close() no | sigfillset() no
dup2() no | sigismember() yes
fork() no | siglongjmp() no
free() yes | signal() no
getdtablesize() no | sigpause() no
getrlimit() no | sigpending() no
longjmp() no | sigprocmask() no
malloc() yes | sigsetjmp() no
mallopt() yes | sigsetmask() no
mallinfo() yes | sigstack() no
memalign() yes | sigsuspend() no
memcpy() yes | sigvec() no
memccpy() yes | strcat() yes
memset() yes | strcmp() yes
mmap() no | strcpy() yes
munmap() no | strncat() yes
pause() no | strncmp() yes
realloc() yes | strncpy() yes
sbrk() no | syscall() no
setjmp() no | system() yes
setrlimit() no | valloc() yes
shmat() no | vfork() no
______________________________|______________________________
Table 2: CodeCenter replaces these C Library functions on Solaris 2.
Name of Can You | Name of Can You
Function Substitute | Function Substitute
Your Own | Your Own
Function? | Function?
------------------------------+------------------------------
|
__builtin_alloc() no | shmget() no
_exit() no | shmctl() no
alloca() no | sigaction() no
atexit() no | sigaddset() yes
brk() no | sigdelset() yes
close() no | sigemptyset() yes
dup2() no | sigfillset() no
exit() no | sigismember() yes
fork() no | siglongjmp() no
free() yes | signal() no
getrlimit() no | sigpause() no
longjmp() no | sigpending() no
malloc() yes | sigprocmask() no
memalign() yes | sigsetjmp() no
memcpy() yes | sigsuspend() no
memccpy() yes | strcat() yes
memove() no | strcmp() yes
memset() yes | strcpy() yes
mmap() no | strncat() yes
munmap() no | strncmp() yes
pause() no | strncpy() yes
realloc() yes | syscall() no
sbrk() no | sysconf() no
setjmp() no | system() yes
setrlimit() no | valloc() yes
shmat() no | vfork() no
shmdt() no |
______________________________|______________________________
Table 3: CodeCenter replaces these C Library functions on Solaris 2 in libucb.
Name of Can You | Name of Can You
Function Substitute | Function Substitute
Your Own | Your Own
Function? | Function?
------------------------------+------------------------------
|
_longjmp() no | signal() no
_setjmp() no | sigpause() no
bcopy() yes | sigsetmask() no
bzero() yes | sigstack() no
getdtablesize() no | sigvec() no
getrlimit() no | syscall() no
longjmp() no | ucbsignal() no
setjmp() no | ucbsigpause() no
sigblock() no | ucbsigblock() no
______________________________|______________________________
|
|||
HP C Library Functions Replaced |
To do its run-time error checking and to make its environment behave like a standard UNIX process, CodeCenter replaces many C library functions and system calls with its own version of them. For some of these functions, you can substitute your own version. However, CodeCenter cannot provide run-time error checking on your substituted function. To use your own version of a function, load the function in a source or object file before linking your program. If your program has already been linked, you must quit, and then start a new CodeCenter session to substitute your function for one of the CodeCenter replacements. The following table lists functions that CodeCenter replaces.
Name of Can You | Name of Can You
Function Substitute | Function Substitute
Your Own | Your Own
Function? | Function?
------------------------------+------------------------------
|
_exit() no | shmat() no
_longjmp() no | shmdt() no
_mcount() no | shmget() no
_setjmp() no | shmctl() no
alloca() no | sigaction() no
bcopy() yes | sigaddset() no
brk() no | sigblock() no
bzero() yes | sigdelset() no
close() no | sigemptyset() no
dup2() no | sigismember() no
fork() no | signal() no
free() yes | sigpause() no
getdtablesize() no | sigpending() no
getrlimit() no | sigprocmask() no
longjmp() no | sigsetmask() no
malloc() yes | sigstack() no
mallinfo() yes | sigsuspend() no
mallopt() yes | sigvec() no
memmove() yes | sigvector() no
memcpy() yes | strcat() yes
memccpy() yes | strcpy() yes
memset() yes | strncat() yes
pause() no | strncpy() yes
realloc() yes | sysconf() no
sbrk() no | vfork() no
setjmp() no |
setrlimit() no |
______________________________|______________________________
On HP platforms, CodeCenter replaces the following libBSD functions, neither of which can be replaced by the user:
On HP platforms, CodeCenter replaces the following libV3 functions, none of which can be replaced by the user:
|
|||
SUN Shared Libraries |
This section describes the support for shared libraries within the CodeCenter environment. For general information about Sun shared libraries, see the Sun manual "Programming Utilities & Libraries" for SunOS and "Linker and Libraries Manual - SunOS 5.0" on Solaris 2. Reading debugging information on shared libraries is not supported in component debugging mode (CDM, a.k.a. CodeCenter's Interpreter). Without debugging information on a file, you are unable to perform certain debugging activities, such as stepping through functions. For information about what debugging techniques are possible on code without debugging information, see the debugging entry in the Manual Browser or "CodeCenter Reference Manual" CodeCenter supports full source-level debugging of shared libraries in process debugging mode (PDM). For example, you can step into functions in shared libraries that were compiled with -g. Once you load a shared library into CodeCenter, its functions and any of its data that you have exported are available to your program. CodeCenter mimics the behavior of the system's link editors, ld and ld.so, with regard to loading shared libraries and with regard to binding functions and data. |
|||
Search Rules for Loading Libraries |
When you load a library using the load command's -l switch, CodeCenter searches for libraries in its search path in the same way that the Sun ld command does. CodeCenter stops searching as soon as it finds either the shared or the static version of the library. If it finds both versions in the same directory, CodeCenter uses the shared version (.so file) by default. You can, however, override this default behavior by specifying the binding mode:
Note that CodeCenter may load more libraries that just the X11 library. When you load a library into CodeCenter, CodeCenter also loads any other library referenced by the library you loaded explicitly. CodeCenter unloads only the X11 library as a result of the unload -X11. The unload command unloads only those libraries that you explicitly unload, regardless of whether CodeCenter loaded them as a result of a reference or an explicit load command. CodeCenter allows you to load both the static and shared versions of a library, but we do not recommend that you do so. On SunOS (Solaris 1), when CodeCenter loads a shared object (an .so file), it looks in the same directory for a data interface description file (an .sa file) with the same root name and version number. If it finds such an .sa file, it loads it so it can generate the necessary data references. CodeCenter does not report an error if it fails to find such an .sa file. NOTE : CodeCenter does not load an .sa file with the same root name but different version number as an .so file. This situation is treated the same as a missing .sa file. |
|||
Using Environment Variables to Modify Loading Libraries |
One way to affect how CodeCenter loads shared libraries is by setting environment variables before starting CodeCenter. Like ld, CodeCenter takes into account the following environment variables.
|
|||
Using Switches to Modify the Loading of Libraries |
Another way to affect how CodeCenter loads shared libraries is to use ld's command-line switches with CodeCenter's load command. The following command-line switches affect how CodeCenter loads libraries:
CodeCenter ignores other ld command-line switches. |
|||
Specifying the Binding Mode |
If you want to load the static version of a library instead of the shared version, you can specify the binding mode with the load command. Just as with ld, you specify the binding mode using the -B switch. The binding mode you specify is in effect until the end of the command line or until you specify another binding mode. Because you can specify binding mode more than once with the load command, you can use the shared version of some libraries and the static version of others. In the following example, the static library One (libOne.a) is loaded, and the shared library Two (libTwo.so) is loaded: -> load -Bstatic -lOne -Bdynamic -lTwo |
|||
Loading the Static Version of the C Library |
CodeCenter automatically loads the C library when starting. By default, it loads the shared version. You can force CodeCenter to load the static version (libc.a) by setting the environment variable LD_OPTIONS to the value -Bstatic before starting CodeCenter. That causes CodeCenter to load the static versions of all libraries by default. Alternatively, you can unload the shared libraries (using unload), then explicitly load the static versions by specifying their pathnames with the load command. When you load a library, CodeCenter automatically loads any other libraries that the library references. Unloading the first library unloads only that first library, not anyof the libraries that were referenced by it. To unload the other libraries, you must unload them explicitly. |
|||
Setting Breakpoints in Shared Libraries while in PDM |
While you are in pdm, you can set a breakpoint in a C library function, such as printf(). To do so, you first set a breakpoint in main(), issue the run command, set the breakpoint in printf(), and issue the cont command: pdm -> stop in printf Function "printf" not defined. pdm -> stop in main stop (1) set at "main.c:8, main()". pdm -> run Resetting to top level. Executing: /test_dir/a.out Breakpoint 1, main (argc=1, argv=0xf7fff824) at main.c:8 pdm (break 1) -> stop in printf stop (2) set at 0xf76ed904, printf(). pdm (break 1) -> cont Breakpoint 2, 0xf76ed904 in printf() pdm (break 1) -> You have set the breakpoint in this fashion only once; subsequent runs of the program retain the breakpoint in printf(): pdm 14 -> run Resetting to top level. Executing: /test_dir/a.out Breakpoint 1, main (argc=1, argv=0xf7fff824) at main.c:8 pdm (break 1) 15 -> cont Breakpoint 2, 0xf76ed904 in printf() |
|||
Binding of Functions and Data |
Like the Sun dynamic linker/loader, ld.so, CodeCenter binds functions from shared libraries at run time when the functions are called. Note that, if you have loaded the definition of a function in your own source or object file, it takes precedence over a definition of that function in a shared library. On SunOS (Solaris 1), CodeCenter binds a library's exported initialized data (usually found in the .sa file) at link time, not at run time (similar to ld's statically linking an .sa file at link time). |
|||
Unloading a Specific Function |
If you specify a function in a shared library with unload, CodeCenter unloads the entire .so file. -> unload printfOn SunOS (Solaris 1), CodeCenter does not unload the .sa file. |
|||
Other SunOS (Solaris 1) Differences |
NOTE : The rest of the section on shared libraries applies only to SunOS (Solaris 1). |
|||
Unloading Shared Objects |
You can unload and unlink an entire shared library at once. -> unload -lX11 |
|||
Unloading a Specific Module |
You can also unload specific modules in a data interface description file (.sa) by specifying the module in parentheses following the library name: -> unload /lib/libc.sa.1.6(errlst.o) |
|||
Using Initialized Global Data |
If you declare initialized global data in a program using SunOS (Solaris 1) shared libraries, you should include its initialization in your .sa archive, as well as in you .so file. If you don't, your program might not use the correct initialization values. The problem results from behavior of Sun's linker, ld, which can only find initializations of data in the user's program or in an archive (.a or .sa file) - not in .so files. When ld can't find the initialization for a variable, the system initializes the variable to 0 (zero). This issue can come up if you use common variables in C programs. Common variables are global variables that are defined in more than one module without using the extern qualifier. Consider this simple C example with two files, a.c and b.c:
In this example, Dogs is a common variable. It is declared in two modules, namely a.c and b.c, without using the extern qualifier. Here's what happens when we compile the example statically: % cc -c a.cThe program runs fine. But suppose the code from b.c is in a shared library without an .sa archive. When we link the code, it runs incorrectly: % ld -o libb.so.1.0 b.o -assert pure-textThe linker erroneously initialized the variable Dogs to 0 (zero). The solution is to create an .sa file containing the static data in b.c: % ar r libb.sa.1.0 b.oNow the program runs correctly. Notice that in this situation you must initialize data in the .sa file; otherwise, the statically linked program runs differently from the dynamically linked one. As good practice, you should probably always include initializations in your .sa files, even if the static variable is initialized to zero. This results in better shared-library performance. |
|||
Using HP Shared Libraries |
This section describes the support for shared libraries within the CodeCenter environment. For general information about HP shared libraries, see the HP Manual, "Programming on HP-UX". Reading debugging information on shared libraries is not supported in component debugging mode (CDM, a.k.a. CodeCenter's interpreter). Without debugging information on a file, you are unable to perform certain debugging activities, such as stepping through functions. For information about what debugging techniques are possible on code without debugging information, see the debugging entry in the Manual Browser or "CodeCenter Reference Manual". CodeCenter supports source-level debugging of shared libraries in process debugging mode (pdm). For example, you can step into functions in shared libraries that were compiled with -g. Once you load a shared library into CodeCenter, its functions and any of its data that you have exported are available to your program. CodeCenter mimics the behavior of the system's link editors in loading shared libraries and binding functions and data, as described below. |
|||
Loading Shared Libraries |
To load a shared library, use the CodeCenter load command. For example, to load the math library, enter the following: -> load -lmTo unload a shared library, use the CodeCenter unload command. For example, to unload the math library, enter the following: -> unload -lmYou can also use the load and unload commands to load and unload libraries with relative or absolute pathnames. |
|||
Search Rules for Loading Libraries |
When you load a library using the load command's -l switch. CodeCenter searches for libraries in its search path in the same way that the HP ld command does. CodeCenter stops searching as soon as it finds either the shared or archive version of the library. If it finds both versions in the same directory, CodeCenter uses the shared version (.sl file) by default. You can, however, change the default search path by specifying the -Ldir command-line switch. The -Ldir swtich to ld allows you to add additional directories to the search path. If -Ldir is specified, ld searches the dir directory before the default places. The linker searches libraries in the order in which they are loaded. Libraries specified with the -l switch are searched before the libraries that the compiler links in by default. CodeCenter links in the standard library libc and /lib/milli.a last. You can also specifically tell ld which libraries to search by setting the LPATH environment variable. If LPATH is not set, ld searches only the libraries specified in LPATH; the default libraries are not searched unless they are specified in LPATH. |
|||
Loading the Archive Version of a Library |
If both archive and shared versions of a library reside in the same directory, CodeCenter loads the shared version by default. You can force CodeCenter to load the archive version of the library with the -a search command-line switch; where search can be one of the following: archive (use the archive version only), shared (use the shared version only), or default (use the shared version if available; otherwise use the archive version). If the specified version of the library cannot be found, CodeCenter reports an error. The following is an example of using the -a archive switch to load an archived version of the math library: -> load -a archive -lmThe following is an example of using multiple -a switches on the same load command: -> load -a archive -lm -a shared -lM |
|||
Specifying Global ld Switches with LDOPTS |
CodeCenter supports the HP environment variable, LDOPTS, which allows you to specify your ld switches in an environment variable. The linker picks up the value of LDOPTS and places its contents before any arguments on the command line. NOTE : You must set the LDOPTS and all other environment variables in a shell before starting up CodeCenter in that shell. |
|||
Binding of Functions and Data |
The default behavior of the HP dynamic linker/loader, dld.sl, binds functions from shared libraries at run time when functions are called. Note that, if you have loaded the definition of a function in your own source or object file, it takes precedence over a definition of that function in a shared library. CodeCenter binds a library's exported initialized data at link time, not at run time. |
|||
Unloading a Specific Function |
If you specify a function in a shared library with , CodeCenter unloads the entire .sl file. |
|||
Shared Library Stack Frames in Core Files |
pdm is currently unable to report about shared library stack frames when statically analyzing core files. Instead, the output will look something like this: Core was generated by 'a.out'.In order to get an accurate stack trace, reproduce the fault within pdm. pdm 1 -> run |
|||
Calls to shl_*(3X) Functions |
This section documents the behavior of shl_*(3X) functions when you call them within CodeCenter. These functions are available only on the HP 9000 Series 700 and Series 800 platforms. shl_definesym(3X) always returns -1 and sets errno to EINVAL. CodeCenter is unable to accurately reproduce the semantics of shl_definesym(3X), so it is not supported. shl_load(3X) and cxxshl_load(3X) always interpret the BIND_IMMEDIATE modifier flag as if it were BIND_DEFERRED. It is impossible to obtain BIND_IMMEDIATE semantics from shl_load(3X) and cxxshl_load(3X) within the CodeCenter environment. Loading a library with the BIND_FIRST modifier flag to shl_load(3X) or cxxshl_load(3X) will cause that library to be assigned an index of 1 (see the shl_get(3X) manual pages for a description of a library's index). By contrast, loading a library outside of the CodeCenter environment will cause that library to be assigned an index of 0 (zero). Therefore, an index of 0 (zero) always represents the user's main program within the CodeCenter environment. When the DYNAMIC_PATH flag is passed to shl_load(3X) or cxxshl_load(3X), those functions use only the path list stored in the SHLIB_PATH environment variable to find the library. This is because there is no way to emulate the +s and +b options to ld(1) within the CodeCenter environment. CodeCenter unloads all dynamically loaded libraries when a reset to top level occurs. shl_unload(3X) and cxxshl_unload(3X) do not actually unload the library, and thus do not unbind any symbols that have been bound from that library. Unloading and relocating a library with shl_*(3X) functions will not cause them to return an error status, but the original image of the library is the only one that is ever loaded during a single run of the user program. The value of the HP-UX reserved variable, __dld_loc is always 0x0 within CodeCenter. It should not be used by a user program. C++ static constructors and destructors in shared libraries are always invoked, even if the user program does not use the C++-aware dynamic loading functions, cxxshl_load(3X) and cxxshl_unload(3X). CodeCenter does not call initializer functions in a shared library at any time. Note that intializer functions in HP-UX shared libraries are not C++ static intializers, which CodeCenter supports. Initializer functions are language-independent functions defined at shared-library-creation time with the +I option to ld(1). The initializer member of struct shl_descriptor objects generated by shl_get(3X) and shl_gethandle(3X) always have the following value: NO_INITIALIZER. shl_get(3X) will return -1 (with errono == EINVAL) if it is passed an index with the value -1 or 0 (zero). This is because there is no distinct dynamic linker (index -1) or main program executable (index 0) within the CodeCenter environment. shl_gethandle(3X) will return -1 (with errno == EINVAL) if it is passed the handle PROG_HANDLE. This is because there is no distinct main program executable (index 0) within the CodeCenter environment. shl_getsymbols(3X) behaves as if every defining instance of a symbol with external linkage in the user's program is exported from the main program. These symbols are accessed by passing PROG_HANDLE as the first argument to shl_getsymbols(3X). Outside of the CodeCenter environment, this behavior is achieved by using the -E switch to ld(1) when creating the main program. The GLOBAL_VALUES and IMPORT_SYMBOLS modifier flags are not supported for calls to shl_getsymbols(3X). Calls to shl_getsymbols(3X) will return -1 with errno set to EINVAL if either of these flags is passed in. |
|||
Potential SUN Anomalies |
In most cases, your programs will run the same within the CodeCenter environment as they do outside the environment. However, there are some platform-specific features that CodeCenter may not support fully, so you may see unexpected behavior. This section attempts to call your attention to these potential anomalies on Sun platforms. Unless otherwise specified, these anomalies apply to both SunOS (Solaris 1) and Solaris 2. |
|||
Default Parser Configuration |
The default C parser configuration for the CodeCenter interpreter (CDM) is K&R. Invoke the config_parser command to display the current setting. For more information about specifying a different parser configuration, see the config_parser entry in the CodeCenter Reference. |
|||
Sun C Compilers and pdm |
On Solaris 2, when you try to debug and executable compiled with SunPro C compiler Version 2.0.1 (or higher) or with SPARCompiler C Version 3.0.1 (or higher), pdm may report that no debugging symbols were found. This is because the Sun compiler puts the debugging information that pdm uses in the .stab.excl section of the executable, which is stripped by the static linker during final execution. To work around this problem, compile with the -xs switch. This causes the assembler to place debugging information in the .stabs section, which is not stripped by the linker. |
|||
Switches and Variables Ignored by load (SunOS/Solaris 1) |
In SunOS (Solaris 1), CodeCenter's load command ignores some command-line switches that are accepted by Sun cc, but many of these switches do not change the meaning onf a program. The following Sun cc command-line switches ignored by CodeCenter do change the meaning of a program.
The load command also ignores the FLOAT_OPTION environment variable that is accepted by Sun cc, which does change the meaning of a program. CodeCenter does not support object files created using the Sun cc compiler -dalign switch. This switch causes more stringent alignment rules for storing double-precision values in memory. Calling object code functions compiled with -dalign from source code could result in a segmentation violation. However, you can load your whole application as object code without problems. |
|||
Setting LD_LIBRARY_PATH |
To use the CodeCenter tutorial on Solaris 2 platforms, you must set the following environment variables: setenv OPENWINHOME /usr/openwin On Solaris 2, the linker only checks for major numbers. Some components of CodeCenter, for example the vi integration, require the library libX11.so.4. If CodeCenter issues an error message such as "cannot find libX11.so.4", make sure that /usr/openwin/lib contains a symbolic link called libX11.so.4 pointing to a libX11.so.4.x or libX11.so.5.x library. |
|||
Locating X11 Header Files |
The tutorial assumes the X11 header files are installed in /usr/include. If they are not, contact your system administrator to put a copy or symbolic link to the location of the X11 header files into /usr/include, or add -Ipathname to the CL_INCS link in the tutorial Makefile, where pathname is the path to the directory containing the X11 header files. If you use the X11R5 libraries instead of the openwin libraries, you must explicitly load -lnsl and -lsocket into the Workspace to run the tutorial. These dependencies are not automatically included in the X11R5 libraries, whereas they are included in the openwin libraries. |
|||
Resource Limits for Stacksize |
If a user has set the stacksize resource to unlimited, it may affect CodeCenter's pdm when debugging an executable. At run time, if the application being debugged within pdm experiences a run time error (such as a segmentation fault), CodeCenter may not display any relevant error information in the Workspace. Essentially, no source file information is displayed, including the line of code where CodeCenter stopped execution and where the problem may be occurring. The user will only understand that a problem has occurred and that execution of the program has stopped, but not have much to go on to resolve the problem. Using the CodeCenter tutorial as an example, we can see how this problem takes effect. After running the bounce_dump application in CodeCenter's pdm, the user may see the following output if the stacksize resource has been set to unlimited: pdm -> debug bounce_dump core As you can see, the user would only understand that a runtime error had occurred in the function called 'store_shape', but not the line number at which the problem occurred. This is a problem that occurs on both SunOS (Solaris 1) and Solaris 2 systems. The error resulting may be slightly different, but the problem is essentially the same. To avoid this problem, quit out of CodeCenter and then at the Unix prompt set the "soft limit" of the stacksize resource to 2048 as follows:< % limit stacksize 2048 Then restart the pdm session. The user should now obtain the proper run time error information they had originally expected. Going back to the CodeCenter tutorial example, the above messages change to the following once the stacksize resource limit is changed to 2048: pdm -> debug bounce_dump core You can see how the output changes to what is depicted within the CodeCenter tutorial manual, giving the user more details on the problem. Additionally, at run time of an application, the Source Area is able to display the source code and a pointer to the line number where execution stopped and where the error is occurring. There is no explanation at this time as to why the stacksize resource and the soft limit setting established for this resource affects CodeCenter. However, if this resource is set to unlimited or pretty much anything higher than 2048, the problem described above could occur. To find out more about "soft limits" and the other resources that can have a limitation placed on them, see the man pages for the limit (or ulimit) command or talk to your system administrator, who can adjust the system resource limitations for your login account as necessary. |
|||
Potential HP Anomalies |
In most cases, your programs will run the same within the CodeCenter environment as they do outside the environment. However, there are some platform-specific features that CodeCenter may not support fully, so you may see unexpected behavior. This section attempts to call your attention to these potential anomalies. |
|||
Default Parser Configuration |
The default C parser configuration for the CodeCenter interpreter is K&R. Invoke the config_parser command to display the current setting. For more information about specifying a different parser configuration, see the config_parser entry in the CodeCenter Reference. |
|||
Supported cc and c89 Switches |
CodeCenter's load command supports the following switches to the HP c89(1) and cc(1) commands:
|
|||
Supported ld Switches |
CodeCenter's load command supports the following switches to the HP ld(1) command:
All other switches are ignored. |
|||
Different Behavior of the load Command |
CodeCenter processes all -L switches before processing any -l switches. Thus, the command: -> load -lm -L./subdirloads the library ./subdir/libm.a instead of /lib/libm.a (presuming both libraries exist). HP's ld(1) command processes all command-line switches in left-to-right order, so this behavior is unexpected. |
|||
Unsupported Environment Variables |
Currently, CodeCenter's load command ignores these HP-UX environment variables:
|
|||
No PIC Support |
The CodeCenter dynamic linker/loader does not support object modules containing Position Independent Code (PIC) on the HP platform. |
|||
No Support for Cache Hint Bits |
The CodeCenter dynamic linker/loader does not detect and eliminate use of cache hint bits in object modules in situations where 64-byte stack pointer alignment cannot be guaranteed. |
|||
void Types may be Misinterpreted |
Due to an HP compiler bug, objects of base type void can sometimes appear to have the base type of int when their definitions are loaded in object form. |
|||
No Support for Long Pointers |
The CodeCenter interpreter does not support long pointer declaration syntax (for example, "int ^x;"). |
|||
No Support for Argument Values in Intrinsics |
The CodeCenter interpreter does not support default argument values in calls to intrinsics. |
|||
CodeCenter Replaces Fewer Header Files |
We provide fewer header files on the HP platform than we do for some other platforms because more HP header files comply with the ANSI standard. |
|||
Changes in Signal Handling |
If your program makes use of either signal() in libBSD.a or sigpause() in libV3.a, load the appropriate library before the program in linked or run for the first time in a session; otherwise, the libc.a version will be used. After a program is linked or run for the first time in a session, you cannot subsequently change the version of signal() or sigpause() that your program uses. Therefore, if you link or run without first loading the appropriate library, you must exit CodeCenter and restart it. To avoid this problem, add one of the following lines to your personal .ccenterinit file or to the system-wide ccenterinit file:
|
|||
sigvec() and sigvector() Flags |
The SV_ONSTACK and SV_NOCLDSTOP flags to sigvec() and sigvector() are ignored. (This behavior with SV_ONSTACK is the same as on other architectures supported by CodeCenter; however, the behavior with SV_NOCLDSTOP is specific to HP-UX). The SV_BSDSIG flag used in sigvector() has no effect (that is, the sigvector() function always acts as if the SV_BSDSIG flag is set). The SV_BSDSIG flag is not returned in the old sigvec structure, even if it was set by the caller. |
|||
sigaction() Flags Ignored |
The SA_ONSTACK and SA_NOCLDSTOP flags to sigaction() are ignored. |
|||
No sigspace() and No sigstack() |
The sigspace() and sigstack() functions are not supported. |
|||
_longjmp() and _setjmp() |
The _longjmp() and _setjmp() functions behave like longjmp() and setjmp(). |
|||
Enhanced sigset() and sigvector() |
Signal handler maintenance functions which are incompatible under HP-UX (such as sigset() and sigvector()) work correctly with each other under CodeCenter. |
|||
syscall() Function |
The function syscall() is unsupported in HP-UX 9.xx and possibly HP-UX 10.x. Calling this unsupported function can result in unexpected behavior. |
|||
ioctl() Support |
CodeCenter supports user programs that make IPMAPMAP and IPMAPUNMAP ioctl() requests. There is one restriction. The restriction is that CodeCenter considers a memory area invalid if your program maps it with IPMAPMAP and unmaps it with close() or ioctl(). This is the case even if close() or ioctl() did not actually unmap the area because other processes on the system still had it mapped. A subsequent IOMAPMAP ioctl() request for that memory area causes CodeCenter to again consider it valid. |
|||
Static Symbol not in symtab |
On the HP platform, pdm may issue the following warning: Internal: static symbol 'symname' found in filename psymtab but not in symtab If you receive this message, issue the following command: whatisand then reissue the command that caused the warning. |
|||
Attaching to a Running Process may Fail on HP-UX |
Attaching to a running process sometimes fails on HP-UX in CodeCenter's process debugging mode (pdm) if the pdm binary you are using is installed on a remote partition. The failure looks like a ptrace failure, such as one you get if you request an illegal process number or if you attempt to attach a file you do not own. pdm -> debug a.outBefore implementing the workaround we provide below, eliminate any possibility that the failure is a result of a ptrace error. See the ptrace man page for information about ptrace failure errors. This is the workaround:
The .clpm.conf file should contain the following lines:
AS PDM {
BINARY: /tmp/pdm;
BINARY_ENV: CLDB;
ENV:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$(centerline)/$(arch)/lib;
ARGS: -connect;
RESTART_ARGS: -connect -restart;
ARG_TMPL: ^[^-].*:0;
}
With the workaround, attempts to attach to a running process will now succeed: pdm 1 -> debug a.out pid Attaching to a process may also fail if the process is sleeping. pdm cannot attach to a sleeping process. For more information about attaching to a running process, see the debug entry in the Manual Browser or CodeCenter Reference. |
|||
clcc Command-Line Switches |
Many of the switches used with the HP C compiler are also used with clcc, the CenterLine-C compiler. However, some switches you use with cc must be replaced by a corresponding clcc switch, and other cc switches have no equivalent in clcc. The following table shows some common cc switches and their clcc equivalents.
_____________________________________________________________
| |
HP cc Switch | clcc Switch | Description
________________|_________________|__________________________
| |
-Aa | -ansi | Enables strict ANSI
| | compliance.
| |
-Ac | -traditional, | Disables strict ANSI C
| -Xa, or -Xt | compliance. Please refer
| | to the descriptions of
| | these switches in the
| | CenterLine-C
| | Programmer's Guide
| | or the clcc manual page
| | for more information.
| |
-G | -pg | Inserts information
| | required by the gprof
| | profiler in the object
| | file.
| |
-Wx,arg1[,arg2, | -Hcppopt=string | Pass argument string to
...,argn] | -Hldopt=string | preprocessor (-Hcppopt)
| | or the linker (-Hldopt).
| | 'string' can contain
| | multiple arguments
| | separated by commas.
| |
+L | -Hlist | Generates a source
| | listing on standard
| | output.
| |
+On | -On | Sets the optimization
| | level to 'n' where 'n'
| | is 1 to 7. If 'n' is not
| | specified, then a level
| | of 2 is used.
| |
+wn | -wn | Suppress warning
| | messages at level 'n'
| | and higher where 'n'
| | is 1 to 4.
| |
+z | -pic | Produces position-
| | independent code. The
| | The memory allocated
| | to static variables
| | cannot exceed 4K.
| |
+Z | -PIC | Like -pic, but allows
| | the global offset table
| | to span the range of
| | 32-bit addresses when
| | there are too many
| | global objects for -pic.
________________|_________________|__________________________
|
|||