m65dbg refinements

[Gurce Isikyildiz]

While trying to debug mega65-ide, I was feeling like the m65dbg tool needed a bit more loving and refinement.

One thing I was thinking of was to try add a 'c' command for 'continue' that would do the raw "t0" command (to turn trace-mode off) and then either:

- sit in a loop waiting for a breakpoint to hit
- let ctrl-c break the loop and force a "t1" raw command to be sent (hence force trace-mode back on).

This was in an effort to get it behaving a bit more similar to gdb.

But just wondering though, is there a way to detect via the monitor whether trace-mode is presently on or off? Any registers in memory that I could assess?

Perhaps a simple way for now might be to send the "r" raw command and assess if the PC stays at the same address for the duration of a second. Still, if there's a way to know for sure, I'd be happy to use that instead.

[Gurce Isikyildiz]

Well, for now, I'm using the polling of the PC value as my technique, working ok.

I'm also now permitting the use of source line-numbers when setting a breakpoint.

For example, if you do a "dis" command and get some source:

<dbg>dis
> src/kickstart.a65:2605
> 2595:         bcc utility_end_of_list
> 2596:
> 2597:         ; Display utility and assign number
> 2598:         ldy #39
> 2599:         lda #$20
> 2600: um2:    sta msg_utility_item,y    ; **WARNING** this replaces the null terminator with a space?
> 2601:         dey
> 2602:         cpy #2
> 2603:         bne um2
> 2604:         iny
> 2605:         inc zptempv
> 2606:         lda zptempv
> 2607:         sta msg_utility_item
> 2608:         ldz #4

Let's say you're within a loop such as the um2: loop above and you want to break immediately after it.

You can now type "break :2604" (i.e., the source-code's line-number), and then the "c" (continue) command.

The continue command will then wait/loop until the breakpoint is hit and return the prompt to back you for you to continue your debugging from this point on.

I've pushed my changes to the MEGA65/m65dbg repo, so it's available as of now.

[Gurce Isikyildiz]

Oh, just as a further note, you can also use line numbers with the "dis" command too, E.g. "dis :2608"

[Gurce Isikyildiz]

Also, one observation/concern I had was that with the new serial baud rate we use of 2,000,000bps, this doesn't seem to be supported by mac osx.

I.e., the "B2000000" is not defined within its "/usr/include/sys/termios.h" file.

From what I've read online, other projects have experienced it too, and have just resorted to disallowing this speed on a mac:

• https://github.com/tomszilagyi/gen_serial/issues/1

Ah well, a bit of a shame it can't run on mac now, but at least I can still talk over the #unix socket to LGB's xemu emulator, that's enough for my debugging efforts for now I reckon.

[Paul Gardner-Stephen]

Could you also add an argument to step to indicate how many instructions to do?

Regarding the serial speed, yes, this is a big pain for OSX. I'll have to think about a solution. 

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gurce Isikyildiz]

Ok, added the optional <count> param to the "step" command.

This was more of a "step-into" command though, did you also (or actually) want it for the "n" (next / step-over) command?

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

[Gurce Isikyildiz]

Oh, just thought I'd also note that pressing the enter key will repeat the last command.

This is just in-case the problem was due typing in "step" multiple times (which I agree would be painful). So this way, you can just type "step" once, and then press enter multiple times to step through.

[Paul Gardner-Stephen]

Hello,

I use step to single-step through code, making sure it stops every instruction. But sometimes I want to do this for, say, 1000 consecutive instructions, either to get to the interesting bit, or to generate a trace of instructions to look at for debugging etc.

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

[Gurce Isikyildiz]

Okidoke, got it. Well, step-into with count is working. I guess I'd better add the step-over with count too, just in-case.


Ok, just added another command "wdump <addr> [<count>]".

 

It permits you to watch a memory dump. This can be handy if you want to continuously keep track of a chunk of memory while stepping through code that iteratively tries to alter that chunk.

 

Usage example:

To add a dump watch at the address 0x07c0, for 0x40 bytes (yeah, oddly, the byte-count is in hex presently, sorry).

<dbg>wdump 7c0 40

watch added!

 

Then the next time you see your watchlist (via either the "watches" command, or via "dis" while the autowatch flag is set):

<dbg>watches
---------------------------------------
#1: WORD    zptempp: AEFD
#2: WORD    zptempp2: 07C0
#3: BYTE    screenrow: 0C
#4: STRING  ae3c: ALT=UTIL MENU CTRL=HOLD-BOOT SHIFT=DEBUG
#5: DUMP    7c0:
 :00007C0 0C 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | .. . . . . . . .
 :00007D0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
 :00007E0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
 :00007F0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
---------------------------------------

 

NOTE: You can use a symbol-name in place of the address. For example:

 

<dbg>wdump msg_checkpoint_eom 20
watch added!

