------------------------------------------------------------------------ Compaq Ladebug for Compaq Tru64 UNIX Systems Release Notes for Version 69 ------------------------------------------------------------------------ 1 Introduction Compaq Ladebug for Compaq Tru64 UNIX Systems is a fully symbolic debugger with graphical user interface (GUI) for the Compaq Tru64 UNIX platform. Key features of Ladebug allow you to: * Perform source-level debugging * Attach to a running process * Debug programs with shared libraries * Debug multithreaded applications * Debug multiprocess applications, including programs that fork and exec * Perform remote client/server debugging of kernel code * Perform kernel debugging * Provide I18N support for local language characters Ladebug supports the debugging of programs written in C, C++, Fortran, Fortran 90, Ada and COBOL. Ladebug features expression evaluation using the syntax of the source programming language. For full information about the Ladebug debugger, please refer to the following manual: Compaq Tru64 UNIX: Ladebug Debugger Manual These release notes are broken down into the following subsections: * 1 Introduction * 2 New Features * 3 Known Problems * 4 Reporting Problems * 5 Problems fixed ------------------------------------------------------------------------ 2 New Features * Internationalization * New features for Version 69 o Bug Fixes * New features for Version 68 o Bug Fixes * New features for Version 67 o C/C++ comma operator support o Support for single quoted characters in whereis o Debug of massively parallel programs * New features for Version 66 o Loading of .o files and kernel binaries o Enhanced memory search o Regular expression search of the symbol table o Initial support for universal character names (UCNs) in identifiers o GUI Improvements * New features for Version 65 o Background and Cautions o if command o Various print commands o New debugger variables for supporting dbx compatibility o Improved remote kernel debugging performance * New features for Version 4.0-64 o Background and Cautions o Older Linux platforms no longer supported o New debugger control variable $floatshrinking o Support for the printing of NUMA distributed Fortran arrays * New features for Version 4.0-63 o Background and Cautions o New processing of comment character '#' o Support for anonymous structures in BLISS o More support for external symbols on Linux * New features for Version 4.0-62 o Background and Cautions o Support for Fortran 90 intrinsic procedures o New debugger variable $cursrcpc o New command line flag -interactive * New features for Version 4.0-61 o Background and Cautions o New meaning for px alias o Display of bitfields in registers o New command unrecord o Improved handling of C++ interludes o Improved handling of C++ downcasts o Pick-lists for multiple files o The debugBreak function o Improvements to performance o Miscellaneous improvements o GUI Improvements * New features for Version 4.0-59 o Background and Cautions o New debugger control variable $lasteventmade o New command option -V * New features for Version 4.0-58 o Background and Cautions o Logical Data Type Support in Fortran * New features for Version 4.0-57 o Background and Cautions o New Graphical User Interface o New Command-- edit o New Predefined Aliases-- printd, printo, and printx o New Debugger Variable-- $curfilepath o Better Fortran Support o Shell-like Treatment on run/rerun Arguments o Comprehensive Diagnostic Message when Ladebug Cannot Find a Source File * New features for Version 4.0-56 o Background and Cautions o More dbx Friendly Features * New features for Version 4.0-55 o Background and Cautions o Support for Reflexes o Support for Source Directory Mappings o More Debugger Variables for Customizing the Look of Ladebug o The Old GUI dxladebug Is Dropped from the Kit * New features for Version 4.0-54 o Background and Cautions o New debugger variable $funcsig o Additional support for Fortran dynamic arrays o New Graphical User Interface incorporated into Ladebug image o Support for Extended Source Line Information * New features for Version 4.0-52 & 4.0-52gui o Background and Cautions o New Graphical User Interface (4.0-52gui only) o Attaching to a process without specifying an image name o New dbx-compatible commands: + cont + conti to o New debugger variables: + $dbxuse + $curprocess + $dbxoutputformat + $statusargs + $doverbosehelp o Improved behavior of the record command o Support for debugging optimized code that has discontiguous scopes * New features for Version 4.0-51 o Background and Cautions * New features for Version 4.0-50 o Background and Cautions * New features for Version 4.0-49 o Background and Cautions * New features for Version 4.0-48 o Background and Cautions o snapshot functionality o Support for debugging compressed files o Support for split lifetime local variables o Support for static links o Ladebug now linked against libcxx.a o Better handling of recursive functions o thread command now accepts an expression o Modified output for listobj command o Modified name lookup o More information from where command o Optionally mmap a loaded file * New features for Version 4.0-47 o Background and Cautions o Requirements o Support for C++ "using" declarations o Better symbolization o More information from "which" command * New features for Version 4.0-46 o Background and Cautions o Requirements o Limited support for C++ Namespaces o More support for C++ Templates o Output pagination support * New features for Version 4.0-44 o Dynamic type member access o watch variable functionality o Using line numbers in expressions is now supported o Remote debugging on DIGITAL UNIX v3.2 is working * New features for Version 4.0-43 o Command line interface support for editing lines which are longer than the screen width o Remote debugging is available on DIGITAL UNIX v4.0 Problems fixed in this and previous releases of the Ladebug Debugger are discussed in detail in Problems Fixed (section 5). ------------------------------------------------------------------------ 2.1 Internationalization The "internationalized" version of the debugger is now available in all kits of the Version 4.0-24 and later debuggers. It is no longer necessary to install the special IOSLDBxxx subsets of the debugger software to achieve localization to other language locales. The IOSLDBxxx subsets are no longer shipped with Digital UNIX V4.0C and later releases. ------------------------------------------------------------------------ New features for Version 69 * Bug Fixes Bug Fixes There are no new features in this version of Ladebug. This is simply a bug fix release. ------------------------------------------------------------------------ New features for Version 68 * Bug Fixes Bug Fixes There are no new features in this version of Ladebug. This is simply a bug fix release. ------------------------------------------------------------------------ New features for Version 67 * C/C++ comma operator support * Support for single quoted characters in whereis * Debug of massively parallel programs C/C++ comma operator support Ladebug now supports the comma operator in C and C++. Since the Ladebug command language uses comma in a different way, it is necessary to use parentheses to print an expression using the C or C++ comma: (ladebug) p 1,2 # Ladebug comma 1 2 (ladebug) p (3,4) # C or C++ comma 4 (ladebug) p (1,2),(3,4) # Both kinds of commas 2 4 Support for single quoted characters in whereis The regular-expression form of the "whereis" command can now take single-quoted characters surrounding the operand. For example: (ladebug) whereis 'x' will get the same result as the following (which is already supported): (ladebug) whereis "x" Debug of massively parallel programs With V67, Ladebug now supports debugging massively parallel programs using prun, dmpirun or mpirun. See the manual's chapter 19 , "Debugging Parallel Applications" for details (be patient, the manual may take some time to load). ------------------------------------------------------------------------ New features for Version 66 * Loading of .o files and kernel binaries * Enhanced memory search * Regular expression search of the symbol table * Initial support for universal character names (UCNs) in identifiers * GUI Improvements Loading of .o files and kernel binaries Ladebug now allows loading of .o files and non-runnable kernel binaries for examination purposes. Enhanced memory search Ladebug now has the ability to search memory in 32-bit and 64-bit portions. This is an enhancement to the memory display commands:
/M // 64-bit
?M // 64-bit ,/M // 64-bit
/m // 32-bit
?m // 32-bit ,/m // 32-bit The address(es) and/or count are used to determine the range of memory to search, similar to normal memory display functions. The 'M' means search 64-bits at a time - the 'm' means search 32-bits at a time. The M/m stands for "match". For each memory location searched the mask is applied to the memory value and then compared with the input value. If a match is found then the address of the location and the memory value are displayed. For example, to look for a 32-bit quantity beginning with 0xb5 starting at address 0x1200013b4, you'd use this command: (ladebug) 0x1200013b4/10m 0xb5000000 0xff000000 0x1200013c4: 0xb53e0018 To look for a 64-bit quantity ending in 0x4, starting at address 0x1200013b4 and going backwards: (ladebug) 0x1200013b4?40M 0x00000000000000004 0x000000000000000f 0x12000128c: 0xa77d8068f4200004 Addendum on Memory Search feature: * the mask is also applied to the given value, as well as each memory value, to ensure a match can be found * the search stops when a match is found Finally there is now a debugger variable for the memory search feature, $memorymatchall, which by default is set to 0. When it is set to a non-zero value, ladebug presents all matches. Otherwise, by default, ladebug presents only the first match. Regular expression search of the symbol table If you are not sure how to spell a symbol, you can use the whereis command with a regular expression in a quoted string rather than a name. This will search the target's symbol table for symbols which match the regular expression. For example, assume the name you remember didn't work: (ladebug) whereis planet Symbol not found Ok, maybe it's spelled with a captial letter: do a regular expression search: (ladebug) whereis "[Pp]lanet" "solarSystemSrc/derived_class_includes/planet.h"`Moon::Moon(char*, Megameters, Kilometers, class Planet*) "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet::Planet(char*, Megameters, class HeavenlyBody*) "solarSystemSrc/derived_class_includes/planet.h"`Planet::Planet(char*, Megameters, class HeavenlyBody*) "solarSystemSrc/derived_class_includes/planet.h"`Planet::print(unsigned int) "solarSystemSrc/derived_class_includes/planet.h"`__INTER__Moon_Moon_Orbit_Planet_Xv "solarSystemSrc/derived_class_includes/planet.h"`__INTER__Planet_Planet_Orbit_Xv "solarSystemSrc/derived_class_includes/planet.h"`__dt__6PlanetXv __T_6Planet __cxxexsig6Planet __vtbl_5Orbit6Planet __vtbl_5Orbit6Planet4Moon __vtbl_6Planet solarSystemSrc/derived_class_includes/planet.h solarSystemSrc/derived_class_includes/planet.h solarSystemSrc/derived_class_includes/planet.h solarSystemSrc/planet.cxx Or you could look for the simple name "Planet" without any prefixes or suffixes to avoid C++ mangled names like __dt__6PlanetXv: (ladebug) whereis "^Planet$" "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet "solarSystemSrc/derived_class_includes/planet.h"`Planet::Planet(char*, Megameters, class HeavenlyBody*) You can use the $symbolsearchlimitdebugger variable to specify the maximum number of symbols that will be returned by the whereis command for a regular expression search. The default value for the $symbolsearchlimit variable is 100; a value of 0 indicates no limit. Initial support for universal character names (UCNs) in identifiers Ladebug will start providing support for universal character names (UCNs) in identifiers as specified in C99 and C++ standards. A UCN is a character string in the form of \uXXXX or \UXXXXXXXX, where X is a hex number (case insensitive). One important equivalence relation is that \uWXYZ is the same as \U0000WXYZ. See the standards for details on the usage of UCNs. As an example, if the C program being debugged has a variable named \u0111_1, you can use the commands (ladebug) print \u0111_1 or (ladebug) print \U00000111_1 to examine its value. Because the standard specifies case-insensitivity, the equivalence relation mentioned above and other language specific exceptions (e.g. In the C language, \u0024 is treated as the character '$'), the debugger has to "normalize" an identifier, converting it into a canonical form before looking it up in the symbol table. During the normalization, the identifier as typed by the user is destroyed. As a result, if the debugger fails to find a symbol correspondent to the identifier that the user typed, it will be the normalized identifier which is echoed, as the following example demonstrates: (ladebug) p \U0000abcd Symbol "\uABCD" is not defined. GUI Improvements * User interface to aid debugging of multi-threaded programs. * Help menu that brings up the Ladebug manual or FAQ (under netscape). * Goto line function in the Source Viewer. This function is accessible through the Edit menu and the Source Viewer popup menu. * Popup menus (accessed through right mouse button press): o In editable input fields: Cut, Copy, and Paste. o In readonly input fields: Copy o In the Source Viewer: Print, What is, Watch, Plot, Stop in, Copy, Search, Search backward, Goto Line. * Stop on attach toggle in the New Target pane for setting or clearing the $stoponattach debugger variable. * Ability to insert blank lines or clear the contents of the Debugger Output pane. * Ability to hide the command input portion of the Debugger Output pane. * Ability to configure whether the Source Mapping dialog comes up automatically when source cannot be found. * Ability to configure the font used in the Source Viewer content area and in the output area of the Debugger Output pane. * Default preferences for Source Viewer font, window sizes and pane configurations for the following window systems: Tru64, Exceed, ReflectionX, Excursion, and Linux. This feature is accessible through the Preferences dialog. New features for Version 65 * Background and Cautions * if command * Various print commands * New debugger variables for supporting dbx compatibility * Improved remote kernel debugging performance Background and Cautions This release of Ladebug comes at a time when the project is well on its way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made to include a number of fixes to bugs reported since -64. See the V65 Problems Fixed section for details Note that starting with this release, the Ladebug debugger version number no longer carries "4.0" The "4.0" part of the number had been used to distinguish versions which supported Tru64 Unix 4.0 or greater from those supporting 3.2 or earlier, and is no longer needed. V65 is an immediate descendent of 4.0-64. if command The Ladebug debugger now provides the if command whose behavior depends on the value of an expression, with the following syntax: if expression braced_command_list [ else braced_command_list ] In this command, the first braced_command_list is executed if expression evaluates to a non-zero value, otherwise the braced_command_list in the else_clause is executed, if specified. For example: (ladebug) set $c = 1 (ladebug) assign pid = 0 (ladebug) if (pid < $c) { print "Greater" } else { print "Lesser" } Greater Various print commands In V65, the Ladebug debugger provides three new print commands: printi, printt, and printb. * printi takes one or more comma-separated instruction expressions and outputs each one in assembly format. See the following example for more detail: (ladebug) $curpc/5i int main(int, char**): probe.C *[line 17, 0x120002780] ldl r1, 48(sp) [line 17, 0x120002784] xor r1, 0x2, r1 [line 17, 0x120002788] beq r1, 0x1200027b0 [line 19, 0x12000278c] ldq r16, -32728(gp) [line 19, 0x120002790] lda r16, -2808(r16) (ladebug) $curpc/5xx 0x120002780: 0xa03e0030 0x44205801 0xe4200009 0xa61d8028 0x120002790: 0x2210f508 (ladebug) printi 0xa03e0030, 0x44205801, 0xe4200009 ldl r1, 48(sp) xor r1, 0x2, r1 beq r1, .+0x28 Note in the branch instruction that the _offset_ is given, rather than the destination PC. This is expected, since the address of the instruction argument is unknown to the printi command. Also note that we have switched the built-in alias pi from "playback input" to "printi". * printt (built-in alias pt) takes one or more integer arguments and processes each one as a time value, in seconds, from the Epoch (7pm, Dec. 31, 1969). (ladebug) printt 0 Wed Dec 31 19:00:00 1969 (ladebug) printt 0xfaceface Wed Mar 29 16:55:26 1967 * printb (built-in alias pb) takes one or more numerical arguments and outputs them in binary format. (ladebug) printb 1234567 0b100101101011010000111 Note: Ladebug does not yet accept input in the form output by the printb command. New debugger variables for supporting dbx compatibility Two new debugger variables are added to support dbx compatibility: * $readtextfile, primarily used for Tru64 Unix kernel debugging. * $regstyle, which controls the format of the register names during disassembly. Note that this only occurs with the memory display commands in "i" mode. There are only three valid settings: 0 = Compiler names (e.g. zero, t3) 1 = Hardware names (e.g. r31, r4) (the default) 2 = Assembly names (e.g. $31, $4) Improved remote kernel debugging performance In V65, the Ladebug debugger implements the next, step and stepi operations several times faster than before, equalling the performance of the dbx debugger. New features for Version 4.0-64 * Background and Cautions * Older Linux platforms no longer supported * New debugger control variable $floatshrinking * Support for the printing of NUMA distributed Fortran arrays Background and Cautions This release of Ladebug comes at a time when the project is well on its way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made to include a number of fixes to bugs reported since -63. See the 4.0-64 Problems Fixed section for details. Older Linux platforms no longer supported As of 4.0-64, The Ladebug debugger no longer supports Alpha Linux kernels prior to 2.2. In particular, the 2.0 kernels (e.g. as distributed in the RedHat 5.2 distribution) are not supported. New debugger control variable $floatshrinking Floating point numbers are represented inside the computer in binary floating point. They are converted to decimal floating point when printed. The two formats are not the same, and some numbers are easily represented in decimal but not in binary (such as 1.1). The internal binary form for such numbers is an approximation, the closest that can be made given the number of bits available. It is often the case that a given binary floating point number represents several "nearby" decimal floating point numbers, as each of them would be converted into the same binary bit pattern. Normally, when a floating point number is printed out, the shortest such decimal number is used, as it is a legal representation of the internal binary number. Users who require the most exact conversion, so that they see the decimal number which is the closest representation in the number of decimal digits available can now see those digits, using the new debugger control variable $floatshrinking. The default value is one, which preserves the old behaviour of Ladebug. Users may set it to zero to see the unshrunk numbers. Here's an example, showing the result of converting 1.1 to the closest long double binary floating point number when the command is read by Ladebug, and then the converting of that value back to decimal floating point when printed for the user. The shrunk number is 1.1, but the unshrunk number is the closest decimal number to the actual binary approximation to 1.1: (ladebug) p $floatshrinking 1 (ladebug) p 1.1 1.1 (ladebug) set $floatshrinking = 0 (ladebug) p 1.1 1.10000000000000000000000000000000008 At the moment, the unshrunk forms are only available for long double variables and expressions (which includes literals from the command line as above). For more detail on floating point representation, see ANSI IEEE standard 754-1985. Ladebug now supports printing of NUMA distributed Fortran arrays You can now use the print and whatis commands with Fortran arrays, which were distributed using NUMA directives. New features for Version 4.0-63 * Background and Cautions * New processing of comment character '#' * Support for anonymous structures in BLISS * More support for external symbols on Linux Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made to include a number of fixes to bugs reported since -62. See the 4.0-63 Problems Fixed section for details. New processing of comment character '#' Ladebug now requires the '#' character which starts a non-leading comment to be preceded by whitespace and followed by whitespace or newlines. Leading comments (lines which start with '#') do not have to have preceeding whitespace, and a '#' at the end of a line does not have to have trailing whitespace. This is an incompatible change, but is needed because the tmpnam standard library function generates file and directory names containing '#' characters. Ladebug will now see "right#file" as a name, not as "right" followed by a comment. This work was done based on QAR 81040. Support for anonymous structures in BLISS When debugging BLISS code, the debugger variable $statusargs can be set to -1 to display anonymous structures in abbreviated form (e.g. struct {...} rather than as a list of data member names). This feature works only when debugging BLISS code. More support for external symbols on Linux Ladebug now has better external symbol support on Linux, as it will read the external symbol table as well as the debug information. New features for Version 4.0-62 * Background and Cautions * New support for Fortran 90 Intrinsic Procedures * New Debugger Variable $cursrcpc * New command line option -interactive Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made to provide a fix for a libc error that affects debugging programs optimized with "Spike". New support for Fortran 90 Intrinsic Procedures Ladebug now supports the kind type category of Fortran 90 intrinsic procedures in addition to those in the mathematical category (as described in the Compaq Fortran Language Reference Manual, which discusses categories of intrinsic functions). New Debugger Variable $cursrcpc This new variable contains the most recently listed PC address. New command line option -interactive This option makes Ladebug act as though stdin is tied to a tty device regardless of whether it really is or not. This is sometimes useful when using rsh to run Ladebug. Currently, the only effect is to cause Ladebug to output a prompt to stdout when it is ready for the next line of input. New features for Version 4.0-61 * Background and Cautions * New meaning for px alias * Display of bitfields in registers * New command unrecord * Improved handling of C++ interludes * Improved handling of C++ downcasts * Pick-lists for multiple files * The debugBreak function * GUI Improvements * Improvements to performance * Miscellaneous improvements Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-61 Problems Fixed section for details. Version 61 follows directly on version 59; there was no formal version 60, though a patch kit with that number was sent to some customers. New meaning for px alias The aliases px, pd and po used to expand to a printf of the first longword of the referenced value; this meant that px of a structure would not show the fields of the structure. We have changed these aliases so that they now refer to new commands (printx, printd and printo), which will not only change the display radix, but will also show the fields of structures. The example below shows the new result, as well as a printf command to simulate the old result: (ladebug) print a struct S { i = 12; c = '\211'; } (ladebug) printf "0x%lx", a 0x890000000c (ladebug) px a struct S { i = 0xc; c = 0xffffffffffffff89; } Display of bitfields in registers Bitfields in registers can now be printed. New command unrecord A new command unrecord has been added; it will turn off the specified recording (input, output or io). Previously, to turn off recording, users had to set recording to /dev/null. Improved handling of C++ interludes When there are derived classes with virtual methods, and multiple inheritance, the compiler sometimes generates 'interludes' - small functions that adjust the 'this' pointer as part of a virtual call. Setting a breakpoint in such an interlude, such as by either of the two commands below (ladebug) stop in __INTER__Top_f_Base_Xv (ladebug) stop in b->f now results in the breakpoint actually being set in the virtually called method - much closer to what the user probably intended. This makes the interlude be just part of the set-up sequence of instructions for the virtual method - even though physically separate from it. To actually break on the interlude itself, use the "stopi" command and the actual address of the interlude in the machine code: (ladebug) stopi at &__INTER__Top_f_Base_Xv Improved handling of C++ downcasts Given arbitrary multiple inheritence including virtual inheritence... class Base1 { ... }; class Base2 { ... }; class Middle : public Base1, public virtual Base2 { ... } class Top : public Middle { ... } Top top; Ladebug now does the right things when you () cast objects (ladebug) print (Base2)top () cast pointers (ladebug) print (Base2*)&top () call methods (ladebug) print top->virtFunc() (ladebug) print (Base2*)&top->virtFunc() (ladebug) print ((Base2)top).virtFunc() Pick-lists for multiple files Where there is more than one file which might have been specified, the user is given a pick-list to select from: (ladebug) file a_multi_unit.ada Select from ---------------------------------------------------- 1 a_multi_unit.ada containing int YI 2 a_multi_unit.ada containing void Z_foo(void) 3 a_multi_unit.ada containing void Y_foo(void) 4 a_multi_unit.ada containing int ZI The debugBreak function debugBreak is a function that can be added to any program. When the debugBreak function is called, it creates a Ladebug debugger process with the initialization needed to connect the debugger (via attach) to the program. This process invokes the debugger, positioned at the prompt, with control over the program just after the debugBreak call. The id of the process calling debugBreak is stored in the new debugger variable $exitonterminationofprocesswithpid. The debugger will exit after debugBreak if the process runs to completion under the debugger. For a detailed discussion on how to use debugBreak, please refer to the Ladebug Debugger Manual. GUI Improvements GUI improvements: * Support for selection panels and wizards being in thier own "plane" window (without a menu bar). * Breakpoint editor wizard. * Use x,y coordinates if specified. * runArgs made temporary. * Debugger output window always appears on startup. * Better support for attach. * Better performance. * Better "interrupt" support. * dxladebug will now be executing a script that calls ladebug -gui, supporting compatibility with old Ladebug command line. Improvements to performance Performance improvements: * Performance improvement to "step" for lines with lots of instructions. * Performance improvement to trace. * Performance improvements to symbol lookup. Miscellaneous improvements * Better echoing of escaped characters in aliases. * Command call is enabled on Linux. * Better handling of namespaces. Please also see New features for Version 4.0-59 for a list of recently introduced features, including a new graphical user interface. New features for Version 4.0-59 * Background and Cautions * New debugger control variable $lasteventmade * New command option -V Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-59 Problems Fixed section for details. Please also see New features for Version 4.0-57 for a list of recently introduced features, including a new graphical user interface. New debugger control variable $lasteventmade A new debugger control variable $lasteventmade has been created. It contains the number of the most recently-created event (breakpoint, watchpoint, catch, etc.). The intended use is the support of complex debugger command scripts in which the user wishes to enable (or disable or delete, etc.) events created in the script. New command option -V A new option to the ladebug command has been added. The -V option will cause the Ladebug debugger to print its version number and terminate. New features for Version 4.0-58 * Background and Cautions * Logical Data Type Support in Fortran Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-58 Problems Fixed section for details. Please also see New features for Version 4.0-57 for a list of recently introduced features, including a new graphical user interface. Logical Data Type Support in Fortran Ladebug now supports tracing of logical variables and comparison of logical values with other logical values and with integer values. ------------------------------------------------------------------------ New features for Version 4.0-57 * Background and Cautions * New Graphical User Interface * New Command-- edit * New Predefined Aliases-- printd, printo, and printx * New Debugger Variable-- $curfilepath * Better Fortran Support * Shell-like Treatment on run/rerun Arguments * Comprehensive Diagnostic Message when Ladebug Cannot Find a Source File Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-57 Problems Fixed section for details. New Graphical User Interface This version of Ladebug includes the new Graphical User Interface (GUI). This interface presents a source-code centered view of the application being debugged. Although it does not yet support all of the Ladebug command line functionality, it does provide the core commands needed for most debugging sessions. The commands not supported may still be entered at the terminal window in which the debugger and gui are running. To start the GUI, use the -gui switch on the Ladebug command line when starting it up, or enter the "gui" command anytime during a command line debugging session. We are eager to hear feedback on the new GUI. It will be used to guide development of future releases. Note that the new GUI does not work with FUSE. New Command-- edit Use the edit command without an argument to bring up an editor on the current source. Specify a file to bring up an editor on the specified file. Ladebug evaluates the EDITOR environment variable to pick an editor. It will default to 'vi'. New Predefined Aliases-- printd, printo, and printx Three predefined aliases are added in this release: * printd is the alias for printf "%ld", * printo is the alias for printf "0%lo", * printx is the alias for printf "0x%lx", They are added for dbx friendliness. Meanwhile, two unsupported aliases, sb and sj, have been removed. New Debugger Variable-- $curfilepath $curfilepath has the value of the access path used to find the current file (relative if relative, absolute if absolute). It can help users debug their map source directory and use commands. Better Fortran Support Ladebug now supports invocation of generic and specific Fortran 90 intrinsic procedures in the Mathematical category as described in the Compaq Fortran Language Reference Manual. Ladebug also supports the exponentiation operator for non-complex operands. Shell-like Treatment on run/rerun Arguments Ladebug now treats arguments to run/rerun commands in a shell-like manner, supporting tilde(~) and environment variable expansion, wildcard substitution, single quote('), double quote("), and single character quote(\). Comprehensive Diagnostic Message when Ladebug Cannot Find a Source File In this release, Ladebug emits a more comprehensive diagnostic message when it is unable to locate a source file-- it prints out the pathnames that it tried and failed. ------------------------------------------------------------------------ New features for Version 4.0-56 * Background and Cautions * More dbx Friendly Features Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-56 Problems Fixed section for details. More dbx Friendly Features When the debugging variable $dbxoutputformat is set to a non-zero value, * the command assign echoes the assigned value, and * the command process displays information about the process that is being switched to. For example, (ladebug> set $dbxoutputformat = 1 (ladebug) run [1] stopped at [int main(void):18 0x120001104] 18 x.op = 6; (ladebug) assign x.op = 9 9 (ladebug) show process * >localhost:25965 (qq) paused. localhost:26133 (www) loaded. (ladebug) process www Current Process: localhost:26133 (www) loaded. ------------------------------------------------------------------------ New features for Version 4.0-55 * Background and Cautions * Support for Reflexes * Support for Source Directory Mappings * More Debugger Variables for customizing the Look of Ladebug * The Old GUI dxladebug Is Dropped from the Kit Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-55 Problems Fixed section for details. Support for Reflexes We introduce the concept of reflexes in this release. Reflexes are a generalization of various detector-reaction operations in Ladebug, such as breakpoints, watchpoints, and signal and unaligned catching. The syntax for reflex creation is designed in such a way that it is backward compatible with the syntax for breakpoint creation, except in the case of "stop < exp > ", which in the old days meant "stop when the value of < exp > changes", and now means "stop in < exp > if < exp > is a function name; otherwise, stop at line < exp > ." Therefore, the user should notice minimal differences when creating breakpoints. Enter 'help stop' at the prompt to learn more about reflexes. Support for Source Directory Mappings Source directory mappings enable Ladebug to look for source files in directories other than the ones provided in the debug info. To learn more about this feature, enter 'help map source directory' at the prompt. More Debugger Variables for customizing the Look of Ladebug For users who prefer the look of dbx, this release provides three new debugger variables for customizing Ladebug to look more like dbx. These variables are $showlineonstartup, $showwelcomemsg, and $giveladebughints. Enter 'help $variable' to see their usage. The Old GUI dxladebug Is Dropped from the Kit We no longer support dxladebug. ------------------------------------------------------------------------ New features for Version 4.0-54 * Background and Cautions * New debugger variable $funcsig * Additional support for Fortran dynamic arrays * New Graphical User Interface incorporated into Ladebug image * Support for Extended Source Line Information Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes. See the 4.0-54 Problems Fixed section for details. New debugger variable $funcsig A new debug variable, $funcsig, has been added which controls the display of function signatures when the debuggee program is stopped. Additional support for Fortran dynamic arrays This release of Ladebug contains symbolic info parsing support for the fortran array descriptor format produced when "-ladebug" is not specified on the compile line New Graphical User Interface incorporated into Ladebug image This release incorporates the Beta release of the new GUI into the Ladebug image. This GUI shows the style and direction of the Ladebug GUI effort. It is provided for comment and review. Future releases will continue to refine and develop this GUI. Support for Extended Source Line Information This release of Ladebug contains symbolic info parsing support for Extended Source Line Information. ------------------------------------------------------------------------ New features for Version 4.0-52 & 4.0-52gui * Background and Cautions * New Graphical User Interface (4.0-52gui only) * Attaching to a process without specifying an image name * New dbx-compatible commands: o cont o conti to * New debugger variables: o $dbxuse o $curprocess o $dbxoutputformat o $statusargs o $doverbosehelp * Improved behavior of the record command * Support for debugging optimized code that has discontiguous scopes Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes in the debugging support for multi-threaded processes. See the 4.0-52 Problems Fixed section for details. New Graphical User Interface This release of Ladebug includes the Beta release of the new GUI for comment and review. This GUI shows the style and direction of the Ladebug GUI effort . Future releases will continue to refine and develop this GUI. For this release the GUI focuses on the operations needed to perform basic source code level debugging. More features will be added in future releases. Any feature not directly supported through the GUI can still be entered in the terminal window from where Ladebug was originally invoked, the GUI will stay in sync with the engine, in this case. A web-based help system is provided with the new GUI to aid in using and understanding it. To invoke the new GUI: ladebug -gui ........or ladebug and enter the gui command at the ladebug prompt whenever you wish to see the GUI (See Caveat 3.) Caveats and Tips 1. A lot of functionality is still not implemented 2. The HELP text is slightly out of synch with the implementation, due to changes made as a result of internal reviews. The gist of the help text is still valid 3. To exit the GUI select the X in the upper left corner of the topmost panel. Note that this leaves the engine running. Currently, if you exit the GUI then restart it in the same session, you will lose the current state of your debug session, and the application will be restarted. Attaching to a process without specifying an image name Ladebug now allows the user to attach to a process without specifying an image name. The attach command has been changed to have the following syntax: attach [image-name-optional] If the image name is not given, the image name of the current process is assumed. New dbx-compatible commands cont Continues the program execution and ignores the next (+1) breakpoints. conti to Continues the execution of the process until the instruction at is about to be executed. New debugger variables * $dbxuse, defaults to 0 Ladebug's "use" command (use [a sequence of dir names]) appends the [dir names] to the existing use list. This is different from the "use" command in dbx, which replaces the existing list with [dir names]. By setting $dbxuse the user can select between the two flavors of "use": When $dbxuse is set to a non-zero value, the "use" command replaces the existing use list, otherwise "use" appends to the existing use list. * $curprocess Contains the pid of the current process. * $dbxoutputformat, defaults to 0 When this variable is set to a non-zero integer, Ladebug will print values of structs and arrays using dbx's formats. * $statusargs, defaults to 1 If it is set to zero, the call stack will be printed in a non-verbose fashion (no parameters). * $doverbosehelp, defaults to 1 When $doverbosehelp is non-zero, a help request on an unrecognized command invokes the intro to help system; when $doverbosehelp is zero, the intro to help system is suppressed. Improved behavior of the record command When the file name is not specified in a "record" command, we create a new file as the recording file in /tmp whose name is suffixed by a running number. A number is skipped if the file ended in that number already exists (as you can see here, my /tmp is filled with ladebug-record-io-00[01-13]). The file name is echoed so the user knows which it is. For example: % ladebug Welcome to the Ladebug Debugger Version 4.0-52 (ladebug) record io I/O recorded in file /tmp/ladebug-record-io-0014 (ladebug) record input Input recorded in file /tmp/ladebug-record-input-0015 (ladebug) record output Output recorded in file /tmp/ladebug-record-output-0016 Support for debugging optimized code that has discontiguous scopes Added support for debugging optimized code that has discontiguous scopes. ------------------------------------------------------------------------ New features for Version 4.0-51 * Background and Cautions Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes in the debugging support for multi-threaded processes and core files. See the 4.0-51 Problems Fixed section for details. ------------------------------------------------------------------------ New features for Version 4.0-50 * Background and Cautions Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieving this. This release is primarily being made due to demand for bug fixes in the debugging support for hard partitioned systems. See the 4.0-50 Problems Fixed section for details. ------------------------------------------------------------------------ New features for Version 4.0-49 * Background and Cautions Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieve this. This release is primarily being made due to demand for bug fixes in the debugging support for hard partitioned systems. See the 4.0-49 Problems Fixed section for details. ------------------------------------------------------------------------ New features for Version 4.0-48 * Background and Cautions * snapshot functionality * Support for debugging compressed files * Support for split lifetime local variables * Support for static links * Ladebug now linked against libcxx.a * Better handling of recursive functions * "thread" command now accepts an expression * Modified output for "listobj" command * Modified name lookup * More information from the "where" command * Optionally mmap a loaded file Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieve this. This release is primarily being made due to demand for support of Fortran static links, support for compressed files, performance improvements and as a vehicle for fixing bugs. snapshot functionality You can save the current state of the debuggee process in a snapshot, and later "return" to that state and try a different set of steps. Conceptually speaking, this feature is similar to the "undo" function in text editors, except that with snapshots you have the control of the granularity of each undo. Limitations: Snapshots are actually implemented by causing the process to fork. 1. The state saved in a snapshot doesn't cover I/O and forks. In other words, when you clone a snapshot, the I/O that has been done since the snapshot was saved is not undone; likewise, the child processes that have been spawned since the snapshot was saved are not killed. 2. 'save snapshot' saves the state of the current process only. If you are doing multiprocess debugging, you might want to save a snapshot for each process. 3. Snapshots on a multithread process are not supported. For more information, type "help snapshot" Support for debugging compressed files Ladebug will now automatically decompress compressed executables rather than depending on the user to decompress them. Ladebug looks first in the current directory for any file that is reported as coming from "/subsys" - these are usually a loadable driver. This means that * users don't have to leave buggy drivers in "/subsys" to debug them, * users can copy kernel dumps and associated loadable drivers to another platform for debugging. Support for split lifetime local variables This is a new capability in 4.0-48, but is latent until the compilers produce the necessary information. It enables the debugger to more accurately locate and evaluate variables in optimized code. Support for static links Ladebug now correctly examines variables that are up-level accessed using static links. This mainly is an issue for optimized Fortran programs that have had loops decomposed into threads. The debugger, when debugging these threads, can now examine the variables outside the loop but inside the function containing the loop. Ladebug now linked against libcxx.a Ladebug is linked against libcxx.a rather than libcxx.so, so it is not dependent on the version of C++ or the C++ RTL installed on your system. Better handling of recursive functions Recursive functions are dealt with more cleanly by the 'next', 'nexti', 'step', and 'return' commands. Prior to 4.0-48, Ladebug would break in a called function that happened to execute the next line or the address being returned to. Ladebug now checks either the $sp ('return') or the $vfp ('next', 'nexti', 'step') to see if is the expected stack frame. We expect to only test the $vfp in a future release. thread command now accepts an expression The thread command nows takes an expression, not just an integer literal, as its argument. Modified output for listobj command The listobj command output has changed to show the mapping of the .text, .data, and .bss sections of each of the loaded files. Modified name lookup We are changing Ladebug's identifier lookup to more closely follow the language model. In this version, Ladebug does a language-model-based lexical scope lookup for symbols. Occassionally this means it no longers finds symbols that it used to find - especially when it should not have found them. More information from where command Ladebug no longer filters out __start from the where command call-stack output - thus providing a more truthful picture of the real state of the program's execution. Optionally mmap a loaded file It is possible for very large applications to save some amount of swap space by having Ladebug mmap the loaded file's, rather than reading portions of them into heap-allocated storage. Defining the LADEBUG_CAN_MMAP_THE_FILE environment variable turns this latent capability on. We have not turned it on by default because 1. it doesn't make much difference for smaller applications, 2. we have not given it sufficient testing, 3. we are not sure how it will behave when you keep the same Ladebug session going, but replace the loaded file on disk. ------------------------------------------------------------------------ 2.47 What's new at Version 4.0-47 * Background and Cautions * Requirements * Support for C++ "using" declarations * Better symbolization * More information from "which" command Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieve this. This release is primarily being made due to demand for Namespace support by C++ developers and as a vehicle for fixing bugs. Support for C++ "using" declarations Support has been added for C++ "using" declarations. Better symbolization When printing a stack trace, Ladebug now prints the name of the .so file which contains a function, if it cannot find out the actual source filename due to missing debug information. This situation arises for compilations using the -g0 qualifier. More information from which command The which command was modified to provide more extensive information. ------------------------------------------------------------------------ 2.46 What's new at Version 4.0-46 * Background and Cautions * Requirements * Limited support for C++ Namespaces * More support for C++ Templates * Output pagination support Background and Cautions This release of Ladebug comes at a time when the project is only part of the way through a significant re-engineering of much of the internal structure of the product. The project has a long range goal of fixing many of the performance and reliability issues it has had, and has chosen the restructuring as the best approach to achieve this. This release is primarily being made due to demand for Namespace and Template support by C++ developers. Requirements This version of Ladebug requires that users have C++ version 6.0 installed on their Digital Unix 4.0 (or later) systems, due to a shared library dependency. Limited support for C++ Namespaces This release adds limited support for C++ namespaces. The usual C++ qualified name syntax for namespace components is now supported: NamespaceId {::namespecId}::id The anonymous namespace is not yet properly supported. Using namespace declarations or definitions is not yet supported. Implicit visibility into namespaces is not supported. More support for C++ Templates The use of templates can cause a source file to be compiled into several .o files. Limited support has been added for this situation (which can also arise due to code in .h files). Output pagination support Two new debugger variables provide user control of output pagination. * $page turns pagination on (when set to 1) and off (when set to 0) * $pagewindow can be set to the maximum number of contiguous lines which will be considered to be in a page. When set to 0 it is ignored. If during the output from Ladebug for a single command, more lines remain when the first page has been displayed, the user is asked More (n if no)? A response of n is equivalent to typing Ctrl-C: the current command is abandoned as soon as possible, and control returns to the (ladebug) prompt level. Any other response causes the next page to be displayed. ------------------------------------------------------------------------ 2.44 What's new at Version 4.0-44 * Dynamic type member access * watch variablefunctionality * Using line numbers in expressions is now supported * Remote debugging on DIGITAL UNIX v3.2 is working Dynamic Type Member Access This change allows the user to circumvent C++ visibilities rules regarding base class pointers referencing derived class objects by directly accessing (print, whatis) derived class members through a base class pointer when $usedynamictypes is set to 1. watch variable functionality This command allows to watch the current storage assigned to the variable. Using line numbers in expressions Line numbers can now be used as a part of an expression. In particular, expressions like (ladebug) @5/i and (ladebug) @"tmp.c":5/i now work. Remote debugging on DIGITAL UNIX v3.2 This feature is working again, but the user must now use the SECURE_SERVER for it. ------------------------------------------------------------------------ 2.43 What's new at Version 4.0-43 * Command line interface support for editing lines which are longer than the screen width * Remote debugging is available on DIGITAL UNIX v4.0 Command line interface support for editing lines which are longer than the screen width Ladebug now provides an interface for editing long command lines similar to that provided by the kshell. (DECL 519) When the length of a command exceeds the width of the screen, part of a command line is now scrolled out of view and a special status character is displayed in the rightmost column. There are four possible status characters: * the status charcter is blank when the command fits fully on the screen * '>' is displayed when there are more characters beyond the right edge of the screen * '<' is displayed when there are more characters beyond the left edge of the screen * '*' is displayed when there are more characters beyond both the right and the left edges of the screen You can scroll along the command line using the arrow keys. You can press to jump to the beginning of the command line and to jump to the end of the command line. Remote debugging is available on DIGITAL UNIX v4.0 This was accidently broken in the previous release. This version fixes it. ------------------------------------------------------------------------ 3. Known problems and restrictions Each subsection below documents known problems and restrictions related to one of the following topics: * Ladebug Debugger o General Problems o Problems in Version 69 o Problems in Version 68 o Problems in Version 67 o Problems in Version 66 o Problems in Version 65 o Problems in Version 4.0-64 o Problems in Version 4.0-63 o Problems in Version 4.0-62 o Problems in Version 4.0-61 o Problems in Version 4.0-59 o Problems in Version 4.0-58 o Problems in Version 4.0-57 o Problems in Version 4.0-56 o Problems in Version 4.0-55 o Problems in Version 4.0-54 o Problems in Version 4.0-52 o Problems in Version 4.0-51 o Problems in Version 4.0-50 o Problems in Version 4.0-49 o Problems in Version 4.0-48 o Problems in Version 4.0-47 o Problems in Version 4.0-46 o Problems in Version 4.0-44 * Ladebug and Fortran * Ladebug and threads * Ladebug and FUSE * Ladebug Remote Debug Server ------------------------------------------------------------------------ 3.1 Known general problems and restrictions with the Ladebug Debugger The following are known general problems and restrictions with the Ladebug Debugger: * Problems debugging analysis routines inserted by ATOM * Problems debugging optimized code * DECthreads debugging on V3.2 * Running the debugger hangs or halts V4.0B * Restrictions due to C++ compiler bugs * Reducing the Size of Debuggable Binaries * System Patches that Ladebug Users should Install * System Crashes * Ladebug and/or Application Hangs * Examining Fortran Arrays * Dxladebug GUI Problems o Hang On Application Input o Scrolling Performance ------------------------------------------------------------------------ Problems debugging analysis routines inserted by ATOM The Ladebug debugger may crash due to running out of memory when used to debug analysis-phase routines inserted by the ATOM tool. This is due to the ATOM tool's not following the calling standard when it inserts its "trampoline" routines. This causes Ladebug to become confused about the state of the execution stack and crash. There is no work-around. Problems debugging optimized code The Ladebug debugger may not be able to see some routine parameters when used to debug optimizied code. This is because the compiler back end is not producing debug information which correctly describes the parameters. There is no work-around. DECthreads debugging on V3.2 This release of the Ladebug debugger does not support DECthreads debugging on the DIGITAL UNIX V3.2 platform. Kernel threads debugging, however, is supported on this platform and both kernel threads and DECthreads debugging are fully supported on the DIGITAL UNIX V4.0 platform. DECthreads debugging on the V3.2 platform was most recently supported in Ladebug versions 4.0-14 and V4.0-14A. Running the debugger hangs or halts V4.0B There is a problem with using any version of ladebug (or dbx) on certain systems that are running DIGITAL UNIX 4.0B. The problem is that some systems will hang or crash when the debugger is used. The machines affected are the newer machines, such as the AlphaStation 500 and 600 series machines. This is not a problem for other machines such as DEC 3000s and DEC 4000s. A kernel patch is required to fix this problem. From the 4.0B patch kit, install the following patch: NEW PatchID: 91.00 PATCH ID: OSF410-053 SUBSET(s): OSFBIN410 When using setld to install the 4.0B patch kit, look for the new PatchID in the subset menu display to select the correct patch. The patch description is: "Patch: Kernel Debugger Corrections". Restrictions due to C++ compiler bugs * There is a known bug with the C++ compiler introduced between v5.1-1 and v5.3 that will prevent Ladebug from displaying the correct value for a derived class that inherits virtually from more than one of its base classes. * There is a known bug with the C++ compiler introduced in v5.4 that may prevent Ladebug from printing the correct return value of a virtual function. When incorrect, the return value is printed as being 'void' instead of its actual value. Reducing the Size of Debuggable Binaries It is often the case that when a bug is reported to the Compaq Ladebug team, and we have looked over the .o files and .so files, etc. that were sent to us that we find that Ladebug is just being swamped by the size of the .so debugging information. The basic reason your .o and .so files may be so large is the duplication of information in them, caused by the many interrelationships amongst the classes in your application. Using the C++ -g rather than -gall switch can radically reduce the size of your binary files. Further reduction can be attempted using an undocumented feature of the V5.6 C++ compiler. The compiler can be directed to put out each class once, and only once, into a set of .o files. The debugger will then find this single occurrence when debugging the application containing all these .o files. This is done by defining the environment variable CXX_DEBUG_INFORMATION_CACHE to be the full file-name of an empty file before invoking your make script: setenv CXX_DEBUG_INFORMATION_CACHE $TMPDIR/136132834732823953.txt rm -f $CXX_DEBUG_INFORMATION_CACHE touch $CXX_DEBUG_INFORMATION_CACHE make -f your_make_script rm -f $CXX_DEBUG_INFORMATION_CACHE unsetenv CXX_DEBUG_INFORMATION_CACHE We would be interested in seeing how much this capability reduces the size of the .o and .so files in your application. It may well reduce them to the point where Ladebug can swallow the lot... We also recommend keeping both stripped and non-stripped executables, and using the stripped ones when you are debugging a different binary file that needs the presence but not debuggability of a some shared libraries. This will also improve Ladebug startup times. Apart from these approachs, the only other approach we can suggest is compiling most of your sources -g0, and compiling just a small subset -gall. System Patches that Ladebug Users should Install The following Compaq Tru64 Unix patches clear up various Ladebug problems that have been reported to us. Customers can get these from http://www.service.digital.com/html/patch_main.html The following patches are strongly recommended. ***in all cases*** NEW PatchID: 91.00 PATCH ID: OSF410-053 SUBSET(s): OSFBIN410 New PatchID: 136.00 PATCH ID: OSF410-400239 SUBSET(s): OSFBASE410OSFCMPLRS410 ***if you are using AdvFS*** New PatchID: 128.00 PATCH ID: OSF410-400231 SUBSET(s): OSFADVFSBIN410 OSFADVFSBINOBJECT410 System Crashes Ladebug has no special privileges or hooks into the system, and as such can not cause any crashes that another debugger or other program could not also cause, hence such crashes are fundamental system problems, not Ladebug problems. However Ladebug does exercise parts of the system (especially procfs, ptrace, and pthreads) more than other programs, and hence crashes caused by these components are seen as 'Ladebug crashed my system', and so the Ladebug team gets such reports regularly. The single biggest problem occurs on V4.0B and V4.0C running on some machines, where using the debugger hangs or halts the system. The machines affected are the newer machines, such as the AlphaStation 500 and 600 series machines. This is not a problem for other machines such as DEC 3000s and DEC 4000s. The problem can be worked around by patching the kernel as follows... If Ladebug causes a problem even doing this, the user can use dbx to perform the patch. % ladebug -k /vmunix (ladebug) patch db_enable=0 (ladebug) quit A kernel patch is required to fix this problem. Ladebug and/or Application Hangs Ladebug relies on both the DECThreads and procfs components of the base system to work. However there have been a series of problems in these components that cause Ladebug to hang, or incorrectly step, etc. while debugging applications. Using a 4.0-40 (or later) Ladebug, and installing the latest patches for DECThreads and the Unix kernel will cause many of these problems to go away. Any further problems should be reported to the Ladebug team, who will then work with the appropriate other teams to get the problems resolved. Here are the relevant patches. Examining Fortran Arrays Ladebug's understanding of Fortran expressions is weak, and is an area where future improvement is being considered. In particular, arrays of strings are incorrectly understood as though the array had an extra left-most dimension indexing the individual characters, rather as though it were an array-of-array-of-character. For this reason, Ladebug emits the following error message when you try to use correct Fortran syntax... (ladebug) print a(1)(:1) print a(1)(:1) ^ Unable to parse input as legal command or Fortran expression. Also for this reason, Ladebug accepts expressions that Fortran would not... (ladebug) print a(1:2,2:3) (2) "ef" (3) "ij" For the time being, you should use this second form to deal with arrays of strings. Dxladebug GUI Problems Please note that the original GUI (dxladebug) is no longer supported and has been removed from the Ladebug kits as of version 4.0-55. To obtain the final version of dxladebug, install the 4.0-52 Ladebug kit. * Hang On Application Input * Scrolling Performance Hang On Application Input When the application being debugged waits for input, dxladebug 'hangs' with none of the controls doing what they are supposed to. The biggest frustration here seems to be the result of the user simply not knowing why the GUI has hung - often they are not aware that their application has stalled waiting for input. Once the application receives the input it is waiting for, dxladebug comes to life again. The problem is still present in the Ladebug 4.0-40 release. We are investigating why the problem occurs, and will fix it within the current GUI if the fix is simple and does not endanger the rest of the GUI. Workaround: Either use the command-line interface, or provide the input to the application. Scrolling Performance The source display had scroll bars, but terrible scrolling performance. This was largely fixed in Ladebug 4.0-40 and later releases. The actual performance of the scrolling was dramatically improved, and a FIND capability was added. ------------------------------------------------------------------------ Problems in Version 69 Inability to debug module usage by anonymous Fortran programs The Fortran compiler now issues debug information for module usage, but it does not do so for anonymous main programs. This means that for a program like the one below, where the module M is defined in a separate source file, Ladebug will not be able to find variable I. use M I = 99 end There is a work-around: use the PROGRAM statement in your Fortran program to give the program a name: program USE_M use M I = 99 end USE_M Please note that this is not a Ladebug problem; should the Fortran compiler bug be fixed, Ladebug will be able to debug these programs. For a list of additional known problems with version 69 see known problems with Version 68. Problems in Version 68 There are no new known problems with Ladebug version 68. For a list of additional known problems with version 68 see known problems with Version 67. Problems in Version 67 Bug in paging control for parallel debugger Paging control in a parallel debugging session doesn't work properly. The most serious indication occurs when the answering "n" to a "More" prompt while debugging a parallel application; in this case Ladebug will ignore the "n" and continue to list. There is no way to get around this problem beyond making sure that your list commands all specify a small number of lines. New requirement for running Ladebug on Linux systems In Version 67, Ladebug is linked shared (rather than staticly) against some Compaq libraries (in particular, libots.so). Ladebug also uses the libraries libc.so and libdl.so, but uses the Linux-provided versions of those libraries when running on Linux. This means that to run Ladebug on Linux, users must have installed the Compaq shared libraries. If any Compaq compiler has been installed, the necessary libraries will have been installed with it. For a list of additional known problems with version 67 see known problems with Version 66. Problems in Version 66 Bug in paging control for parallel debugger Paging control in a parallel debugging session doesn't work properly. The most serious indication occurs when the answering "n" to a "More" prompt while debugging a parallel application; in this case Ladebug crashes with socket errors. To get around this problem, turn off paging control altogether by entering the following at the Ladebug prompt (or in a script, such as .dbxinit or .ladebugrc): set $page = 0 Bug in the C++ demangler Ladebug uses There is a bug with the C++ demangler Ladebug uses in V66. Within the debugging information of a binary, mangled names of the form: "__7_RWinsert_aux__Q2_3std56vector__ps__6_jbZ1Z__ tm__29_Q2_3std19allocator__tm__3_jbFQ3_3std30vector __ps__6_jbZ1Z__tm__4_Z1Z8iteratorjb_v" will fail to be demangled and will generate the following error message: Please report a demangle internal error This behavior has been observed using the Compaq C++ V6.3-007 compiler. Other compiler versions may or may not be affected. Note that Ladebug Version 65 does not issue the above error message as it uses an older demangler. Ladebug Version 66 does finish loading, so it should be usable. For a list of additional known problems with version 66 see known problems with Version 65. Please note that the Version 65 "known problem" with the GUI has been fixed in this release! Problems in Version 65 GUI bug printing variables When using the GUI, if you have more than one Source Viewer up on different threads, printing variables may not yield the expected results. This is because the engine's notion of the current thread and frame may be different from what is viewed in the Source Viewer where the user is issuing the print command. The debugger output window and the DO button don't send their context to the engine when sending command requests to the engine. The current work-around is to click the mouse on the selected frame in the Source Viewer where you want to print. Then issue the command. For a list of additional known problems with version 66, see the known problems with Version 4.0-64. Problems in Version 4.0-64 For a list of known problems with version 4.0-64, see the known problems with Version 4.0-63. Problems in Version 4.0-63 For a list of known problems with version 4.0-63, see the known problems with Version 4.0-62. Problems in Version 4.0-62 For a list of known problems with version 4.0-62, see the known problems with Version 4.0-61. Problems in Version 4.0-61 For a list of known problems with version 4.0-61, see the known problems with Version 4.0-59. Problems in Version 4.0-59 For a list of known problems with version 4.0-59, see the known problems with Version 4.0-58. Problems in Version 4.0-58 For a list of known problems with version 4.0-58, see the known problems with Version 4.0-57. Problems in Version 4.0-57 For a list of known problems with version 4.0-57, see the known problems with Version 4.0-56. Problems in Version 4.0-56 For a list of known problems with version 4.0-56, see the known problems with Version 4.0-55. Problems in Version 4.0-55 For a list of known problems with version 4.0-55, see the known problems with Version 4.0-54. Problems in Version 4.0-54 The following are known problems and restrictions with the Ladebug Debugger Version 4.0-54 release: * The dxladebug GUI has become non-functional with this release and is no longer supported. For a list of additional known problems, see the known problems with Version 4.0-52. ------------------------------------------------------------------------ Problems in Version 4.0-52 For a list of known problems with version 4.0-52, see the list of known problems with Version 4.0-51. ------------------------------------------------------------------------ Problems in Version 4.0-51 For a list of known problems with version 4.0-51, see the list of known problems with Version 4.0-50. ------------------------------------------------------------------------ Problems in Version 4.0-50 For a list of known problems with version 4.0-50, see the list of known problems with Version 4.0-49. ------------------------------------------------------------------------ Problems in Version 4.0-49 For a list of known problems with version 4.0-49, see the list of known problems with Version 4.0-48. ------------------------------------------------------------------------ Problems in Version 4.0-48 For a list of known problems with version 4.0-48, see the list of known problems with Version 4.0-47. ------------------------------------------------------------------------ Problems in Version 4.0-47 For a list of known problems with version 4.0-47, see the list of known problems with Version 4.0-46. ------------------------------------------------------------------------ Problems in Version 4.0-46 The following are known problems and restrictions with the Ladebug Debugger Version 4.0-46 release: * Problems with very large applications * Problems with per-routine entry tracing * Known problems with handling interrupts * step fails to step into routine * Core files produced by cont command may not be readable * Release notes under CDE may cause broken link message * kdbx hangs on whatis command * Line numbers may be wrong after illegal multibyte characters * Register View may hang dxladebug GUI * Cannot modify registers from Register View in dxladebug GUI * Memory consumed when using dxladebug GUI * Source view in dxladebug GUI displays incorrect line after program completion * Instruction view in dxladebug GUI causes error after "detach" * Some buttons may be incorrectly active in the Source Browser of the dxladebug GUI * Using an alias for quit may confuse the debugger * The dxladebug Source Browser cannot be iconized * Ladebug may cause a "no pseudo-terminals available" message ------------------------------------------------------------------------ Problems with very large applications Very large C++ applications (>50Mb debuggable binaries) may have trouble with the debugger running out of memory. The internals of this version of Ladebug contain both the new and the old versions of data structures that we are re-engineering. For this reason, it can use more memory than previous versions. This will be fixed in the next version, but for now, be aware that you may have to increase your datasize limit: % limit datasize 500000 Very large C++ applications (>50Mb debuggable binaries) seem to have this problem the most. You should make sure you are using the latest C++ 6.0 compiler, and that you are not using the -gall qualifier too heavily, since earlier compilers and the -gall qualifier both cause large debuggable binaries. Problems with per-routine entry tracing A Unix kernel bug results in the debugger being unable to insert tracing breakpoints in some applications. Users will see messages like this: Warning: Unable to insert breakpoint at 0x3ff80173398. If the address can be read then you have run into a known operating system problem which has been reported, but for which a fix is not yet available. The following shows a way to see if the memory is readable... (ladebug) 0x3ff80173398/X 0x3ff80173398: 6bfa800147ff0400 Writes to the process using either the procfs or ptrace facility are consuming "mapentries", objects used to map VM space for re-writing the memory. When all the available mapentries are consumed, further writes can only happen to pages that have already been written to. A workaround outside of Ladebug is to bump the maxentries from the default of 200 to something like 20000 with dbx: dbx -k /vmunix assign vm_tune.vt_mapentries=20000 quit You can also put this in /etc/sysconfigtab as: vm: vm-mapentries = 20000 When a patch to the Unix kernel is available, it will be released through the normal channels. Within Ladebug, this problem most often arises due to the use of the stop <variable> command. Delete any such commands and use watch instead; the problem may go away and you will be able to continue debugging. Note that there will be warnings when the 'stop' is deleted. Known problems with handling interrupts The following are known to be problems with the debugger's handling of interrupts (Ctrl/C): * After pressing the dxladebug GUI "Interrupt" button multiple times in rapid succession (in an attempt, for example, to halt the display of a program variable that contains a large amount of data), the dxladebug GUI will fail with an assertion failure. (LB 2227.1) * An interrupt entered when the debugger is loading a program will not halt the load process. * Occasionally, assigning a value to a variable will not work after entering an interrupt. * Occasionally, after an interrupt is entered, the debugger will stop indefinitely in the routine "__exc_virtual_unwind" after displaying one or the other of these two messages: bad PC (0x5083200000000010) - stack trace not available. PC is zero - stack trace not available. Several other problems related to interrupt handling have been fixed in Version 4.0-43. See the Problems Fixed section of 4.0-43 for details. step fails to step into routine Under certain circumstances the debugger will not step into a called function when instructed to do so by the debugger "step" command. If the calling function, function A, is built into a shared library and the called function, function B, is not built into that shared library, attempts to step into function B from its call site in function A may not be honored by the debugger, and program execution will proceed right through function B without stopping. To work around this problem, set a breakpoint inside function B before it is called. Core files produced by cont command may not be readable Under certain conditions, the debugger cannot read a core file produced by the debugger's "cont " command. When debugging a DECthreads multithreaded application, and if the "cont " command is given with a signal that produces a core file, that core file cannot be read back in by the debugger. Release notes under CDE may cause broken link message There is a problem with the integration of the release notes into the Common Desktop Environment. If the Ladebug release notes are not installed on the system (subsets OSFLDBDOC or IOSLDBDOC), then clicking on the README icon in the Ladebug application group in the CDE Application Manager will result in a "broken link" error message. kdbx hangs on whatis command A problem with the kdbx debugger, when Ladebug is used as the underlying debugger engine, causes kdbx to hang when the Ladebug command "whatis" is issued. Line numbers may be wrong after illegal multibyte characters If a line in a debugger command input file contains multiple illegal multi-byte characters, then the line numbers displayed in the debugger error messages will be incorrect. Register View may hang dxladebug GUI Manipulating the Register View can hang the dxladebug GUI under the following conditions: 1) open the Register View 2) click on (select) a value in the Value/Deposit field in the lefthand side of the register display 3) select a value in the Value/Deposit field in the righthand side of the register display. The GUI will then hang, consuming as much CPU as it can get. (LB 2046) Cannot modify registers from Register View in dxladebug GUI Because of the Register View problem that may hang the dxladebug GUI and other problems with the view, the ability to modify register values has been disabled. Memory consumed when using dxladebug GUI There is a large memory leak in the "ladebug" process when the dxladebug GUI is used. This is especially true when manually expanding and collapsing pointers and structure elements in the Locals and Monitor views, or when the C++ dynamic type feature is used. Memory usage by the "ladebug" process can quickly grow to 50MB and more. (LB 2053) This memory leak has been greatly reduced in the 4.0-36 version of the debugger. Source view in dxladebug GUI displays incorrect line after program completion When program execution completes, the dxladebug GUI Source View will still display the "execution paused at" arrow at the point where the last breakpoint was encountered. (LB 2054) Instruction view in dxladebug GUI causes error after "detach" If the Instruction View is open when you detach from the program being debugged and that program completes, the following error will be displayed, once for each active breakpoint: (LB 2049) Internal Error : dbg$search_for_rout : No valid routine at PC = X Some buttons may be incorrectly active in the Source Browser of the dxladebug GUI In the Source Browser, the "Display Source" and "Set Breakpoint" buttons are sometimes enabled when they should be disabled (greyed out). (LB 1211) Using an alias for quit may confuse the debugger If you have defined an alias for the "quit" command and issue that alias in the dxladebug GUI command message view, dxladebug will not exit properly. (LB 1190) The dxladebug GUI Source Browser cannot be iconized The dxladebug GUI Source Browser cannot be iconized. (LB 1153) Ladebug may cause a "no pseudo-terminals available" message "Error: No pseudo-terminals available - can't start debugger engine" This diagnostic means that a communication channel could not be opened between the dxladebug GUI and the Ladebug engine. If you see this diagnostic, you need to add more pseudo-terminals to your kernel. ------------------------------------------------------------------------ 3.2 Known problems and restrictions with the Ladebug Debugger and Fortran The following are known problems and restrictions with the Ladebug Debugger Version 4.0-41 and Fortran: * Debugging information problems with V3.5 compiler ------------------------------------------------------------------------ Debugging information problems with V3.5 compiler Problems with the V3.5 Fortran compiler will result in unreliable debugging information in Ladebug. These problems are corrected in the V3.6 Fortran compiler. ------------------------------------------------------------------------ 3.3 Known problems and restrictions with the Ladebug Debugger and threads The following are known problems and restrictions with the Ladebug Debugger Version 4.0-40 and threads: * Thread context may change after "step[i]" or "next[i]" * Some commands need a running thread ------------------------------------------------------------------------ Thread context may change after "step[i]" or "next[i]" The step and next commands execute lines of source code based on the current thread context. The thread context may change after the operation is performed. Similarly, the stepi and nexti commands execute machine instructions based on the current thread context. Some commands need a running thread When debugging a DECthreads application, the step, stepi, next, nexti, and call commands can only be performed on running threads. ------------------------------------------------------------------------ 3.4 Known problems and restrictions with the Ladebug Debugger and FUSE From 4.0-54 on, the new GUI no longer works with FUSE. ------------------------------------------------------------------------ 3.5 Known problems and restrictions with the Ladebug Remote Debug Server The following are known problems and restrictions with the Ladebug Remote Debug Server: * Commands using signals are not supported * Cannot set breakpoint in shared libraries * Process exit code may be wrong * Processes may be left after run * Multithreaded applications are not supported * Attach and detach commands are not supported * The -pid option is not supported ------------------------------------------------------------------------ Commands using signals are not supported For remote debugging, no commands are supported that make use of signals; in particular: cont catch ignore Cannot set breakpoints in shared libraries In remote debugging, you cannot set breakpoints on functions in shared libraries (although you can now debug programs using shared libraries). Process exit code may be wrong When a remote process exits, the exit code is always returned to the debugger as 0, whatever the real exit status. Processes may be left after run When the server is run, processes may be left over afterward if the system is heavily loaded. The leftover processes must be killed manually. Multithreaded applications are not supported Multithreaded application debugging support is not available in the Remote Debug Server. Attach and detach commands are not supported The "attach" and "detach" commands are not supported. The -pid option not supported The "-pid" option is not supported. ------------------------------------------------------------------------ 4 Reporting problems If you have any problems with the Ladebug debugger, please email us at Ladebug.Support@hp.com. When reporting problems, include as much information as possible to help with diagnosis and resolution of the problem. Useful information would include (but is not limited to): * The Ladebug version number as reported in the "Welcome" banner. * The source code of a sample program or an executable binary that demonstrates the problem. * The steps necessary to rebuild the sample program or executable binary that demonstrates the problem. * The version(s) of the compiler(s) used to build the sample program or executable binary that demonstrates the problem. * The exact steps used to reproduce the problem. * If the executable program is compiled with a compiler that supports the "-P" option, please include a .i or .ixx file. * The system configuration: o the type of hardware (e.g. AlphaStation 600) o the version of the operating system (e.g. output of uname -a) ------------------------------------------------------------------------ 5 Problems fixed * Problems fixed in Version 69 o Fortran Module Support o Partial support for -names as_is o Miscellaneous * Problems fixed in Version 68 o Miscellaneous * Problems fixed in Version 67 o Miscellaneous * Problems fixed in Version 66 o Infinite Recursion o Printing Address of Variables in Registers o The printt Command o GUI o Miscellaneous * Problems fixed in Version 65 o Crediting the wrong breakpoint o Conducting symbol search in BLISS with case-sensitivity turned on o Duplicate native thread entries in the output of show thread o Miscellaneous * Problems fixed in Version 4.0-64 o Ladebug assertion failure for "stabs" debug information fixed o patch command bug o Accuracy in presenting floating point numbers o Miscellaneous * Problems fixed in Version 4.0-63 o -I qualifier no longer needs a space o $threadlevel is a preference, not a command o Improved printing of unnamed unions in C++ classes o Miscellaneous * Problems fixed in Version 4.0-62 o Debugging programs optimized with "Spike" * Problems fixed in Version 4.0-61 o Miscellaneous * Problems fixed in Version 4.0-59 o Miscellaneous * Problems fixed in Version 4.0-58 o Miscellaneous * Problems fixed in Version 4.0-57 o Miscellaneous * Problems fixed in Version 4.0-56 o Miscellaneous * Problems fixed in Version 4.0-55 o Miscellaneous * Problems fixed in Version 4.0-54 o Miscellaneous * Problems fixed in Version 4.0-52 o Multi-Threaded Debugging on Multi-CPU Systems o Attach and Detach o Language Understanding o Miscellaneous * Problems fixed in Version 4.0-51 o Multi-threaded debugging o Core file debugging * Problems fixed in Version 4.0-50 o Core file debugging o Problems with classes and/or structs having the same identifier as variables o Problems with local variables and class data members having the same identifier o Limitation in print o Support for base classes o Breakpoint/Watchpoing handling o Assertion failures o Miscellaneous * Problems fixed in Version 4.0-49 o Emacs support file, ladebug.el, missing from kit o Ladebug man pages not included in kit o Debugging on hard partitioned systems * Problems fixed in Version 4.0-48 o Shared library handling o C++ o FORTRAN o Miscellaneous * Problems fixed in Version 4.0-47 o Shared library handling o C++ o FORTRAN o Miscellaneous * Problems fixed in Version 4.0-46 o C++ o FORTRAN o GUI o Miscellaneous * Problems fixed in Version 4.0-44 o Fortran o C and C++ o Threads and Timers o Miscellaneous o Performance * Problems fixed in Version 4.0-43 o C++ Class support o Watchpoints o Further fixes to multi-dimensional arrays in FORTRAN o Indexing into interleaved arrays in COBOL o GUI o Interrupt handling o Unsigned arithmetic o Single-stepping on v3.2 systems ------------------------------------------------------------------------ Problems fixed in Version 68 Fortran Module Support A number of bugs in the handling of debug information records for the Fortran langauge Module feature have been fixed in this release. As a result, debugging of Fortran code which contains uses of the Module feature should be much easier. This work was done in parallel with work on the Fortran compiler itself, fixing bugs in the compiler's generation of the debug information records for the Module feature. It is therefore necessary to use a new compiler as well as a new Ladebug to get the improved debugging capability. This support is in Fortran version 5.5A or greater. There is still a known problem with the Fortran compiler which has an impact on debugging with Ladebug. Partial support for -names as_is When the user's context is a Fortran-language program, Ladebug does symbol look-up in a caseless manner, because Fortran is a caseless language. The Fortran compiler now has a flag, "-names as_is", which causes the compiler to be case-sensitive. Users can specify -names lowercase and -names uppercase as well, which can cause similiar problems. Use of this flag means that names are not caseless. Ideally debugger look-ups should be done in a appropriately case-sensitive manner when the current context is in a file compiled with one of the values of that flag. The Fortran complier does not tell Ladebug which files should be treated this way, so Ladebug will search for names in both caseless and case-sensitive manners, preferring the caseless names. While only partial support for the -names as_is feature, this change may assist users in debugging Fortran programs which are case-sensitive. In particular, when the user specifies a Fortran module variable using its link-name (i.e. using the pattern $$, of which an example is $FooMod$Bar), Ladebug will now look up the name in a case-sensitive manner; this lets users find module variables in files compiled with -names as_is even if the caseless form of the name specifies a completely different variable in a different module. Miscellaneous * When user commands were echoed to a file (using "set $pimode=1") the Fortran logical operator ".NOT." would be echoed using the C-language "!" logical operator. It is now echoed correctly as ".NOT.". Similar changes were made for .AND., .OR. and .XOR. Problems fixed in Version 68 Miscellaneous * Updated Ladebug to work with the "Kite" release of prun. * Fixed a Ladebug segv / core dump while trying to unwind from a bogus PC value. * Fixed a Ladebug segv / core dump while trying to open a binary containing corrupt header information. * Updated the ability to catch forks on Tru64 v5.1B * Improved SEGV signal processing and SEGV signal debugging. Ladebug used to constantly monitor the SEGV signal 11 as part of its implementation of watchpoints, even when told by the user to ignore the signal. Now Ladebug only monitors the SEGV signal if it knows there are watchpoints to monitor. Otherwise, if told to ignore SEGV, it will. The default behaviour (catch all SEGV signals) continues as before; this change only affects users who wish to ignore that signal. * Fixed a bug involving access to thread local storage when debugging Fortran OpenMP programs. Problems fixed in Version 67 Miscellaneous * Fixed DECLADEBUG 2174 - Passing any xtaso_short value to a Ladebug-initiated call. * Fixed DECLADEBUG 2274 - printt command now indicates that time is based on UTC rather than GMT. * Fixed DECLADEBUG 2278 - Assertion on: whereis "^t*". * Fixed DECLADEBUG 2280 - Assertion on: whereis xalloc. * Fixed DECLADEBUG 2282 - Incorrect printing of some floating point numbers. * Fixed DECLADEBUG 2283 - Incorrectly pulling long doubles out of a register pair. * Fixed DECLADEBUG 2287 - Guard against infinite recursion when printing a function. * Fixed DECLADEBUG 2290 - A union inside a class didn't get shown in a print. * Fixed DECLADEBUG 2296 - If a breakpoint had an action list which created a breakpoint, and the outer breakpoint was hit multiple times, Ladebug would only create one "inner" breakpoint. It now creates a new "inner" breakpoint each time the "outer" breakpoint is triggered. * Fixed DECLADEBUG 2297 - Ladebug now understands Fortran omitted optional array arguments as having no value, rather than trying to fetch through a descriptor address of zero. * Fixed DECLADEBUG 2299 - Handle "Unrecognized binary file format" gracefully. * Fixed DECLADEBUG 2310 - Now $curthread changes when $threadlevel changes. * Fixed DECLADEBUG 2330 - Linux: return sometimes fails. * Fixed DECLADEBUG 2338 - Implement work-around for inability to handle reloaded shared objects, particularly when reloaded at a different address. * Fixed DECLADEBUG 2339 - Guard against terminated threads in core files. * Fixed LADEBUGBUGS 2630 - Sub-commands in a command list will be looked at individually for their MPP-type. * Improved Ladebug startup performance for Alpha-Linux. * Clean up a variety of memory leaks. * Fixed the interaction between the GUI Help Menu selections and the ladebugHelpBrowser script that manages the user's browser(s). * In the GUI, better handle how breakpoints are displayed (and behave on user interaction) when: (1) there is more than one on a line or, (2) when a single breakpoint is represented on more than one line (i.e., stop in all ). Problems fixed in Version 66 Infinite Recursion Ladebug could be put into an infinite loop internally due to an infinite recursion occurred when stepping into a constructor or method in a doubly-nested namespace. For example: namespace A { namespace B { using A; foo::foo() {} } } The recursion occurred when stepping into the constructor for foo. Printing Address of Variables in Registers Trying to print the address of a variable that the compiler had placed in a register caused Ladebug to reply "Unable to take address of X". (ladebug) print &i Unable to take address of i (ladebug) Now Ladebug will tell the user the register number. (ladebug) print &i $r6 (ladebug) NOTE: The printing of register numbers only works when $dbxoutputformat is set. printt Command Improvement The printt command used to display the time printed adjusted to the local time-zone, as Ladebug used the ctime library function. Users requested unadjusted (GMT) times, as provided by the gmtime library function. These times are probably closer to the time units the program expects to be manipulating. Another consideration is that users may be physically located in a different time-zone than the target application is running in, and time-zone conversion could be wrong or misleading. As an example, the value zero (0) used to be printed here in New Hampshire as "Wed Dec 31 19:00:01 1969", adjusted to our local time. As a raw time value, in GMT, zero is "Thu Jan 1 00:00:01 1970". Ladebug now prints the value "(GMT) Thu Jan 1 00:00:01 1970" for the command printt 0. GUI Problems Fixed * Printing variables in multiple source viewers or windows on different threads did not always yield the expected results. Now, the context (i.e., process, thread, frame) that is reflected in the source viewerwilwill be the context used when printing variables from either the DO button or the debugger output pane. If the debugger output pane is in its own window, printing will utilize the context last set up by the last user action in a given source viewer. * Several resize problems were fixed. * The locator button in the source viewer toolbar (=>) is now disabled when there is no current location in the source being viewed. * Setting a breakpoint on a line in a file other than the one viewed in the source viewer (e.g. through the command line), could sometimes cause the corresponding line breakpoint button in the source in the source viewer to light. This was incorrect, as the two lines have different sources despite the sharing the same line number. This problem has been fixed. Miscellaneous * Fixed DECLADEBUG 1820 - No valid breakpoint address for static member function. * Fixed DECLADEBUG 2152 - Fix up/down when using Ladebug under emacs. * Fixed DECLADEBUG 2170 - Assertion failed: stn src/st/mem/resolution.C 209. * Fixed DECLADEBUG 2196 - Backup PC by 4 confuses kernel debugging in extreme cases. * Included file level static variables in lookup results, if no other matches are found. * Tweaked traceback information to resemble dbx when $dbxoutputformat is set * Fixed DECLADEBUG 2228 - Indirecting through an invalid function pointer (NULL) caused a core dump that doesn't allow analysis of the user's code. * Fixed DECLADEBUG 2235 - The command set $lang was broken when used with no target. * Alphabetically ordered output from the whereis command. * Fixed DECLADEBUG 2239 - Bad echo of pthread commands. * Expanded fix for DECLADEBUG 1891 & 2169.1 - Covered operator functions, in addition to regular functions. * Fixed DECLADEBUGBUGS 2698 - Prevent paging mechanism from masking Ctrl-C output. * Fixed DECLADEBUG 2263 - A Ladebug SEGV when issuing the whatis command. * The printf command now works without requiring a target binary, and a format bug was fixed. * Fixed DECLADEBUG 2256 - Obscure symbol table bug. * Fixed DECLADEBUG 2260 - whereis and whatis should print full function signatures even if $statusargs is 0. * Fixed part of DECLADEBUG 2269 - Overloaded function selection for breakpoint. * When encountering a function which has no debug information, don't assume that the arguments are in the six standard argument registers and all still valid. Give a visual indication that there is no information. Problems fixed in Version 65 Crediting the wrong breakpoint When two breakpoints were triggered at the same time, and one of them was marked as quiet, Ladebug sometimes reported the quiet breakpoint as the reason for the stop rather than the non-quiet one. V65 fixes this anomaly (The original problem report is in DECLADEBUG 2059). Conducting symbol search in BLISS with case-sensitivity turned on This problem was reported in DECLADEBUG 2144. A BLISS language symbol should be searched for in a case-insensitive way. V65 fixes this problem. Duplicate native thread entries in the output of show thread The Ladebug debugger no longer displays duplicate native thread entries in the output of show thread. Miscellaneous * Fixed DECLADEBUG 2131 - Ladebug would crash while reading Coff Symbol tables where procedure signature entries are encountered within the description of a class. * Fixed DECLADEBUG 2113 - GUI preference window was too small. * Fixed DECLADEBUG 2139 - Assertion failure when reading unnamed symbols in debug info. * Fixed DECLADEBUG 2148 - Ladebug would crash when $threadlevel is set. * Fixed DECLADEBUG 2149 - Assert on some executables processed by the spike tool. * Fixed DECLADEBUG 2153 - Ladebug would SEGV when doing a next on an attached threaded application. * Fixed DECLADEBUG 2163 - Ladebug would crash due to a dangling reference within Ladebug. Problems fixed in Version 4.0-64 Ladebug assertion failure for "stabs" debug information Some libraries and the objects produced by some compilers produce debug information in records called "stabs". If an application is built using the COFF file format, the stabs will be encapsulated in COFF records which can sometimes have incorrect fields (for example, specifying a routine which didn't exist in the procedure descriptor table). Ladebug does not understand the stabs format, and would raise an assertion failure when it saw a COFF record with an incorrect field, ending the debugging session. Ladebug now checks for the existence of the symbol @stabs in a file; if it sees that symbol, it assumes that the file contains stabs encapsulated in COFF and will stop processing the debug information from that file. This means that the file's symbolic information will not be known, and that users will have to debug inside it at the machine-language level. patch command bug The patch command modifies the running program and the on-disk executable file as well. To allow users to revert back to the old file, Ladebug tried to save the original executable file by changing its name and copying it. Two patch commands in a row would defeat this: the original file would be replaced by the result from the first patch. This bug has been fixed. More recent versions of the operating system will prevent Ladebug from modifying the on-disk file when a process made from it is running. This can be worked around by moving the file to another name and then copying it back to the original name. This work-around is now part of the patch command's action. In an effort to be more comprehensible, the files have been given clearer names. If your original executable was named prog, the saved original is now named prog~backup. A temporary intermediate patched file resulting from the use of the work-around will be named prog~temp. The current patched file being debugged will be named prog. Accuracy in presenting floating point numbers Ladebug now shows the user all the decimal digits required to correctly represent the actual bit pattern in a float, double, or long double. Though the default presentation Ladebug used to use often leads to more "natural" looking numbers, correct presentation can be important. The default presentation of float is 6 digits, of double is 16, and of a long double is 33 digits; truthful presentation requires 9, 17 anbd 36, respectively. Before this fix, if the user had printed a value and used the result as an input to Ladebug, the resulting bit pattern might not be the same as that in the value printed. Here's a short example from Ladebug Debugger Version 4.0-63: (ladebug) p f 3.14159 (ladebug) assign f2 = 3.14159 # Cut-and-paste value from above (ladebug) p f2 3.14159 (ladebug) p f == f2 # They are unequal! 0x0 (ladebug) px f, f2 # And the actual bit patterns differ 0x40490fdb 0x40490fd0 and the correct result in Ladebug Debugger Version 4.0-64: (ladebug) p f # Show correct number of digits 3.14159274 (ladebug) assign f2 = 3.14159274 (ladebug) p f2 3.14159274 (ladebug) p f == f2 # They are equal, as they should be 0x1 (ladebug) px f,f2 # And the bits are equal 0x40490fdb 0x40490fdb For another example, if Ladebug were to use the default representation, some miscompares in user code might not be obvious. If the application's code had a compare using only the default six digits of precision, such as if (f == 3.14159) and the user used Ladebug to print the value of "f", then if "f" were printed with the default precsion, it might well be the case that "f"'s value would also be printed as 3.14159. But those two values might actually be different and the control expression would evaluate as false. Some actual possible values near 3.14159 are printed correctly as: 3.14159226 3.1415925 3.14159274 3.14159298 3.14159346 and yet each would be printed as 3.14159 using the default precision. This bug was reported by Steve Hobbs in DECLADEBUG 2024. The correct number of digits to present taken from ANSI IEEE standard 754-1985. Miscellaneous * Fixed DECLADEBUG 2000 - A bug in the calculation of octal values. * Fixed DECLADEBUG 1204 - Ladebug had problems printing union members. * Fixed DECLADEBUG 1947 - Ladebug would crash when switched to native thread mode while debugging a pthreads core file. * Ladebug on Alpha Linux can now identify the dynamic type of a pointer or reference. * Improved the Fortran common block support for Linux. Ladebug now knows the names of common blocks, and how to print both the whole block and its individual members. * We have fixed various problems with Ladebug's ability to call both C and Fortran functions. You can now call many Fortran functions. Ladebug doesn't support calls that require descriptors. * Fixed DECLADEBUG 2042 - Ladebug couldn't properly edit screen lines longer than 100 characters (approx). * Fixed DECLADEBUG 2043 - $i++ didn't change $i. Ladebug expressions involving setting debugger variables did not actually change their value. To change the value of a debugger variable, you had to use a set command. Now you can use expressions like $i++, although string assignment is not implemented (nor is it implemented for program variables). * Ladebug now supports the representation of addresses in the kseg segment, for use in kernel debugging, by the use of a 0k prefix followed by hexadecimal digits for the segment offset of the address. E.g., 0k123abc represents the address at offset 0x123abc in the kseg segment. * Fixed DECLADEBUG 2036 - Ladebug would throw an assertion failure when reading the symbol table of an atomized program. * Fixed DECLADEBUG 2068 - Ladebug used to print long double NaNs (Not a Number) as "NaNNaN.0" and long double Infinities as "InfinityI.nfinityE+07". This has been fixed. * Fixed DECLADEBUG 2074 - A fatal error which occured when $lang was set to "java". * Fortran array slicing and bounds checking now have better behavior. Work in this area fixed DECLADEBUG 2007 (an assertion failure while printing an array slice with member selection) and eliminated a crash described in DECLADEBUG 1671, although setting watchpoints on whole Fortran arrays or sections of Fortran arrays is still not supported. Problems fixed in Version 4.0-63 -I qualifier no longer needs a space The -I qualifier no longer needs a space between it and the directory entry, so users may cut and paste Ladebug command arguments from their compiler command line to the Ladebug command line. This was reported in DECLADEBUG 305. $threadlevel is a preference, not a command Setting $threadlevel now expresses a preference (which is sticky) rather than forcing the actual threadlevel to a level not currently supported by the application or the debugger. Reading $threadlevel shows the current thread level, which may not match your preference. Improved printing of unnamed unions in C++ classes For whatis Foo::u, where the type of u is an anonymous union declared within class Foo: Old Form New Form union Foo:: { union { int x; int x; char c; char c; } Foo::u; } Foo::u; This was reported in DECLADEBUG note 888. Miscellaneous * Fixed DECLADEBUG 1893 - C language struct members whose names began with "__" were being hidden from the user. * Fixed QAR 50164 - Ladebug could crash when debugging a target application which had a very deep stack (usually due to recursion). The crash was fixed, and some performance improvements for dealing with deep recursive call stacks were made. * Fixed selection from a namespace alias using the syntax aliasOfANamespace::member. * Fixed DECLADEBUG 1716 - Ladebug was not finding members of anonymous unions inside C++ classes. * Fixed QAR 33160 - Improve the way Ladebug outputs Cobol types and groups. * Fixed QAR 35734 - Ladebug didn't always correctly interpret the C++ global scoping operator (::). * Fixed QAR 49914 and QAR 49915 - Ladebug now adds symbols from the external symbol table to its internal tables when the symbols are not already there. This makes symbols like __istart visible. * Fixed QAR 52599 - Ladebug didn't deal with weak procedure symbols properly. * Ladebug required a running process before it would let users "call" a function, but it did not require one before attempting to print an expression including a function call. Such a call could lead to incorrect results and unexpected signals. Ladebug now checks for a runnable process when evaluating a call in an expression. * Fixed DECLADEBUG 1949 - Better handling of incomplete symbol table struct descriptions for the C language. * Fixed DECLADEBUG 1966 - The quiet specifier didn't make a breakpoint actually be quiet. * Fixed DECLADEBUG 1543 - Ladebug would SEGV when trying to run a process loaded as a core file. * Fixed DECLADEBUG 754 - whatis of a variable declared as being of a typedef type should report the typedef name, rather than the meaning of the typedef name. * Fixed DECLADEBUG 1839 - Several problems where Ladebug misunderstood the size of pointers and references in sources compiled with -xtaso_short. Problems fixed in the Ladebug Debugger Version 4.0-62 Debugging programs optimized with "Spike" If your application has been optimized by the "Spike" tool using performance feedback, and you debug the application, in certain cases the call stack will not be displayed fully by Ladebug. It will terminate too soon and may be incorrect. This is a libc error introduced in Tru64 UNIX V4.0D. This error will be fixed in a future Tru64 UNIX patch release and in the base kit for a future release of the OS. In the mean time Ladebug has been modified to work around this problem if it detects that the version of libc it is using is one with the problem. Problems fixed in the Ladebug Debugger Version 4.0-61 Miscellaneous * Overload pick-lists are now alphabetized. * The manual has been improved. * Ladebug now looks up C++ constructors and destructors are more correctly. * Ladebug now more correctly follows C++ rules about the visibility struct S {...} S; implies for struct S and S. * Ladebug handles C++ pointers and reference types more correctly. * Ladebug handles C++ rules about virtual and nonvirtual methods in derivation hierachies more correctly. * Ladebug now gets the correct result (4) for sizeof('a'). * A number of debugger internal errors leading to SIGSEGVs have been fixed. * Ladebug now does better echoing of strings with escaped characters, such as "ab\t\007cd". * Ladebug handles the C++ use of interludes more correctly. * Ladebug now does virtual dispatching calls correctly. class C { ... virtual int f() ... }; class D : public C { virtual int f() ... }; D d; C* p = &d; (ladebug) print p->f() will call D::f (ladebug) print p->C::f() will call C::f * Ladebug has more support for Fortran 90 optional arguments. * A bizarre consequence of the expression *&array ==- *&array[0] has been fixed. * A bug in which Ladebug acted as if $stopparentonfork were set when it was not has been fixed. * Ladebug handles use lists better. * Ladebug now issues a supplementary information line to distinguish variables that have no value because they were optimized away versus no value at the current PC (due to splitting). * The bug (LADEBUGBUGS 2641) which could consume all of memory when unloading or quitting from programs with lots of symbols has been fixed. * The obscure problem caused by the const qualifier being removed from a virtual function of a base class has been fixed. * Remote kernel debugging works again. * Support for a Zulu kernel trap frame change has been added. * An assertion failure posted in DECLADEBUG 1814 (due to incorrect information from the compiler for a C++ using directive that references an incomplete type) has been fixed. * The bug (DECLADEBUG 1752) of not recognizing nested classes as being the same when they were described by debugging information in different .o files has been fixed. Problems fixed in the Ladebug Debugger Version 4.0-59 Miscellaneous * Fixed many bugs in the echoing of commands when $pimode is set and record io is in effect (More work will be done in this area in the future). * Help text and man page text have been improved. * The continue command is accepted as meaning cont. * The syntax every procedure entry is accepted as meaning every proc entry. * Nested aliases now expand correctly. * Fixed DECLADEBUG 1624, SEGV when attempting to print a debugger variable. * Paging now works with the output of the printenv, setenv and export commands. * Fixed DECLADEBUG 1613, Ladebug can now cope with binaries joined via the shell command ostrip -j. * Fixed DECLADEBUG 1629, made namespace using declarations visible again * Fixed DECLADEBUG 1628, better handling of ignored signals under linux/ptrace. * Fixed DECLADEBUG 1625, C++ interlude functions are now less visible. * Fixed DECLADEBUG 1633, Ladebug now allows rerun when there are breakpoints in dlopen-ed code. * The "String is too long to display" error message now includes the name of the debugger variable. * Underscore ("_") is now a legal character in naming an environment variable. * Fixed DECLADEBUG 1619, the user is now warned that Ladebug does not support snapshotting threaded applications. * Fixed DECLADEBUG 1654, added detection of Symbol Table format error (incorrect procedure count). * Bugs which prevented remote kernel debugging capabilities have been fixed. * Bugs which prevented the patch command from working have been fixed. * Ladebug now allows the whereis ~destructor syntax. * Ladebug now allows patching a location not backed by a loadable file. * Fixed dropping of a comma when echoing printf commands. * Fixed DECLADEBUG 1675, a problem with breakpoints on class member functions when the application was compiled -g3. * Fixed a Ladebug SEGV with file command when no binary is loaded. * Ladebug now disallows startup if given an incorrect qualifier. * Ladebug now has better handling of unsupported startup qualifiers. * Fixed DECLADEBUG 1695, an interaction bug when the same instruction triggered both a breakpoint and a watchpoint. * Better handling for reinstating signal handlers after backtraces. * Better representation of C++ unnamed structs/unions. * Fixed DECLADEBUG 1695, watchpoints now work properly after a rerun. * Added class/struct/union label when displaying C++ nested types as members. * Better handling for debugging of core files with mismatched pthreads libraries. * Ladebug now warns users about debugger variables not starting with "$", and about overlaps between debugger variable names and user program names. * Added exit as an alias of the command quit. Problems fixed in the Ladebug Debugger Version 4.0-58 Miscellaneous * Fixed a bug in processing the output pagination control character. Problems fixed in the Ladebug Debugger Version 4.0-57 Miscellaneous * Fixed a bug in looking up a class member class which has opaque base classes. * Fixed DECLADEBUG 1603 - Allow evaluating a C++ struct member in a C context. * Fixed DECLADEBUG 1607 - In some situations, debug info entries for some alternate entry points actually preceed the debug info for the main entry point. This is a formatting error. Ladebug will report the error and work around the problematic entries, allowing the users to debug their program. * Fixed DECLADEBUG 1614 - Expand aliases in an alias definition correctly. * Allowed commands in the form of c, which are a shorthand for cont. * Initialized an uninitialed data field. Problems fixed in the Ladebug Debugger Version 4.0-56 Miscellaneous Version 4.0-55 segmentation faults if the binary given at the command line does not exist. 4.0-56 fixed this bug. Problems fixed in the Ladebug Debugger Version 4.0-55 Miscellaneous * Fixed QAR 71758 - Provide better local kernel debugging support. * Fixed DECLADEBUG 1076, 1249, 1591 (partial)- Support writing registers and memory when debugging core files. * Fixed DECLADEBUG 1486 - Fix a symbol table parsing bug. * Fixed DECLADEBUG 1566 - Expand leading tilde, include ~ and ~, and environment variables in file names. * Fixed DECLADEBUG 1569 - Add a preference for any symbol over a file name when they have the same name * Fixed DECLADEBUG 1582 - Fix a bug in looking up global variables. * Fixed DECLADEBUG 1584 - Allow the caller's stack to be in the "wrong direction" by large amounts. * Fixed DECLADEBUG 1590 - Handle long command string. * Fixed LADEBUGBUG 2321 - 'whereis' and 'stop in' can take a signature in C and C++ mode. * Fixed handling of 64-bit array indices as part of tqArray_64 support. * Made the command 'record output' switch a single tee, so that each overrides the earlier rather than the previous behavior where each was done as well as the earlier. Problems fixed in the Ladebug Debugger Version 4.0-54 Miscellaneous * Fixed QAR 70617 - Display SIGABRT instead of SIGIOT when they are the same. * Fixed DECLADEBUG 1521 - Provide better representation for array pointers * Fixed DECLADEBUG 1522 - Allow pointer arithmetics on an array reference * Fixed DECLADEBUG 1528 - Provide better tracing thru _OtsMove * Fixed DECLADEBUG 1529 - Fix crash while parsing external symbolic info * Fixed DECLADEBUG 1531 - Add control for printing of function arguments * Detaching a snapshot process is no longer allowed. Problems fixed in the Ladebug Debugger Version 4.0-52 * Multi-Threaded Debugging on Multi-CPU Systems * Attach and Detach * Language Understanding * Miscellaneous Multi-Threaded Debugging on Multi-CPU Systems Fixed numerous issues involving using breakpoints or watchpoints when debugging pthreads processes on Multi-CPU Systems. These often resulted in the process being debugged hanging, or receiving spurious signals, or dying upon detach. Attach and Detach Make attaching to a process be a lot more innocuous - no longer cause the process to make further progress, making it easier to debug hangs. Fixed BCGM113LM, TURRIS::DECLADEBUG note 1353.0: Detaching from a hung process also hung Ladebug. Language Understanding Fix the assertions and other problems associated with Fortran alternate entry point parameters and dynamic arrays. Fix some problems with the visibility of global identifiers. If we can't find main, set the initial scope to the universal scope. Fix an incorrect handling of -g3 level of debugging. This results in a more correct representation of fortran procedures compiled under -g3, going from function other2(integer*4, integer*8) to subroutine other2(integer*4, integer*8) If a procedure contains a static link, but the debugger is unable to find the ancestor frame referenced by that static link during a lookup, then warn the user. Miscellaneous * Fixed DECladebug 1443.0 - crashes caused by the show process command when the process changes. * Fixed some obscure problems with function calls that were corrupting Ladebug's stack occassionally, causing crashes. * When the user issues a SIGQUIT, exit quietly instead of printing a stack trace. This puts SIGQUIT inline with how Ladebug treats SIGTERM. * Don't crash when presented with a bad core file. * Fixes assertion failures, etc. when attempting to debug the kernel with insufficient privileges. * Fixed QAR 66003 - some crashes in the old GUI. * Fix some of the old GUI's problems with core files. * Fixed Assertion failed: !isTerminated() src/appl/procs/process.C 739 * Fix a memory leak. * Fix the SEGVs when "watch", which isn't available under ptrace, is used with ptrace. ------------------------------------------------------------------------ Problems fixed in the Ladebug Debugger Version 4.0-51 * Multi-threaded debugging * Core file debugging Multi-threaded debugging Release 4.0-50 has problems with debugging an attached multi-threaded processes and the setting of Ladebug variable $threadlevel. These problems are resolved in this release. Core file debugging Release 4.0-50 has problems similar to the aforementioned ones in debugging multi-threaded core files. They have been fixed in 4.0-51. ------------------------------------------------------------------------ Problems fixed in the Ladebug Debugger Version 4.0-50 * Core file debugging * Problems with classes and/or structs having the same identifier as variables * Problems with local variables and class data members having the same identifier * Limitation in print * Support for base classes * Breakpoint/Watchpoint handling * Assertion failures * Miscellaneous Core file debugging * Users who are debugging core files on a system different from the one on which the core file was created are "transporting" core files from an original system to a user system. For Ladebug to debug a transported core file, it needs access to the libraries used by the core file. A new environment variable is now used by Ladebug to support debugging transported core files. Before invoking Ladebug, copy the shared libraries used by the failing application on the original system into a directory on the user system. Set the environment variable LADEBUG_COREFILE_LIBRARY_PATH to that directory. You can now run Ladebug on the core file in a normal manner on the user system. This is necessary because core files do not include the contents of the libraries. They refer to them by pathname in a loader database inside the core file. Usually the pathnames are absolute pathnames for the original system's filesystem, such as "/usr/shlib/libc.so". On the user system, there may be not files with the specified pathname, or the file with that pathname may be a different version. If the file is different or absent, Ladebug will not be able to present the user with the correct view of the core file. All the relevant shared objects associated with the core file (those that would show up in the output of the listobj command if the user were debugging on the original system) must be in the local directory. Example: % setenv LADEBUG_COREFILE_LIBRARY_PATH applibs % ladebug a.out core At this point, the listobj command would show the shared libraries as being located in the "applibs" directory, rather than from the user system's directories. < End of example > For debugging transported corefiles of multi-threaded applications, it is prudent to put the shared objects used by the application in one subdirectory (e.g. "applibs", as shown in the previous example) and the pthread debug library (libpthreaddebug.so) in a separate directory (e.g. "dbglibs"). DO NOT PUT APPLICATION SHARED OBJECTS IN THE SECOND/DEBUG DIRECTORY! Then, to get Ladebug to use the correct libpthreaddebug.so library, point the LD_LIBRARY_PATH environment variable at its directory, % setenv LD_LIBRARY_PATH dbglibs before you run Ladebug. * Many problems with processing core files generated by processes that have been doing dlOpens have been fixed, and there is ongoing work in this area. Problems with classes and/or structs having the same identifier as variables This release fixes the problems related to classes and/or structs having the same identifier as variables, as shown in the following transcript: % ladebug a.out (ladebug) p s struct s { i = 0; } (ladebug) stop in main (ladebug) run (ladebug) W 1 2 struct s { int i; } s; 3 4 int main() 5 { > 6 return s.i; 7 } (ladebug) p s struct s { i = 0; } (ladebug) p s.i 0 (ladebug) p struct s struct s { int i; } Problems with local variables and class data members having the same identifier Ladebug no longer has problems when local variables and class data members have the same identifier, as demonstrated in the following transcript: (ladebug) W 1 class S { 2 public: 3 S():i(0){} 4 int i; 5 }; 6 7 void main() 8 { 9 int i = 10; 10 S* s = new S(); > 11 i++; 12 } (ladebug) p i 10 Limitation in print This release is able to print Bar::Foo where both Bar and Foo are types; it also accepts the command print , which has exactly the same behavior as whatis . Support for base classes We have been overhauling the support for both virtual and non-virtual base classes, and now many more of the fringe cases work properly. Meanwhile, Ladebug now correctly supports printing of dereferences of pointers to virtual base classes. Breakpoint/Watchpoint handling * Under obscure circumstances, previous versions of Ladebug would not actually remove the Breakpoints and Watchpoints when they were no longer needed, although they would be hidden from both the user and the process by the debugger. This merely slowed the process down. They are now fully removed. * As soon as the running process dies, Ladebug now returns the context back to before the program was run, so that breakpoints etc. can be specified for the next run. * Watchpoints now work even when the user has specified "ignore SEGV". Assertion failures This release fixes the following assertion failures: * src/st/file/parsesymscoff.C 3613 * The "isComplete()" assertion failure when dealing with classes generated by older C++ compilers without the beginning stTag entry. Also, we have replaced an assert with a warning message to allow users to continue debugging after encountering an unexpected TIR format (continued flag being set). This was caused by bad compilers/linkers but was showing up as a Ladebug problem. Miscellaneous * In this release, the message "Process has exited" is now put out more often, to remind you that run, rerun, and other commands can cause the current process to terminate. * Ladebug would crash under some circumstances if the environment variable LD_LIBRARY_PATH was set. This has been fixed. * The performance has been improved dramatically when printing deep call stacks. * Stack tracing now works through JIT'ed code, provided the JIT'ed procedures have been correctly registered with the exception system. * Variables whose lifetimes have been split by the optimizer are now more likely to be correctly evaluated. ------------------------------------------------------------------------ Problems fixed in the Ladebug Debugger Version 4.0-49 * Emacs support file * Ladebug Man Pages * Hard Partitioning Emacs Support File The emacs support file, ladebug.el, was missing from the 4.0-48 kit. It is now once again included in the Ladebug kits. Ladebug Man Pages The Ladebug man pages are normally installed as part of the OS installation and were not included in Ladebug kits. The current version of the Ladebug man pages are now included as part of the Ladebug kits in the LDBMAN subset. Hard Partitioning Ladebug better supports debugging in the presence of hard partitioning, which essentially partitions a single machine into what appears to software as multiple separate machines (each partition running its own copy of the OS). The issue was that physical memory doesn't start at address zero for secondary partitions, so debuggers were unable to find the Restart Parameter Block (RPB) for mapped kernels. A modified libdpi.a was supplied to the Ladebug project which allows debuggers to work on partitions transparently. ------------------------------------------------------------------------ Problems fixed in the Ladebug Debugger Version 4.0-48 * Performance Improvements * C++ * FORTRAN * Miscellaneous Performance improvements As part of our continuing work on Ladebug's memory usage and cpu usage, we have started delaying the loading of information about local variables until an explicit reference to the containing scope is made. Typically this happens automatically as part of the scope lookup. * In the case of the whereis command, local symbols may not be found. * A where command will load the local symbols of all the displayed scopes. * The performance of the stop, when and trace commands has been improved. Many memory leaks within these commands, and also within the watch command, have also been eliminated. C++ * Clear up Ladebug's confusion when a namespace and a class have the same name. * Fixed some problems in reading namespace related information from the a.out file. DECLADEBUG 1301. * Don't print C++ base classes inherited virtually more than once. Do print base classes once for each non-virtual base class. * Some C++ member-function-related crashes were fixed. Fortran * A common block that was defined in a shared library, but referenced from a different shared library, sometimes could not have its members examined. This has been fixed. * Fixed some problems with arrays passed-by-reference in the Fortran support Miscellaneous * Control-C now interrupts the debugger output and returns control to the user in the where comand, and many other cases. * Large character arrays are now handled better o We've put a control-C handler in the read loop(s) for strings. o Ladebug already has $maxstrlen, which limits the size of string that gets printed; however, it used to fetch to a null byte and then apply the limit. It will now check the limit in the loop, so that we don't waste time fetch bytes we're not going to print. * Fixed a problem resulting