| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2155.1 | post in turris::decladebug | DECC::MDAVIS | Mark Davis - compiler maniac | Mon Apr 21 1997 13:04 | 10 |
| You should (also) post your questions to the debugger notesfile.
As to the line number jumping around, if you compile and generate
an assembler listing, you will probably see the instructions for
your single statement labelled with line numbers 1,2,3; and the
instructions will be shuffled among one another.
The debugger is trying to tell you each time it is about to execute
an instruction from a line whose number is DIFFERENT from the current
line; so it looks like the line is being executed multiple times.
|
| 2155.2 | ECO patch for DECCC | DPPRIP::BOLLAND | | Thu May 29 1997 07:20 | 8 |
|
I've been told that I should install the ECO patch cc01055.a-dcx_axpexe
to get round this problem. I've done this but there is no difference !
Does anyone have any ideas ?
stephen
|
| 2155.3 | | LARAMS::VOGEL | | Thu May 29 1997 10:16 | 25 |
|
Stephen,
The problem reported in topic 1651 has not yet been corrected. On the
other hand it does not seem to be related to the problem you describe
in the base note.
The problem reported in topic 1651 deals with the debugger skipping
around while evaluating arguments for a function call when
those arguments appear on different physical lines. It's unclear
if the "skipping around" you are talking about in .0 is during
a function call or not.
In any case I do not see how this problem could cause your program to hang.
If possible, can you provide us with enough information so that we can
reproduce the problem? Also, Mark suggested you post this in the
DEBUG notes conference? If you posted it there, what is the topic
number?
Thanks,
Ed
|
| 2155.4 | sounds normal for optimized code... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu May 29 1997 10:58 | 14 |
|
Skipping around in the debugger is fairly common with optimized code,
and is rather more prevalent on OpenVMS Alpha. This behaviour is tied
in with the code generation for the instruction-level parallelism
performed at the microprocessor level.
Make sure you are using /NOOPTIMIZE with /DEBUG -- I've had "fun",
as you describe, with optmized code... Things are rather easier
to debug with the non-optimized code.
Given the run-time length for this application, I would look at
starting to instrument the code, and starting to implement various
support routines directly in the code to facilitate debugging...
(If you have not already done so...)
|
| 2155.5 | | DECCXL::OUELLETTE | mudseason into blackfly season | Thu May 29 1997 15:35 | 20 |
| The frontend of the DEC C compiler goes to heroic efforts to attribute
to each sub-expression its exact range of source text. The optimizer
then can do some magical transformations like removing duplicate code
and scheduling what's left. Generation of debug info for the instructions
emitted then reduces this to line number information (rather than beginning
and end of range) for each instruction. It can get rather hard to follow.
Debugging /noopt code is generally easier. But some times you have little
choice but debug the optimized code. Here understanding what optimizing
compilers do is your best help. Also helpful is the machine code listing
generated with /LIST/MACHINE or -source_listing -machine_code. In the .lis
files created that way will be an annotated machine listing describing
the instructions and the source lines attributed to each instruction.
/SWITCH=NO*SCHED* or -Wf,-switch,"no*sched*" can also be helpful in
that it disables scheduling, but keeps other optimizations. That's not
how you want to ship an application, but for some problems, it can speed
the debugging process.
R.
|