chupa@vax1.acs.udel.EDU (Michael A Chupa) (04/07/90)
I would like to start my students using a debugger, and am presently using
Turbo Pascal & macsbug. In the TP manual, the {$D+} compiler directive is
documented as providing additional code to allow user breaks to display the
procedure name in which the call to macsbug occurred. When we run programs
with the compiler directive, we are still finding macsbug reporting that there
is "no procedure name." Any hints as to what the difficulty is, and how to
fix it?chaffee@reed.UUCP (Alex Chaffee) (04/10/90)
In article <5994@udccvax1.acs.udel.EDU> chupa@vax1.acs.udel.EDU (Michael A Chupa) writes: >I would like to start my students using a debugger, and am presently using >Turbo Pascal & macsbug. In the TP manual, the {$D+} compiler directive is >documented as providing additional code to allow user breaks to display the >procedure name in which the call to macsbug occurred. When we run programs >with the compiler directive, we are still finding macsbug reporting that there >is "no procedure name." Any hints as to what the difficulty is, and how to >fix it? Well, I don't use Turbo Pascal, but in Think C, a function without a procedure name can be given one by declaring a dummy local variable. This makes sure that the function has a stack frame (LINK and UNLK instructions bracketing the function, if you speak that language), which is what MacsBug uses to find the function's name. I believe this may be a bug in MacsBug, because even for functions with no local variables, Think puts in LINK $0000 and UNLK properly. Is there a reason why Macsbug would discriminate against LINK $0000's? Of course, if the procedures in question already have local variables, I'm stumped. -- Alex Chaffee chaffee@reed.{UUCP,BITNET} Reed College, Portland OR 97202 ____________________