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

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: 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:

These release notes are broken down into the following subsections:

2 New Features

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 65

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.

New debugger variables for supporting dbx compatibility

Two new debugger variables are added to support dbx compatibility:

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

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

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

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

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

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.

Improvements to GUI

GUI improvements:

Improvements to performance

Performance improvements:

Miscellaneous improvements

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

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

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

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: 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

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, 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

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

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

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

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

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

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

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

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

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

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

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. 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

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 and 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

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: 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:

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

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:

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

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.

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...

Also for this reason, Ladebug accepts expressions that Fortran would not... 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
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 65

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 65, 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: 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

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): 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)

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

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

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]"

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

For remote debugging, no commands are supported that make use of signals; in particular:

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 let us know. 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):

5 Problems fixed

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

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

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

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

Problems fixed in the Ladebug Debugger Version 4.0-59

Miscellaneous

Problems fixed in the Ladebug Debugger Version 4.0-58

Miscellaneous

Problems fixed in the Ladebug Debugger Version 4.0-57

Miscellaneous

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

Problems fixed in the Ladebug Debugger Version 4.0-54

Miscellaneous

Problems fixed in the Ladebug Debugger Version 4.0-52

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

Problems fixed in the Ladebug Debugger Version 4.0-51

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

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

Assertion failures

This release fixes the following assertion failures: 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

Problems fixed in the Ladebug Debugger Version 4.0-49

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

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. Many memory leaks within these commands, and also within the watch command, have also been eliminated.

C++

Fortran

Miscellaneous

Problems fixed in the Ladebug Debugger Version 4.0-47

Shared library handling

C++

FORTRAN

A number of problems in handling alternate entry points and COMMON blocks which lead to assertions were fixed:

Miscellaneous

Compilers are now putting out debugger symbol table information for procedures that have been optimized out of existence. Ladebug now supports this information--previously it crashed.

We have reduced the amount of memory leaked during the execution of the command 'stop <variable-name>'. We still strongly recommend using the command 'watch variable <variable-name>' instead. 

Problems fixed in the Ladebug Debugger Version 4.0-46

C++

FORTRAN

GUI

Miscellaneous

Problems fixed in the Ladebug Debugger Version 4.0-44

Fortran

C and C++

 Threads and Timers

Added a workaround for a kernel bug which affects debugging a program with timers. (DECL 852)
 

Miscellaneous

Performance

Drastically improved the performance of Ladebug when a trace or stop command requires a breakpoint on hundreds or more of procedures. We are continuing work in this area, especially for the initial execution of the command.

Problems fixed in the Ladebug Debugger Version 4.0-43

C++ Class support

Watchpoints

FORTRAN

COBOL

GUI

Interrupt Handling

Unsigned Arithmetic

Single-stepping on v3.2 Systems