There is a little known "dump" command in dbx.
It gives the list of local names dbx does know the values for at the given
point.
my 2 cents,
Alexander
On Wed, 28 Apr 2010, Maxim Kartashev wrote:
I should've made longer answer even longer... Of course, source-level debugger
is almost entirely useless if it can't provide values of variables; and
sometimes dbx can do that, but sometimes it can't. Why don't you give it a try
and see for yourself?
And why don't I copy that optimized-code topic from dbx online help here:
optimized-code (topic)
When programs are compiled with optimization and debugging enabled
at the same time (-O -g), dbx operates in a restricted mode.
The details about which compilers emit which kind of symbolic
information under what circumstances is considered an unstable
interface and likely to change from release to release.
Source line information is available, but the code for one source line
may appear in several different places for an optimized program, so
stepping through a program by source line will result in the "current line"
jumping around in the source file, depending on how the code was scheduled
by the optimizer.
Tail call optimization can result in missing stack frames when the last
effective operation in a function is a call to another function.
Generally, symbolic information for parameters, locals, and globals is
available for optimized programs. Type information about structs, unions
and C++ classes, and the types and names of locals, globals and parameters
should be available. The C++ compiler will not provide symbolic
type information about locals, but the C compiler will.
Information about the location of parameters and locals is sometimes
missing for optimized code. If dbx cannot locate a value, it will
report that. Sometimes the value may disappear temporarily, so
try to single-step and print it again. If you stop at the first
instruction of an optimized function, dbx can print the values of
parameters, because the values will be in ABI-conforming registers
or stack locations.
The most recent Sun compiler for SPARC machines provides the information
for locating parameters and locals. Newer versions of gcc also provide
this information. The most recent Sun compiler on x86 and older Sun
compilers do not provide this information.
Global variables may be printed and assigned to as normal, although
they might have inaccurate values if the final register-to-memory store
has not happened yet.
The sections Inlining of Functions and Parallelization in the the Sun Studio
Performance Analyzer manual contain additional information that might
be helpful when debugging an optimized program.
For OpenMP programs, compiling with -xopenmp=noopt instructs the compiler
not to apply any optimizations, however the optimizer still processes
the code in order to implement the OpenMP directives. This means there
are still some of the above problems in programs that were compiled
with -xopenmp=noopt.
ольга крыжановская wrote:
The values and names of local variables are the data I require, so the
answer is more like 'no', right?
Olga
2010/4/28 Maxim Kartashev <[email protected]>:
Short answer is yes.
Long answer is longer:
1. Use *latest* version of
- compiler that generates debug info (-g -O)
- dbx that reads and processes it
2. Expect certain limitations (such as inability to print arbitrary local
variable)
3. See `help optimized-code' in dbx
ольга крыжановская wrote:
Does dbx have an option to debug optimized Sun Studio code at source level?
Olga
_______________________________________________
tools-compilers mailing list
[email protected]
_______________________________________________
tools-compilers mailing list
[email protected]
