nala@ihlpl.ATT.COM (A. Flora-Holmquist) (05/06/88)
I am a new IIgs programmer and purchased the APW shell, C compiler, and APW debugger. The debugger is a machine level debugger, the C compiler to the best of my reading does not/will not produce an assembly listing. If I need to debug a C program it appears that sprinkling DrawCString in the code is my only choice. Have I missed something obvious in the APW documentation that addresses debugging C programs with the APW debugger? Any hints? It seems so obvious that a compiler should support some debugger that I can't believe the APW C compiler/APW debugger combination is useless. Thanks for the help. Al Flora-Holmquist ihnp4!ihlpl!nala
arenberg@trwrb.UUCP (Jeff Arenberg) (05/06/88)
In article <4827@ihlpl.ATT.COM> nala@ihlpl.ATT.COM (A. Flora-Holmquist) writes: >I am a new IIgs programmer and purchased the APW shell, C compiler, and >APW debugger. The debugger is a machine level debugger, the C compiler >to the best of my reading does not/will not produce an assembly listing. >If I need to debug a C program it appears that sprinkling DrawCString >in the code is my only choice. Have I missed something obvious in the >APW documentation that addresses debugging C programs with the APW >debugger? Any hints? It seems so obvious that a compiler should support >some debugger that I can't believe the APW C compiler/APW debugger >combination is useless. > >Thanks for the help. > >Al Flora-Holmquist >ihnp4!ihlpl!nala Regretfully you are quite accurate in your assessment. For C code, the debugger is practically useless. (No, you didn't miss anything in the documentation :-( ) A big part of the problem is all of the startup code that is inserted when you link in 2/start. If you can find the end of that code, and the beginning of yours, and insert a break at that point, then you have a better chance of tracing your code. About the only way I know of doing this is to look for Toolbox traps. I look for the calls to Init each toolbox and assume I'm close. Of course this approach is useless if you aren't using toolbox calls, like when converting Unix source code. If anyone knows a better way, *PLEASE* say something. Jeff Arenberg ------------------------------------------------------------ UUCP : ( ucbvax, ihnp4, uscvax ) !trwrb!trwcsed!arenberg ARPA : jarenberg@ecla.usc.edu GEnie: shifty ------------------------------------------------------------
wombat@nuchat.UUCP (Scott Lindsey) (05/07/88)
From article <4827@ihlpl.ATT.COM>, by nala@ihlpl.ATT.COM (A. Flora-Holmquist): > I am a new IIgs programmer and purchased the APW shell, C compiler, and > APW debugger. The debugger is a machine level debugger, the C compiler > to the best of my reading does not/will not produce an assembly listing. It's really hard to get away from assembly on the GS. I don't view APW C as a terribly viable development tool for a number of reasons... one being the necessity of assembly-level debugging. In answer to your question, APW comes with a utility called DUMPOBJ, which can be used to produce code listings from .ROOT files. Good luck. -- Scott Lindsey uunet!nuchat!wombat | These are _my_ opinions. StyleWare, Inc. | 5250 Gulfton 2E | It was a cold night for alligators Houston, TX 77081 | ... a cold night for dogs.
LMB7421@RITVAX.BITNET (05/09/88)
>From: "A. Flora-Holmquist" <ihnp4!ihlpl!nala@ucbvax.berkeley.edu> >Subject: APW C debugging question >I am a new IIgs programmer and purchased the APW shell, C compiler, and >APW debugger. The debugger is a machine level debugger, the C compiler >to the best of my reading does not/will not produce an assembly listing. >If I need to debug a C program it appears that sprinkling DrawCString >in the code is my only choice. Have I missed something obvious in the >APW documentation that addresses debugging C programs with the APW >debugger? Any hints? It seems so obvious that a compiler should support >some debugger that I can't believe the APW C compiler/APW debugger >combination is useless. The executable code is what you use in the debugger...there isn't a macro assembly debugger (yet), so you have to know mini-assembler...I usually debug using certain key code...toolbox calls, ProDOS calls, compares, etc. The debugger appears to be built for low-level assembly freaks (no, this isn't a cutdown on people programming in assembly or, god forbid, machine language - I do it myself :-), however, a C program is within reason. >Al Flora-Holmquist >ihnp4!ihlpl!nala Les Barstow LMB7421@RITVAX.BITNET rutgers!rochester!ritcv!ultb!lmb7421.UUCP 292 Kimball Drive Rochester, NY 14623 .USSnail
jsnow@esunix.UUCP (John Snow) (05/10/88)
From article <791@trwcsed.trwrb.UUCP>, by arenberg@trwrb.UUCP (Jeff Arenberg): > > Regretfully you are quite accurate in your assessment. For C code, the > debugger is practically useless. (No, you didn't miss anything in the > documentation :-( ) A big part of the problem is all of the startup code > that is inserted when you link in 2/start. If you can find the end of > that code, and the beginning of yours, and insert a break at that point, > then you have a better chance of tracing your code. About the only way I > know of doing this is to look for Toolbox traps. I look for the calls to > Init each toolbox and assume I'm close. Of course this approach is > useless if you aren't using toolbox calls, like when converting Unix > source code. > > If anyone knows a better way, *PLEASE* say something. > There is a much easier way to find the beginning of the main() segment of code. When you link the program, use the linker option that creates a listing of the linkmap (I think it is -L, but I can't remember). I usually always print this listing to the printer by redirecting the output of the linker to the printer. This listing shows the relative starting position of every subroutine in the program. Just look for the main() routines relative starting position and add that to the starting address that the program gets loaded into (the debugger automatically sets the program counter to the starting address of the program when you load the code). The link map listing use very useful for determining the starting address of any subroutines called by main(), also. -- ----------------------------------------------------------------------------- John F. Snow UUCP: {ihnp4,decvax}!decwrl!esunix!jsnow Evans & Sutherland Computer Corp. Compuserve: 71550,1152 BIX: johnfsnow Salt Lake City, Utah