Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!spline!thomas
From: thomas%spline.uucp@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: comp.unix.wizards
Subject: Re: Problem with dbx on Sun3.1 (no executable code at line ...)
Message-ID: <2016@utah-gr.UUCP>
Date: Mon, 4-May-87 06:21:33 EDT
Article-I.D.: utah-gr.2016
Posted: Mon May  4 06:21:33 1987
Date-Received: Tue, 5-May-87 01:20:22 EDT
References: <2652@phri.UUCP>
Sender: news@utah-gr.UUCP
Reply-To: thomas%spline.UUCP@utah-gr.UUCP (Spencer W. Thomas)
Organization: Univ of Utah CS Dept
Lines: 26


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)