tribby@hpindda.HP.COM (David Tribby) (06/16/89)
I'm using the new Apple II GS debugger, GSBug. The application version
works fine, but I have a few questions about the init (CDA) version...
The documentation talks about a file named GSBUG.SETUP, but it
did not come on the disk with the debugger. This file is supposed
to go in a directory called SYSTEM.STARTUP. Should that directory
be under */, */SYSTEM, or */SYSTEM/SYSTEM.SETUP (or somewhere else)?
I can start the init version with control-OpenApple-Option-escape,
but when I try to get out with q or qr, GSBug beeps at me and
leaves me in the command line. The q and qr work fine with the
application version. I finally got out by entering the commands
off to get the correct display
s start single-step mode
j jump into executing code.
Any ideas why q doesn't work?
Thanks in advance!
--Dave Tribby
- - - - -
ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribbymattd@Apple.COM (Matt Deatherage) (06/17/89)
In article <6230036@hpindda.HP.COM> tribby@hpindda.HP.COM (David Tribby) writes: >I'm using the new Apple II GS debugger, GSBug. The application version >works fine, but I have a few questions about the init (CDA) version... > > I can start the init version with control-OpenApple-Option-escape, > but when I try to get out with q or qr, GSBug beeps at me and > leaves me in the command line. The q and qr work fine with the > application version. I finally got out by entering the commands > off to get the correct display > s start single-step mode > j jump into executing code. > Any ideas why q doesn't work? > >Thanks in advance! >--Dave Tribby > - - - - - > ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby Q doesn't work because it doesn't make sense to "quit" something you broke into on the fly. The command is "r" for "resume". Why doesn't the package say this? Because the command is in the release notes, and when I was asked to approve them for shipment, I wouldn't, because they talked about things they shouldn't have and nobody had time to clean them up, so they went without them. The changes since the manual are really minor, and the manual on the whole is very good. Yes, there are more commands in there than the manual covers, but being beta software, they usually don't work. ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------
jazzman@claris.com (Sydney R. Polk) (06/20/89)
From article <6230036@hpindda.HP.COM>, by tribby@hpindda.HP.COM (David Tribby): > I'm using the new Apple II GS debugger, GSBug. The application version > works fine, but I have a few questions about the init (CDA) version... > > The documentation talks about a file named GSBUG.SETUP, but it > did not come on the disk with the debugger. This file is supposed > to go in a directory called SYSTEM.STARTUP. Should that directory > be under */, */SYSTEM, or */SYSTEM/SYSTEM.SETUP (or somewhere else)? We got no docs, but I don't think this file is essential. > I can start the init version with control-OpenApple-Option-escape, > but when I try to get out with q or qr, GSBug beeps at me and > leaves me in the command line. The q and qr work fine with the > application version. I finally got out by entering the commands > off to get the correct display > s start single-step mode > j jump into executing code. > Any ideas why q doesn't work? That is the only way to exit. q actually would try to excute a prodos quit call. It doesn't make since in an init. What you have done is basically equivalent to a breakpoint. It's as if the debugger was the boot application (in a sense it is) and you can't really "quit" it. > Thanks in advance! > --Dave Tribby Another neat thing: The debugger leaves interrupts enabled period. This means that if you can make it the first thing in your system setup folder, all sorts of things which normally wouldn't work with a CMS SCSI Card will work. For instance, when running AppleShare, if you set up a volume to be present when you boot, normally AppleShare would hang with a CMS SCSI Card because the interrupts which tell the GS that the logon was successful are eaten by the card (the card disables interrupts). If the debug init is run first however, this will work! Gross. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
tribby@hpindwa.HP.COM (David Tribby) (07/19/89)
Several comp.sys.apple readers were helpful the last time I had a GSBug
question, so here are a couple more...
1. Is there any way to set a "real time" breakpoint for a toolset call?
Since I do most of my programming in TML Pascal, I would like to set
a breakpoint on a particular toolset call, then let the program run
in real time until the invocation.
2. Does the "init" version of GSBug interfere with the "run time" version?
I have the init version enabled at startup, and sometimes peculiar
things happen when I invoke the run-time version and try to load & debug.
For example, I loaded my program, then tried to invoke the loader/dumper
CDA to get the seqment addresses. When I pressed OA/Ctrl/esc, the display
froze (the cursor quit blinking and no characters echoed on the screen).
Things seemed to start working again when I pressed the option key (by
itself), but it turned out I had invoked the init version of GSBug! I
Restored from the init version, then could work with my program in the
run-time GSBug.
Thanks in advance for any help!
--Dave Tribby
- - - - -
ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribbyjazzman@claris.com (Sydney R. Polk) (07/20/89)
From article <36410002@hpindwa.HP.COM>, by tribby@hpindwa.HP.COM (David Tribby): > Several comp.sys.apple readers were helpful the last time I had a GSBug > question, so here are a couple more... > > 1. Is there any way to set a "real time" breakpoint for a toolset call? > Since I do most of my programming in TML Pascal, I would like to set > a breakpoint on a particular toolset call, then let the program run > in real time until the invocation. Ooh, yuck! OK, you have to use something like Nifty List or Mangler to find where the toolset is loaded. You have to look in the tollset jump table to figure out where the tool is. If you suceed in this, you still may fail, because you can't set a breakpoint to an address in ROM. Now that I have thought a second, you might get the TSPtr by finding and area in memory that is blank, assembling something to make the correct call, and then setting a BP their. You still may run into the ROM problem, although you could set a bp in the dispatcher at the appropriate place. It would be much easier to set a breakpoint at the routine you are calling the tool from and then turn mp off for e1000-ffff and step into it. You do NOT want to do this in GS/OS calls; they have real-time code in them. > 2. Does the "init" version of GSBug interfere with the "run time" version? > I have the init version enabled at startup, and sometimes peculiar > things happen when I invoke the run-time version and try to load & debug. > For example, I loaded my program, then tried to invoke the loader/dumper > CDA to get the seqment addresses. When I pressed OA/Ctrl/esc, the display > froze (the cursor quit blinking and no characters echoed on the screen). > Things seemed to start working again when I pressed the option key (by > itself), but it turned out I had invoked the init version of GSBug! I > Restored from the init version, then could work with my program in the > run-time GSBug. What we do: We set up a check at the beginning of our program to see if Opt-Ctl are down. If they are, we brk, which drops into the init and we can set things up from there. I NEVER use the run-time debugger anymore; if I have to, I run off of a disk without the init. > Thanks in advance for any help! > > --Dave Tribby > - - - - - > ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
dlyons@Apple.COM (David Lyons) (07/20/89)
From article <36410002@hpindwa.HP.COM>, by tribby@hpindwa.HP.COM (David Tribby): > Several comp.sys.apple readers were helpful the last time I had a GSBug > question, so here are a couple more... > > 1. Is there any way to set a "real time" breakpoint for a toolset call? > Since I do most of my programming in TML Pascal, I would like to set > a breakpoint on a particular toolset call, then let the program run > in real time until the invocation. Yes! The version APDA has (4.0b1) has SETTBRK, TBRKIN, and TBRKOUT (among other things). Note that 4.0b1 only breaks on $E10000 calls, not on the $E10004 entry to the same calls. (Some compilers generate lots of calls to the $E10004 tool dispatcher, which expects an extra RTL address to already be on the stack.) Tool breaks come in very handy, at least for me. > 2. Does the "init" version of GSBug interfere with the "run time" version? Yes, at least sometimes. Hold down Option during boot to keep the init from loading (or delete the file, or mark it Inactive in the Finder). --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
tribby@hpindwa.HP.COM (David Tribby) (07/21/89)
Thanks, Syd & Dave, for the answers to my GSBUG questions! I asked... |> 1. Is there any way to set a "real time" breakpoint for a toolset call? And Dave Lyons pointed out... |Yes! The version APDA has (4.0b1) has SETTBRK, TBRKIN, and TBRKOUT (among |other things). TBRKIN and TBRKOUT were exactly what I needed. SETTBRK and the commands to show and clear toolset breakpoints were described in a cover sheet for the 4.0b1 manual, but not the related IN and OUT commands. Last month you told me about the "R" command, to reset the init version after poking around. Are there any other undocumented commands that work? |> 2. Does the "init" version of GSBug interfere with the "run time" version? |Yes, at least sometimes. Hold down Option during boot to keep the init from |loading (or delete the file, or mark it Inactive in the Finder). As Syd points out, why even use the run time version? It's real handy to have the init version available to look around in a running program. Is there any situation where it's better to start from the run time version? And now a bonus question... I go into GSBug to examine parts of a program, including tracing it for awhile and switching between the Super Hi-Res and GSBug screens. After I've had enough, I go to single-step mode, switch to SHR, and jump back into my code. When my program terminates back to APW, the screen seems to be in low-resolution graphic mode rather than text mode. Why? (I fix the screen by re-entering GSBug and immediately exiting.) --Dave Tribby - - - - - ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby
wombat@claris.com (Scott Lindsey) (07/23/89)
From article <6230036@hpindda.HP.COM>, by tribby@hpindda.HP.COM (David Tribby): > The documentation talks about a file named GSBUG.SETUP, but it > did not come on the disk with the debugger. This file is supposed > to go in a directory called SYSTEM.STARTUP. Should that directory > be under */, */SYSTEM, or */SYSTEM/SYSTEM.SETUP (or somewhere else)? From experience, not necessarily documenation: After you've set up all the settings, breakpoints, traps, etc. you want to default to, type "csave */system/system.setup/gsbug.setup" to create the settings file. This file will be automatically used by GSBUG.INIT but not by GSBUG, the stand-alone. You can type "cload */system/system.setup/gsbug.setup" to load it (or any other settings file w/ another pathname) into GSBUG, but I've yet to discover any settings autoload for it. -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
dlyons@Apple.COM (David Lyons) (07/23/89)
In article <6230036@hpindda.HP.COM> tribby@hpindda.HP.COM (David Tribby) writes: >I'm using the new Apple II GS debugger, GSBug. The application version >works fine, but I have a few questions about the init (CDA) version... > > The documentation talks about a file named GSBUG.SETUP, but it > did not come on the disk with the debugger. This file is supposed > to go in a directory called SYSTEM.STARTUP. Should that directory > be under */, */SYSTEM, or */SYSTEM/SYSTEM.SETUP (or somewhere else)? You can create the file using CSAVE; the correct directory is */SYSTEM/SYSTEM.SETUP. > I can start the init version with control-OpenApple-Option-escape, > but when I try to get out with q or qr, GSBug beeps at me and > leaves me in the command line. The q and qr work fine with the > application version. I finally got out by entering the commands > off to get the correct display > s start single-step mode > j jump into executing code. > Any ideas why q doesn't work? I don't think the docs are quite up to date with the product--try using R for Resume instead. If R doesn't work for you in particular circumstances, then do what you did, using S and J. That works (but leaves some memory in bank 0 allocated, so you won't be able to launch P8 applications until you reboot). --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
dlyons@Apple.COM (David Lyons) (07/25/89)
In article <36410003@hpindwa.HP.COM> tribby@hpindwa.HP.COM (David Tribby) writes: >As Syd points out, why even use the run time version? It's real handy to have >the init version available to look around in a running program. Is there any >situation where it's better to start from the run time version? Yes, I occasionally find the Application version useful. Like when I want to trace an application from the beginning & don't have a handy way to trap on a tool call that I know it makes right at the start. (It's really hard to hit Apple-Option-Ctrl-Esc at just the right moment. Using the App version of the debugger and LOADing the program is much easier.) >I go into GSBug to examine parts of a program, including tracing it for >awhile and switching between the Super Hi-Res and GSBug screens. After I've >had enough, I go to single-step mode, switch to SHR, and jump back into my >code. When my program terminates back to APW, the screen seems to be in >low-resolution graphic mode rather than text mode. Why? (I fix the screen by >re-entering GSBug and immediately exiting.) Happens to me too. (Why? To keep life interesting, I think.) --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.