dbx screwing up...

Peter Rowell peter at thirdi.UUCP
Tue May 16 10:29:33 AEST 1989


In article <14490 at duke.cs.duke.edu> apte at helios.UUCP (Jitendra Apte) writes:
>In article <1666 at eric.mpr.ca> parker at 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 at thirdi.UUCP
Third Eye Software, Inc.		(415) 321-0967
Menlo Park, CA  94025   		"No! Not the cat!"



More information about the Comp.unix.questions mailing list