<dbg>watches
---------------------------------------
#1: WORD    zptempp: AEFD
#2: WORD    zptempp2: 07C0
#3: BYTE    screenrow: 0C
#4: STRING  ae3c: ALT=UTIL MENU CTRL=HOLD-BOOT SHIFT=DEBUG
#5: DUMP    7c0:
 :00007C0 0C 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | .. . . . . . . .
 :00007D0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
 :00007E0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
 :00007F0 20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |  . . . . . . . .
#6: DUMP    msg_checkpoint_eom:
 :000AE06 52 45 2D 54 52 59 49 4E  47 20 54 4F 20 52 45 41  | RE-TRYING TO REA
 :000AE16 44 20 4D 42 52 00 4D 45  47 41 36 35 20 4D 45 47  | D MBR.MEGA65 MEG
---------------------------------------

[Paul Gardner-Stephen]

Oh, while you are making such wonderful improvements, is it possible to have a dump command that takes 28 bit unresolved addresses, instead of 16-bit CPU addresses?

(Or does it already do it, and I am just doing something wrong or using too old a version).

Paul.

--

[Gurce Isikyildiz]

Oh, there was an "mdump" command to dump from a 28-bit address.

But I haven't turned that into a watch command yet, but hope to do it soon, I guess I'll call it "wmdump" (i.e., a watch for an mdump).

I've just been tinkering with xemu source and added the 's' monitor command to it (for writing hex vals straight into 28-bit memory). I just wanted to fill the memory where the printmessage text will be dropped to...

I forked from LGB's repo to make the commit, and I've sent a pull request his way.

Gurce

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

[Gurce Isikyildiz]

Made a few more additions tonight.

- Added an optional <count> parameter to the "n" (next) command.

- Can now add memory dumps of 28-bit memory to the watchlist with "wmdump <addr28> [<count>]"

- On startup, now tests for existance of a "~/.m65dbg_init" file. If one exists, commands are automatically read and executed from there.

Any empty lines, or lines starting with a "#" character (comment marker) are ignored.

Here's an example of what my "~/.m65dbg_init" looks like presently:

# ---------------------- # default initialisation # ---------------------- autocls autowatch # ------------------------------------------------------------- # my watchlist for debugging my present issue # (this saves me from re-typing it every time I restart m65dbg) # ------------------------------------------------------------- ww zptempp ww zptempp2 wb screenrow wdump 7c0 40

So the next time I run m65dbg, I see this upon start-up:

$ m65dbg
m65dbg - v1.00
======
error 2 opening /dev/ttyS4: No such file or directory
- Type 'help' for new commands, '?'/'h' for raw commands.
Loading "kickstart.list"...
Loading "kickstart.map"...
Loading "/Users/gurce/.m65dbg_init"...
 - autocls is turned on.
 - autowatch is turned on.
watch added! (WORD   : zptempp)
watch added! (WORD   : zptempp2)
watch added! (BYTE   : screenrow)
watch added! (DUMP   : 7c0 40)

So when I type my first dis, step or n command, all my desired watches ready and waiting for me

[Paul Gardner-Stephen]

All sounds great :)

Could you please also change the -d option to -l, to match the other MEGA65 tools?

Thanks,

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

[Gurce Isikyildiz]

Done :) Also, default port is not "/dev/ttyUSB1", as I suspect that's the default for Ubuntu devs, which I'm guessing are the majority.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

[Gurce Isikyildiz]

Oops, typo: default port is now "/dev/ttyUSB1"

[Paul Gardner-Stephen]

Thank you on both fronts :)

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

[Gurce Isikyildiz]

No probs :)

Also, after Ben's reminder about sharing any changes to px100mhz branch prior to dropping them back in master/development, I had a small pull request here:

https://github.com/MEGA65/mega65-core/pull/46/files

Just two small changes:

- tweaked Makefile to assure that "make clean" properly deleted the "bin/KICKUP.M65" file.
- tweaked run_ise to assure xst build log is generated from scratch (and not appended to prior log)

The latter feels the more critical, as the xst log file could show errors from prior builds, which and up being red herrings for the dev.

If any probs with the changes, let me know. I think the github site has a review facility that lets you drop in review comments.

[Paul Gardner-Stephen]

Thanks for the reminder. I have just accepted the pull.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

[Gurce Isikyildiz]

Had a small itch tonight, so added the following:

•  Added an optional [<addr>] argument to "c" (continue) command, equating to "continue until <addr>".
    (i.e., set a breakpoint at <addr>, then continue till we hit it)
   
• Added a not-very-functional "next" command. The aim/hope here was to tweak the xemu emulator to perform a "step over" of a JSR call and break immediately after it returned. I had some modest success with it, but the idea breaks down when it bumps into clever calls like "JSR checkpoint" which fiddle with the stack, then JMP back to the caller.