roy@phri.UUCP (Roy Smith) (04/30/87)
On our sun-3's running Sun3.1, we sometimes have dbx refuse to set
a breakpont at a given line, complaining "no executable code at line ..."
when there certainly *is* code there. For example:
Script started on Tue Apr 28 17:11:57 1987
alanine% dbx ribosome
Reading symbolic information...
Read 1272 symbols
(dbx) list 160,180
160 frames[0] = 1;
161 frames[1] = frames[2] = 0;
162 }
163 }
164
165 /*
166 * Flag parsing done. If there are args left, the first is
167 * a file name for input. If no more args, read from stdin.
168 */
169 if (argc > optind)
170 {
171 if ((sfp = seqopen (argv[optind])) == NULL)
172 xerror ("can't open sequence file %s", argv[optind]);
173 }
174 else
175 sfp = seqopen ("-");
176
177 if ((seq = getseq (sfp, SF_BASE)) == NULL)
178 xerror ("error reading sequence");
179
180 bpl = aapl * 3;
(dbx) stop at 169
warning: Event 1 not found
no executable code at line "ribosome.c":169
(dbx) quit
alanine% [control-D]
script done on Tue Apr 28 17:12:35 1987
It doesn't always happen, but when it does it seems to be
repeatable. The same thing happens if you select a line in the source
window and hit the "stop at" button in dbxtool. Does anybody have any idea
what's going on?
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
"you can't spell deoxyribonucleic without unix!"thomas%spline.uucp@utah-gr.UUCP (Spencer W. Thomas) (05/04/87)
There used to be a bug in the pre-processor (one that I fixed a long
time ago) that incorrectly passed line numbers on to the compiler when
you invoked a macro with newlines in its actual arguments (e.g. if you
said
putc( '\n',
stdout )
).
If all your line numbers are consistently off, and if the compiler
reports errors on the wrong line (if you insert a syntax error on line
169, but get it reported on line 173, for example), then this is
probably your problem.
The other possible cause is that dbx will usually insist that the
"executable code" occurs on the last line of a multi-line statement.
This doesn't seem to be the case in your situation, though.
Where can you set a breakpoint so that it breaks on that line? If you
single step, does it hit line 169? You could insert printfs, and see
how they correspond to dbx's concept of the line number. Have you
tried setting a breakpoint on 168 or 170?
Hope some of this is helpful. Let us know what you discover.
=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@cs.utah.edu)sdo@ursa.UUCP (05/04/87)
In article <2652@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > On our sun-3's running Sun3.1, we sometimes have dbx refuse to set >a breakpont at a given line, complaining "no executable code at line ..." >when there certainly *is* code there. For example: This is most likely caused by the inclusion of executable code from a header file (this at least is one way in which it is caused, though of course there might be others). For example: ----file defs.h------ #include <stdio.h> #define TRUE (1) #define FALSE (0) #ifndef lint static char *defssccsid = "%W% INCLUDE FILE %G%"; #endif ----------source file---------------- #include "defs.h" main() etc. What happens is that the line control information produced by 3.[01] of cpp is incorrect, so that you can't set breakpoints where you think you ought to be able to. This bug is fixed in 3.2. -- Scott Oaks Bear Stearns (212) 952-3164 {convex, sunrise, cuctr}!ursa!sdo