Contents

1. Introduction
2. About Forte Developer 7 dbx
3. New and Changed Features
4. Software Corrections
5. Problems and Workarounds
6. Limitations and Incompatibilities
7. Documentation Errors

 

 

---

A. Introduction

This document contains information about the Forte[tm] Developer 7 dbx. This document describes the new features that are included with this release, software software corrections that are addressed by this release, and lists known problems, limitations, and incompatibilities. Information in this document overrides information in the manuals for this release.

Information in the release notes updates and extends information in all readme files. To access the release notes and the complete Forte Developer documentation set, go to the documentation index at file:/opt/SUNWspro/docs/index.html.

To view the text version of this readme, type the following at a command prompt:

   more /opt/SUNWspro/READMEs/dbx

To view the HTML version of this readme, go to:

   file:/opt/SUNWspro/docs/index.html

Note - If your Forte Developer 7 software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.

 

---

B. About Forte Developer 7 dbx

dbx is an interactive, source-level, command-line debugging tool. You can use it to run a program in a controlled manner and to inspect the state of a stopped program. dbx gives you complete control of the dynamic execution of a program, including the collection of performance data. This release of dbx is available on the Solaris[tm] operating environment (SPARC[tm] Platform Edition) versions 7, 8, and 9.

 

---

C. New and Changed Features

This section describes the new and changed features for dbx. For information about other Forte Developer components, see the What's New manual. To access this manual on your local system or network, go to file:/opt/SUNWspro/docs/index.html. You can also access this manual by going to http://docs.sun.com.

• dbx can now debug mixed Java and native code (C and C++) running under the Solaris operating environment. Using dbx you can debug:
  • A file with a file name ending in .jar
  • A file with a file name ending in .class
  • A Java application that is started using a wrapper
  • A running Java application to which you attach dbx
  • A C/C++ application that embeds a Java application

  Most dbx commands operate similarly on native code and Java code.

• The following changes have been made to the dbx collector command:
  • An approximate limit to the amount of data collected can be set.
  • Address space data collection is no longer supported.
  • The command includes subcommands to record a sample and to control whether dbx records a sample when it stops the target process.

• The following dbx environment variables have been removed:
  • allow_critical_exclusion
  • aout_cache_size
  • locache_enable
  • delay_xs

  The allow_critical_exclusion variable allowed exclusion of certain shared libraries. It is replaced by functionality in the new loadobject command.

  The aout_cache_size and locache_enable variables were used to control when dbx discards symbolic information from programs and shared libraries. The default behavior is now unchangeable. dbx discards symbolic information from an executable when it begins debugging a new executable, and libraries are reused until they are updated on disk, or until the dbx session is terminated.

  The delay_xs variable was used to disable the demand-loading of symbolic information from programs and shared libraries compiled with the -xs flag, and force all the information to be loaded at once. Demand loading is now on all the time.

• The old loadobject command and loadobjects command have been replaced with a new loadobject command to control and list the symbols loaded by dbx.

• The default dbx prompt is now the last path component of argv[0] instead of the entire string in argv[0].

 

---

D. Software Corrections

1. Detaching From an Attached Process in dbx Before Closing Experiment No Longer Causes Hang
2. Fixing, Then Reloading, Fixing, and Running No Longer Causes dbx to Dump Core
3. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in Solaris 8 Operating Environment Signal
4. Can Now Interrupt Printing of a Very Large Data Structure

1. Detaching From an Attached Process in dbx Before Closing Experiment No Longer Causes Hang (4456506)

   Due to a bug in dbx, if you attached dbx to a process, enabled data collection (using collector enable), and then tried to detach from the process before disabling data collection, dbx unloaded the collector library, failed to close the experiment, failed to detach from the process, and could not complete any more commands. dbx now performs correctly in this situation.

2. Fixing, Then Reloading, Fixing, and Running No Longer Causes dbx to Dump Core (4459339)

   If you used a fix command on program foo, then reloaded the original binary, and issued a fix command and a run command, dbx dumped core. dbx now performs correctly in this situation.

3. Multithreaded C++ Programs Using Alternate Threads No Longer Hang When Debugged in Solaris 8 Operating Environment (4432577)

   Multithreaded C++ programs built with alternate threads used to hang when you attempted to debug them in the Solaris 8 operating environment. 32-bit multithreaded C++ programs built with the -R /usr/lib/lwp compiler option used to hang when run within dbx. 64-bit multithreaded C++ programs built with the -R /usr/lib/lwp/sparcv9 compiler option were likely to hang, especially when runtime checking was used.

   This symptom occurred with C++ code compiled in standard (default) mode (with the -compat=5 compiler option); it did not occur with code compiled in compatibility mode (with the -compat=4 compiler option).

4. Can Now Interrupt Printing of a Very Large Data Structure (4474492)

   Forte Developer 6 update 2 dbx was very slow in printing a large data structure. In Forte Developer 7 dbx such printing is faster, and you can interrupt a print operation.

 

---

E. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates, check Forte Developer Hot Product News at http://www.sun.com/forte/fcc/hotnews.html.

