Subject: Re: [stella] debugger pcode From: "B. Watson" <atari@xxxxxxxxxxxxxx> Date: Sun, 26 Jun 2005 22:56:04 -0400 |
On Sun, 26 Jun 2005, Glenn Saunders wrote: > --- atari2600 <atari2600@xxxxxxxxxxxxx> wrote: >> So if you're considering attaching breakpoints to >> source, as suggested below, I think we're on >> different tangents. > > It wouldn't have to be one or the other. It could be > both. It probably won't be both... > The notion of "assemble time" vs. "debug time" is a > little blurred considering that it takes less than a > second to cross-assemble a 2600 binary on a PC. > Conceptually it's the same as controlling the debugger > from the sourcecode view in an integrated IDE like > Visual Studio. It's just that instead of a GUI > approach where debugging settings are hidden in other > windows and breakpoints are visually implied with > highlighting lines and such, you have to actually > annotate the sourcecode. The current plan is to put a breakpoint checkbox on each line of code in the disassembly window (which will also be the source window, when we support source-level debugging). The checkbox will have to mutate into something else later, when we support complex break conditions, but it'll be in the same place. > As long as the debugger can bring in a DASM LST file > and present the running code in that format with the > mnemonics, symbols, and comments intact, than I would > say configuring the breakpoints interactively in the > debugger would be fine without resorting to marking up > the sourcecode. But it would be nice to be able to > save debugging config off for later. With the > sourcecode aproach it's already embedded in the ASM > file which has its good and bad points (when sharing > code you'd want to remove or nullify all the debuging > lines). The ability to save the debugger config will be there, as part of the existing "save state" function. However... ...breakpoints are by address, not by label (otherwise the 6507 would be painfully show: we have to check for a breakpoint on every instruction, and parsing labels takes a lot longer than numerically comparing addresses). This means that, if you assemble your source, debug it, set a few breakpoints, and save the config... then later change the source and reassemble, the breakpoints will probably be invalid: your labels won't have the same address values unless you only make trivial changes. What I had in mind was something of a "batch file" approach: a file that contains debugger commands to be executed at debugger startup. You could set up your breakpoints in there instead of marking up your source. The batch file would have access to the symbol table, so you could set breakpoints at labels in there, and they'd get resolved when the debugger runs the file. Also, I was thinking of adding a -break command line option, that you can use like so: stella -break myLabel romname.bin We already look for and load romname.sym, so myLabel would be resolved from there. It would be equivalent to a batch file with the single line "break myLabel" in it. I'm not really in favor of marking up the source unless (until) we have a source code editor built into Stella. This won't happen in version 2.0, but it's something we're working toward. Eventually, we really will have that IDE you keep asking for :) -- B. Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://stella.biglist.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] debugger pcode, Glenn Saunders | Thread | [stella] Stella 2.0 Alpha 2 availab, B. Watson |
Re: [stella] Stella 2.0 alpha 1 ava, B. Watson | Date | Re: [stella] debugger pcode, B. Watson |
Month |