Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!thirdi!peter
From: peter@thirdi.UUCP (Peter Rowell)
Newsgroups: comp.unix.questions
Subject: Re: dbx screwing up...
Keywords: dbx
Message-ID: <458@thirdi.UUCP>
Date: 16 May 89 00:29:33 GMT
References: <1666@eric.mpr.ca> <14490@duke.cs.duke.edu>
Reply-To: peter@thirdi.UUCP (Peter Rowell)
Organization: Third Eye Software, Menlo Park, CA
Lines: 32

In article <14490@duke.cs.duke.edu> apte@helios.UUCP (Jitendra Apte) writes:
>In article <1666@eric.mpr.ca> parker@waters.mpr.ca (Ross Parker) writes:
>>
>>We have seen a bizarre problem with dbx ...
>>the source displayed with 'list' is not always the first executable line ...
>
>I have experienced similar problems, and was wondering ...
>
>While stepping through a program, dbx says that it is at line number
>"XYZ" whereas control is actually a few lines ahead of "XYZ". It
> ...

More than likely it you have one (or more) invocations of a macro that
takes 2 or more args. If you have a newline inside of the argument
list, the cpp on many BSD systems (SysV, also?) will lose count of
which source file line it is on.  It normally happens that a #line
directive is generated by cpp with the wrong line number.  Since this
is the info dbx (and any other source level debugger) is using for
mapping address <=> line number, you can see why things look strange.
As always, your macroage may vary.

E.g.

#define TakesTwo(a,b) a=b
TakesTwo(foo, bar)		/* this is fine */
TakesTwo(foo,			/* <<== this causes the problem */
bar)

----------------------------------------------------------------------
Peter Rowell				peter@thirdi.UUCP
Third Eye Software, Inc.		(415) 321-0967
Menlo Park, CA  94025   		"No! Not the cat!"