  ------------------------------------------------------------------------

                Compaq Ladebug for Compaq Tru64 UNIX Systems
                        Release Notes for Version 67

  ------------------------------------------------------------------------

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/exec
   * Perform remote client/server debugging
   * 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 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:
             + <number.exp> cont <signal>
             + conti to <address.exp>
        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 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:

    <address>/<count>M <value> <mask>       // 64-bit
    <address>?<count>M <value> <mask>       // 64-bit
    <address1>,<address2>/M <value> <mask>  // 64-bit
    <address>/<count>m <value> <mask>       // 32-bit
    <address>?<count>m <value> <mask>       // 32-bit
    <address1>,<address2>/m <value> <mask>  // 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 <number.exp> cont <signal>
        o conti to <address.exp>
   * 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:

          <unix prompt>ladebug -gui <other engine command line options
          and arguments>........or

          <unix prompt>ladebug <engine command line options and
          arguments> 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 <pid> [image-name-optional]

If the image name is not given, the image name of the current process is
assumed.

New dbx-compatible commands

<number.exp> cont <signal>

Continues the program execution and ignores the next (<number.exp>+1)
breakpoints.

conti to <address.exp>

Continues the execution of the process until the instruction at
<address-exp> 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
<Ctrl-a> to jump to the beginning of the command line and <Ctrl-e> 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 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 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
&ltvariable> 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 <signal>" command. When debugging a DECthreads
multithreaded application, and if the "cont <signal>" 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 <signal> catch <signal> ignore <signal>

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@compaq.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 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 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 <frame_name> 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 <class::method>).

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 <file
     symbol> 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 <n> c, which are a shorthand for <n>
     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
    <opaque> 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 <type name >, which has exactly the same
behavior as whatis <type name >.

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
