| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 950.1 | might be looking for end of previous line first... | SMURF::PETERT | rigidly defined areas of doubt and uncertainty | Fri May 09 1997 13:48 | 9 |
| Well, there's a line 21, but it's a bit mucked up since it exists for
one instruction inbetween instances of line 19. Does dbx allow
you to set a breakpoint there? Not that I expect a lot of use
from dbx on a c++ file, but for something as simple as setting
a breakpoint, it should give an indication whether or not this is
a general problem for all debuggers or just ladebug in particular.
PeterT
|
| 950.2 | | DECC::OUELLETTE | mudseason into blackfly season | Fri May 09 1997 16:22 | 31 |
| I'm not sure what's up here & I need your help to (perhaps) get GEM to
generate a decent .o file or get the debuggers to do something reasonable
with the files as they stand.
cosf> dbx matt3
dbx version 3.11.12
Type 'help' for help.
main: Source not available
(dbx) use .
(dbx) stop in main
[2] stop in main
(dbx) run
[2] stopped at [main:19 ,0x120001100] for (i=0; i<10; i++);
(dbx) stop at 21
beyond end of file at line "matt3.cxx":21
(dbx) n
warning: "matt3.cxx":21 has no code associated with it
[main
warning: "matt3.cxx":21 has no code associated with it
:21 +0x20001115,0x120001114] return 0;
(dbx) n
[main:19 +0x18,0x120001118] for (i=0; i<10; i++);
(dbx) n
Program terminated normally
(dbx) quit
|
| 950.3 | | GEMGRP::MONTELEONE | | Fri May 09 1997 20:02 | 46 |
|
This works for me:
gemeun> lad d.out
Welcome to the Ladebug Debugger Version 4.0-35
------------------
object file name: d.out
Reading symbolic information ...done
(ladebug) bp main
[#1: stop in int main(void) ]
(ladebug) r
[1] stopped at [int main(void):4 0x1200018e0]
4 for (i=0; i<10; i++);
(ladebug) stop at 6
[#2: stop at "d.cxx":6 ]
(ladebug) c
[2] stopped at [int main(void):6 0x1200018f4]
6 return 0;
The line number table is different, though:
Procs(1 entries, only those with a symbol print):
0. ( 1) main, iline= 0x0, regmask=0x00000000, save_reg_offset 0x1a
fregmask 0x00000000, save_freg_offset 0x0, low_line 0x1,
high_line 0x7
frame_size 0x0, proc_addr 0x0000000000000000
Lines:
0. 4 1. 4 2. 4 3. 4
4. 4 5. 6 6. 7 7. 7
I used the currently built C++ compiler in the GEM area.
You should take a close look at the locators - the line number table
is derived directly from the locators.
I cannot offer any insight as to why the debuggers behave as they
do with the line number table posted in the basenote.
Bob
|
| 950.4 | | GEMGRP::MONTELEONE | | Fri May 09 1997 20:05 | 11 |
|
Also, take a look at the procedure descriptor, examining the low
and high line number values. If there is a line number which falls
outside the bounds of this range, then I could see where the debuggers
could have a problem. If this is the case, then the problem is almost
certainly related to locators.
Bob
|
| 950.5 | | DECC::OUELLETTE | mudseason into blackfly season | Fri May 09 1997 22:03 | 3 |
| OK. This is my problem. I see where I've gone wrong now...
R.
|