Re: Does dbxtool + ESQL/C = works together?

In article <CC0qML.4C6@cbfsb.cb.att.com>, ashaw@cbnewsg.cb.att.com (andrew.shaw) writes: > From article <24tlujINNfuk@rave.larc.nasa.gov>, by goodrich@lynx.larc.nasa.gov (Mike Goodrich): > > > > The subject line says it all. Has anyone determined how to make > > dbxtool (or dbx) properly list the source code while debugging? > > Thanx in advance... > > > > I never have, but maybe someone else has. I have tried re-synching > the line numbers in the source file (#line %C%, if you use SCCS), > but with only limited success. > > Andrew Shaw Similarly, I've had a lot of fun with xdb [HP's version of sdb]. As Andy points out, adding line directives can help. Usually I don't bother, however. XDB has a nice capability of debugging on procedure calls [it's been so long since I've used sdb that I forget if that holds true for it, and I have no idea about dbx - if not, then too bad]. So I add a dummy function call at places where I really want a break point, and then set the procedure call breakpoint... This at least gets me to a known starting point. Another alternative, is to get C output from ESQL, and debug that - I VERY rarely do that, and I'll admit that the code is UGLY [but it's not nearly as bad as what C++ gives you when you try to turn that into C]. Perhaps the presence of the intermediate C file will help the debugger. [It's worth a shot]. Standard disclaimers apply - I hope that this is of some help Ihor Kinal att!cbnewsh!ijk [What's really strange in an ESQL file is if you don't use host variables, then INFORMIX doesn't include line directives to get line numbers back in sync. We happen to have a special file where that was true, and the resulting line numbers were off by HUNDREDS. Really blew my mind when I tried to debug it. The things I go thru to get my job done ... If my boss only knew. The fix was simple - I just included a dummy host variable.]