| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Code based breakpoints using ca65 and VICE
Recent discussions about debugging etc made me do this, much like Doynax's stuff:
Macro for ca65:
.macro breakpoint name
.ident (.concat("br_", .string(name))):
.export .ident(.concat("br_", .string(name)))
.endmacro
Link line in your Makefile:
ca65 -C link -m map -Ln symbols $(OBJS) && sed 's/al [0-9A-F]* \.br_\([a-z]*\)/\0\nbreak \.br_\1/' < symbols > symbols2
Basically it tells ca65 to emit all labels into a file called symbols. The sed-script then locates all symbols starting with br_ and adds a breakpoint command after it.
To run in VICE:
x64 -moncommands symbols2 whateva.d64
This enables you to add breakpoints directly into your sourcecode like:
breakpoint flashcolors
inc $d020
jmp *-3
Have fun with future debugging! :)
|
|
... 27 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Then again... Any script language could easily make some sort of pre parsing of any text file, before this text file is sent to an assembler. What is so great about having it "in" the assembler itself? It is still executed in a completely separate pass, before any labels are resolved and so on, isn't it? |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I thinks it's a great advantage to be able to write sine curves and small graphic converters in the middle of your sourcefile.
I guess k2asm does it by a prepass (but im only guessing) while Kick Assembler assembles both the script and the Assembler commands together. The strength of the ladder is that the script and the asm code can interact both ways.
Notice that Mr. Sid didn't solve the original problem (generating breakpoints). In the Kick Assembler example it was done by:
.eval file.writeln("break " + toHexString(*))
where the * refers to the current memory position, this couldn't have been done in a prepass.
However, Including a preparse script in an assembler is a cool thing, relative to no script, since it makes people aware of the of the advantages of scripting.
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@Slamsky: Just to clarify, I was referring to k2asm in my post..
...and now I just implemented some shit so I can just write ".bpc("if .A == $83")" in my code, and the VICE monitor will break on this line, if the specified condition holds true (if register A is equal to $83 at that point in the program). Very nice. :) If I just write ".bp", it will break unconditionally on this line.
I am using DreamAss for the current project. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Dragnet: KickAssembler now supports setting variables from the commandline. The are available from the script through the cmdLineVars hashtable. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
That macro would be super handy:
.bpc("if .A == $83")
Is is possible to do it with Vice and KickAss?
As far as I got up to, I was able to generate the breakpoints file and then manually type in the monitor:
break 8800 if .A == $83
But that's lame ;-)
I have this complex routine that fails at one point and I need to track exactly that condition have you got any other suggestions?
I want to use the condition to stop and step the code exactly when it happens. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
Here's the macro for KickAss and VICE (thx Frantic):
.macro bpc(condarg) {
.eval brkFile.writeln("break " + toHexString(*) + " " + condarg)
}
Example:
.var brkFile = createFile("breakpoints.txt")
:bpc("if .A == $83")
Will stop but only if A is $83.
Of course VICE has to be launched with:
-moncommands breakpoints.txt
Happy debugging :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
To track down bugs with modern fancy tools you all would first of all need to produce code/demos :-P Also, i wonder how we survived in the past? :-)
A simple bcs *, bcc * or alike was enough to check if flags are for sure at the state we expect them or else our program will lock up. $02 is also a good opcode to use with vice, so you can trigger the monitor as soon as your wanted piece of code is reached. I mean, we have already a whole programming language on board to do complex debugging tasks and giving feedback: 6502
So far i have not crossed borders that would make me need more. There's other things that are way more interesting in my opinion, like having a proper profiler and thus be able to detect dead code (micro64 is giving some more information here in the monitor), or have cycles of certain code segments counted easily.
Just wondering. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
I think i agree with Bitbreaker.. Breakpoints are not a must in case of c64 as you can actually change the code quickly enough and recompile/restart. I think the point is that with modern tools we could save few minutes here and there.
But profiling is a different story.. The closest thing to profiling i've been using was to slam tons of watchpoints around the code part i was optimising, running it in vice, capturing the vice output into a text file and then calculating the "weight" of each instruction with some text based utilities. That was slow but sort of worked. But i would resort to it only in the worst case (that case was my worst case as it was not a simple inner loop optimization but something bigger with a complex flow and branching and i had to figure out the right mix depending on the input data)..
Anyway, you mentioned micro64 and profiling. I remember trying it out a year ago or so and although it mentioned the profiling in the changelog i was not able to turn it on and get anything sensible out.
Could you post some short instruction on how to make it work? Thanks in advance! |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
The micro64 has a monitor that can be accessed via a terminal/telnet, a typical output would look like:
$0030: b0 de bcs $0110 ; 0.55% executed, 72.81% taken
$0032: 46 11 lsr $11 ; 0.15% executed
$0034: 90 ee bcc $0124 ; 0.15% executed, 87.77% taken
$0036: a9 80 lda #$80 ; 0.07% executed
$0038: 85 11 sta $11 ; 0.07% executed
$003a: 45 13 eor $13 ; 0.07% executed
$003c: 85 13 sta $13 ; 0.07% executed
$003e: 85 16 sta $16 ; 0.07% executed
$0040: 30 e2 bmi $0124 ; 0.07% executed, 51.24% taken
$0042: e6 14 inc $14 ; 0.04% executed
$0044: e6 17 inc $17 ; 0.04% executed
$0046: d0 dc bne $0124 ; 0.04% executed, 100.00% taken
$0048: a9 01 lda #$01 ; 1.13% executed
$004a: 19 d3 28 ora $28d3,y ; 1.13% executed
$004d: 99 d3 28 sta $28d3,y ; 1.13% executed
The mnemonic decoding yet showed some bugs (sta ($xxxx),y how cool would that be) BeRo is informed and has fixed those issues already. The output is not yet perfect, but gives a few interesting numbers, most of all, on how often a branch is taken. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
You ought to be kidding me :)
I've fired up micro64, even were in the monitor, even saw the command to reset the profiler stats but never actually disassembled a running piece of code.
Thanks for the tip, you've made my day! |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
