For full information about the Ladebug debugger, please refer to the following manual:
The IOSLDBxxx subsets are no longer shipped with Digital UNIX V4.0C and later releases.
There are no new features in this version of Ladebug. This is simply a bug fix release.
There are no new features in this version of Ladebug. This is simply a bug fix release.
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
The regular-expression form of the "whereis" command can now take
single-quoted characters surrounding the operand. For example:
(ladebug) whereis 'x'
(ladebug) whereis "x"
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).
Ladebug now allows loading of .o files and non-runnable kernel binaries for examination purposes.
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
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:
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.
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
(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
__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*)
$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.
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
(ladebug) print \U00000111_1
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.
$stoponattach debugger variable.if commandprint commandsThis 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 ]
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
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
printb command.
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)
In V65, the Ladebug debugger implements the next,
step and stepi operations several
times faster than before, equalling the performance of the
dbx debugger.
$floatshrinkingThis 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.
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.
$floatshrinkingFloating 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
For more detail on floating point representation, see ANSI IEEE standard 754-1985.
You can now use the print and whatis
commands with Fortran arrays, which were distributed using NUMA directives.
#'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.
#'
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.
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.
This release is primarily being made to provide a fix for a libc error that affects debugging programs optimized with "Spike".
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.
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;
}
Previously, to turn off recording, users had to set recording to /dev/null.
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->fnow 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
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()
(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 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.
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.
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.
This release is primarily being made due to demand for bug fixes. See the 4.0-57 Problems Fixed section for details.
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.
Ladebug evaluates the EDITOR environment variable to pick an editor. It will default to 'vi'.
This release is primarily being made due to demand for bug fixes. See the 4.0-56 Problems Fixed section for details.
(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.
This release is primarily being made due to demand for bug fixes. See the 4.0-55 Problems Fixed section for details.
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.
This release is primarily being made due to demand for bug fixes. See the 4.0-54 Problems Fixed section for details.
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.
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:
Caveats and Tips
- <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.)
- A lot of functionality is still not implemented
- 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
- 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.
attach <pid> [image-name-optional]If the image name is not given, the image name of the current process is assumed.
% 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
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.
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.
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.
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.
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.
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
This release is primarily being made due to demand for Namespace support by C++ developers and as a vehicle for fixing bugs.
This situation arises for compilations using the -g0 qualifier.
This release is primarily being made due to demand for Namespace and Template support by C++ developers.
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 (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.
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.
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.
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): OSFBIN410When 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".
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.
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
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.
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.
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.
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.
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.
The Fortran compiler now issues
debug information for module usage,
but it does not do so for anonymous main programs. This means that for
a program like the one below, where the module M is defined
in a separate source file, Ladebug will not be able to find variable
I.
use M
I = 99
end
There is a work-around: use the PROGRAM statement in your Fortran
program to give the program a name:
program USE_M
use M
I = 99
end USE_M
Please note that this is not a Ladebug problem; should the Fortran compiler bug be fixed, Ladebug will be able to debug these programs.
For a list of additional known problems with version 69 see known problems with Version 68.
There are no new known problems with Ladebug version 68.
For a list of additional known problems with version 68 see known problems with Version 67.
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.
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.
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
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
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!
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.
For a list of known problems with version 4.0-64, see the known problems with Version 4.0-63.
For a list of known problems with version 4.0-63, see the known problems with Version 4.0-62.
For a list of known problems with version 4.0-62, see the known problems with Version 4.0-61.
% limit datasize 500000Very 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.
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: 6bfa800147ff0400Writes 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 quitYou can also put this in /etc/sysconfigtab as:
vm: vm-mapentries = 20000When a patch to the Unix kernel is available, it will be released through the normal channels.
Within Ladebug, this problem most often arises due to the use of the stop <variable> command. Delete any such commands and use watch instead; the problem may go away and you will be able to continue debugging. Note that there will be warnings when the 'stop' is deleted.
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.
To work around this problem, set a breakpoint inside function B before it is called.
This memory leak has been greatly reduced in the 4.0-36 version of the debugger.
Internal Error : dbg$search_for_rout : No valid routine at PC = X
"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.
Similarly, the stepi and nexti commands execute machine instructions based on the current thread context.
cont <signal> catch <signal> ignore <signal>
show thread
patch command bug
-I qualifier no longer needs a space$threadlevel is a preference, not a commandC++ classes
A number of bugs in the handling of debug information records
for the Fortran langauge Module feature have been
fixed in this release. As a result, debugging of Fortran code
which contains uses of the Module feature should be
much easier.
This work was done in parallel with work on the Fortran compiler
itself, fixing bugs in the compiler's generation of the debug
information records for the Module feature.
It is therefore necessary to use a new compiler as well as a
new Ladebug to get the improved debugging capability. This support
is in Fortran version 5.5A or greater.
There is still a known problem with the Fortran compiler which has an impact on debugging with Ladebug.
-names as_is When the user's context is a Fortran-language program,
Ladebug does symbol look-up in a caseless manner, because
Fortran is a caseless language. The Fortran compiler now
has a flag, "-names as_is", which causes the
compiler to be case-sensitive. Users can specify
-names lowercase and -names uppercase as well,
which can cause similiar problems.
Use of this flag means that names are not caseless. Ideally debugger look-ups should be done in a appropriately case-sensitive manner when the current context is in a file compiled with one of the values of that flag.
The Fortran complier does not tell Ladebug which files should be
treated this way, so Ladebug will search for names
in both caseless and case-sensitive manners, preferring
the caseless names. While only partial support for the
-names as_is feature, this change may assist users
in debugging Fortran programs which are case-sensitive.
In particular, when the user specifies a Fortran module
variable using its link-name (i.e. using the pattern
$<a-module-name>$<a-variable-name>,
of which an example is $FooMod$Bar),
Ladebug will now look up the name in a case-sensitive manner; this lets
users find module variables in files compiled with
-names as_is even if the caseless form of the
name specifies a completely different variable in a different
module.
set $pimode=1") the Fortran logical operator
".NOT." would be echoed using the C-language "!"
logical operator.
It is now echoed correctly as ".NOT.".
Similar changes were made for .AND.,
.OR. and .XOR.xtaso_short value to a
Ladebug-initiated call.
printt command now indicates that time is
based on UTC rather than GMT.
whereis "^t*".
whereis xalloc.
$curthread changes when
$threadlevel changes.
return <frame_name>
sometimes fails.
stop in all
<class::method>).
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() {}
}
}
foo.
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)
(ladebug) print &i
$r6
(ladebug)
$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.
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.
DECLADEBUG 1820 - No valid breakpoint address for
static member function.DECLADEBUG 2152 - Fix up/down when using Ladebug
under emacs.DECLADEBUG 2170 - Assertion failed:
stn src/st/mem/resolution.C 209.DECLADEBUG 2196 - Backup PC by 4 confuses kernel
debugging in extreme cases.$dbxoutputformat is setDECLADEBUG 2228 - Indirecting through an invalid
function pointer (NULL) caused a core dump that doesn't allow analysis of
the user's code.DECLADEBUG 2235 - The command set $lang
was broken when used with no target.whereis command.DECLADEBUG 2239 - Bad echo of pthread
commands.DECLADEBUG 1891 & 2169.1 - Covered operator
functions, in addition to regular functions.DECLADEBUGBUGS 2698 - Prevent paging mechanism from
masking Ctrl-C output.DECLADEBUG 2263 - A Ladebug SEGV when issuing the
whatis <file symbol> command.printf command now works without requiring a
target binary, and a format bug was fixed.DECLADEBUG 2256 - Obscure symbol table bug.DECLADEBUG 2260 - whereis and
whatis should print full function signatures even
if $statusargs is 0.DECLADEBUG 2269 - Overloaded function
selection for 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).
This problem was reported in DECLADEBUG 2144. A BLISS language symbol should be searched for in a case-insensitive way. V65 fixes this problem.
show thread The Ladebug debugger no longer displays duplicate native thread
entries in the output of show thread.
DECLADEBUG 2131 - Ladebug would crash while reading Coff Symbol tables where procedure signature entries are encountered within the description of a class.
DECLADEBUG 2113 - GUI preference window was too small.
DECLADEBUG 2139 - Assertion failure when reading unnamed symbols in debug info.
DECLADEBUG 2148 - Ladebug would crash when $threadlevel is set.
DECLADEBUG 2149 - Assert on some executables processed
by the spike tool.
DECLADEBUG 2153 - Ladebug would SEGV when doing a
next on an attached threaded application.
DECLADEBUG 2163 - Ladebug would crash due to a dangling reference within Ladebug.
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.
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
(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.14159346and 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.
DECLADEBUG 2000 - A bug in the calculation of octal values.
DECLADEBUG 1204 - Ladebug had problems printing union members.
DECLADEBUG 1947 - Ladebug would crash when switched to native
thread mode while debugging a pthreads core file.
DECLADEBUG 2042 - Ladebug couldn't properly edit screen lines
longer than 100 characters (approx).
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).
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.
DECLADEBUG 2036 - Ladebug would throw an assertion failure when
reading the symbol table of an atomized program.
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.
DECLADEBUG 2074 - A fatal error which occured when $lang
was set to "java".
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.
-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.
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.
DECLADEBUG 1893 -
C language struct members whose names
began with "__" were being hidden from the user.
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.
aliasOfANamespace::member.
DECLADEBUG 1716 - Ladebug was
not finding members of anonymous unions inside C++ classes.
QAR 33160 - Improve the way Ladebug outputs Cobol types and groups.
QAR 35734 - Ladebug didn't always correctly interpret
the C++ global scoping operator (::).
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.
QAR 52599 - Ladebug didn't deal with
weak procedure symbols properly.
DECLADEBUG 1949 -
Better handling of incomplete symbol table struct descriptions
for the C language.
DECLADEBUG 1966 -
The quiet specifier didn't make a breakpoint actually be quiet.
DECLADEBUG 1543 -
Ladebug would SEGV when trying to run a process loaded as
a core file.
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.
DECLADEBUG 1839 -
Several problems where Ladebug misunderstood the size of pointers
and references in sources compiled with -xtaso_short.
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.
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
Fixed BCGM113LM, TURRIS::DECLADEBUG note 1353.0: Detaching from a hung process also hung Ladebug.
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.
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.
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_PATHto 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 coreAt 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 dbglibsbefore you run Ladebug.
% 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;
}
(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
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.