1. dbx Can't Print the Template Parameter of a Type With No Name
2. Monitoring a Local Variable May Cause Termination With a SIGKILL Signal
3. thread -blocks Command Does Not Work
4. Data Collection Problems When dbx is Attached to a Process
5. Runtime Checking Does Not Work With -xcheck = stkovf

1. dbx Can't Print the Template Parameter of a Type With No Name (4058205)

   dbx can't print the template parameter of a type with no name.

2. Monitoring a Local Variable May Cause Termination With a SIGKILL Signal (4292103)

   On SPARC platforms running the Solaris 7 operating environment, monitoring a local variable by setting an On Modify breakpoint (stop modify) may cause dbx to terminate with a SIGKILL signal or to hang. This problem does not occur on SPARC platforms running the Solaris 8 operating environment or on Intel platforms.

3. thread -blocks and thread -syncs Commands Do Not Work (4307236)

   The thread -blocks command and thread -syncs commands do not work properly in some configurations due to bugs in the Solaris operating environment. The bad configuration is the Solaris 7 operating environment running a 64-bit kernel when you are debugging a 32-bit application.

4. Data Collection Problems When dbx is Attached to a Process

   If you attach dbx to a running process without preloading the collector library, libcollector.so, a number of errors can occur.

   • You cannot collect any tracing data: synchronization wait tracing, heap tracing, or MPI tracing. Tracing data is collected by interposing on various libraries, and if libcollector.so is not preloaded, the interposition cannot be done.
   • If the program installs a signal handler after dbx is attached to the process, and the signal handler does not pass on the SIGPROF and SIGEMT signals, profiling data and sampling data is lost. (4397578)
   • If the program uses the asynchronous I/O library, libaio.so, clock-based profiling data and sampling data is lost, because libaio.so uses SIGPROF for asynchronous cancel operations.
   • If the program uses the hardware counter library, libcpc.so, hardware-counter overflow profiling experiments are corrupted because both the collector and the program are using the library. If the hardware counter library is loaded after dbx is attached to the process, the hardware-counter experiment can succeed provided references to the libcpclibrary functions are resolved by a general search rather than a search in libcpc.so.
   • If the program calls setitimer(2), clock-based profiling experiments can be corrupted because both the collector and the program are using the timer.

5. Runtime Checking Does Not Work With -xcheck = stkovf

   Runtime checking does not work if you specify -xcheck = stkovf. You receive a rua (Read From Unallocated Memory) error.

 

---

F. Limitations and Incompatibilities

Forte Developer 7 dbx has the following limitations:

• It is not possible to attach to a running process from your .dbxrc file. A .dbxrc file should not contain commands that execute your code. However, you can put such commands in a file, and then use the dbx source command to execute the commands in that file.
• dbx incorrectly demangles pointer to member functions for compat=4. This is not a problem for compat=5.

  Workaround: Recompile your program with:

  CC -compat=4 -Qoption ccfe -abiopt=pmfun1
  

  This flag introduces an ABI change and should not be used in production builds.
• On V9/V9 systems, stack traces that pass through code compiled with both the -g and -O options provide inaccurate results if the arguments are NOT integral types. Printing of float parameters in such functions may display the following error message:

  RegSet::getd('o1'): cannot -- will return 0.0
  

  Workaround: Use -g only.

• On V9/V9 systems, use of the call command or printing function calls is not working with nested small structure as an argument or as a return value.
• Using older copies of libC.so.5 or libC.so.4 may cause problems for dbx in the area of C++ exceptions. Warning messages about bad stabs and unhandled exceptions may result.

  Workaround: Link libC statically or install the latest libC.so.5 on all systems.

  libC.so.5 is available as a SUNWlibC patch, one for each version of the Solaris operating environment and for each architecture, in your Forte Developer 7 download or from http://sunsolve.sun.com. For the patch number for your version of the Solaris operating environment and your system architecture, see the Forte Developer 7: Forte Compiler Collection Release Notes, accessible through the documentation index on the Forte Developer 7 web site at http://www.sun.com/forte/fcc/documentation.

•  Fortran users should compile with the -stackvar option to take full advantage of runtime checking.

  Some programs may not work properly with -stackvar. In such cases, try the -C compiler option, which will turn on array subscript checking without RTC.

•  Follow fork may be unreliable for multithreaded applications.
•  Use of the call command or printing function calls may cause deadlock situations with multithreaded applications.

The following incompatibilities exist between dbx 7.0 and dbx 6.0:

•  The dbx environment variable rtc_use_traps has been removed. Traps are used automatically as long as the hardware is UltraSPARC.
•  Fortran intrinsics support on Intel platforms has been removed.
•  The dbx environment variables allow_critical_exclusion, aout_cache_size, and locache_enable have been removed. For more information, see New and Changed Features.
•  The dbx environment variable cfront_demangling has been removed. The -F option to the dbx command (allow cfront demangling) has also been removed. Use an earlier version of dbx to get cfront support.
•  Subcommands have been removed from and added to the collector command. For more information, see New and Changed Features.
•  The old loadobject command and loadobjects command have been replaced with a new loadobject command to control and list the symbols loaded by dbx.
•  The default dbx prompt is now the last path component of argv[0] instead of the entire string in argv[0].

---

G. Documentation Errata

There is no new information at this time. 

 

---

Copyright © 2002 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.