Hi Martin, This is quite good, also your enjoying what you are doing I think that is the key for good quality products (software, hardware, integrated systems). This is a time saver for new development and making it work properly. This gives you more control of the debugging process for the chip your interested in. This also beats what MounStudio has done with it's integration of GDB for debugging their CH32 chips because they focus only on those chips.
Have a good holiday John S PS: I don't think you need to worry about the quantity of emails, looks like we can break the record of the number of emails in one month at least since 2014? (in the group email chart). On Wed, Dec 24, 2025 at 9:07 AM Martin Kobetic <[email protected]> wrote: > My last message seems to have been blocked due to size (I attached a > picture). I'm not sure if any list admins are watching currently, so I'm > resending it with a link instead. Please reject the original if you are. > > ---------- > > Hi all, I hope I'm not too annoying with all the emails. I promise I'll try > to keep it down, but I've got one more thing I'd like to bring up. I've > been doing a lot of debugging, and I went down the rabbit hole with GDB to > make that as convenient as possible. I want to share what I was able to do > with GDB and maybe solicit some debugging tips from others. > > First of all I'm quite impressed with how powerful GDB's TUI and Python API > is. This is how my debugger looks now: > https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/gdb-amforth.png > > The top views are "source", "asm" and custom "registers" view. Note that > the register view is tailored to what AmForth uses the registers for. The > Forth "parameter stack" and "return stack" are on the bottom right. I have > some ideas how to improve the stack views further but I think this already > shows what's (fairly easily) possible. > > Some of my earlier tweaks are addition of ".s" and ".r" commands to GDB to > dump the stacks in the command window (that's also what the stack views are > currently using as well). > > If anyone's interested the custom views are defined using the python API: > https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/gdb-amforth.py > and the custom commands and the layout itself is defined in GDB init file: > https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/.gdbinit. > The OpenOCD and GDB invocations are in the Makefile: > https://github.com/mkobetic/amforth/blob/unor4/appl/unor4/Makefile#L64-L80 > > This makes debugging the assembler words quite comfortable. I'm still > thinking about the best way to debug colon words. The best I've got so far > is adding a breakpoint at DO_EXECUTE and automatically stepping twice to > end up in the code of the word being executed. > > define bde > hbreak DO_EXECUTE > commands > step 2 > end > end > > Then I can use `continue` to step from word to word. I suspect there are > probably better ways to go about this. I'd welcome any suggestions. > > I'm also wondering what's the best way to set a breakpoint in a colon word. > You can't just point at the address in the word parameter field because > that's not where the PC is going to be. The best I can think of is again a > breakpoint in DO_EXECUTE but with the condition on FORTHIP pointing at that > address in the parameter field maybe? I haven't really tried that yet, but > can't think of anything better. Again, any suggestions are welcome. > > Any other favourite tricks that you could share with a rookie? I'd be much > obliged. > > Cheers and Merry Xmas! > > Martin > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/amforth-devel > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
