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
