Debugging using BlastEm!

doragasu · Post by **doragasu** » Sat Mar 15, 2014 7:19 pm

I have started experimenting with the debugging capabilities of the promising BlastEm! (Many thanks Mask of Destiny!).

As I'm not a CLI debugging fan, I have integrated GDB with Code::Blocks IDE, for easy breakpoint and watches management. It somehow works: I can set breakpoints, step through code and watch variables. But so far I have encountered two problems that make the debugging experience a bit frustrating:

1.- I cannot debug my assembly files. I can debug my C files, and also assembly files like "sega.s" from SGDK. When I try debugging one of my .s files, the debugger window outputs errors like "No source file named /home/doragasu/src/genesis/test/test.s.". I suspect the problem might be I use "--register-prefix-optional" switch to build my 68k assembly stuff, saving writing a lot of stupid "%" characters.
2.- When I step-over functions, if the function is implemented in my code, it works, but if I step-over SGDK functions, it doesn't work: the program gets stopped but the cursor indicating where the PC is doesn't appear anywhere.

Is anyone using BlastEm! for debugging? Any suggestions on how to fix these issues?

Mask of Destiny · Post by **Mask of Destiny** » Sat Mar 15, 2014 11:59 pm

doragasu wrote:1.- I cannot debug my assembly files. I can debug my C files, and also assembly files like "sega.s" from SGDK. When I try debugging one of my .s files, the debugger window outputs errors like "No source file named /home/doragasu/src/genesis/test/test.s.". I suspect the problem might be I use "--register-prefix-optional" switch to build my 68k assembly stuff, saving writing a lot of stupid "%" characters.

This may be a silly question, but is test.s actually at the path indicated?

doragasu wrote:2.- When I step-over functions, if the function is implemented in my code, it works, but if I step-over SGDK functions, it doesn't work: the program gets stopped but the cursor indicating where the PC is doesn't appear anywhere.

This can probably be fixed by linking with a copy of the SGDK lib that has debug symbols. I'm not 100% sure why that's necessary, but the way GDB implements step over is by single stepping until PC gets to the right spot. It might get confused when the processor stops at an address that it doesn't know is code though.

It's also possible that I'm indicating the wrong stop reason for single stepping and that's why it's confused. Not sure why it would work fine for code with symbol information then though.

doragasu · Post by **doragasu** » Sun Mar 16, 2014 12:43 pm

Of course the .s files are present and readable at the path specified by GDB (that was the first thing I checked).

I'll try generating the SGDK library again, compiling with -g to test if adding debug info helps.

Thanks!

doragasu · Post by **doragasu** » Sun Mar 16, 2014 8:11 pm

I have tried modifying an assembly file, using the default syntax with the '%' to name registers. Then I built it without using the --register-prefix-optional switch and tried to debug the file. Result: FAIL. I still get the same error ("No source file named <asm_file>."), but the file is there for sure.

Then I tried rebuilding SGDK library with debug information, built a project, started the debug session, and voila! I can step over SGDK calls without a problem! This is really neat!

The stuff I tried to debug in assembly runs during HBLANK. Could this be the problem?

Mask of Destiny · Post by **Mask of Destiny** » Mon Mar 17, 2014 6:07 am

doragasu wrote:I have tried modifying an assembly file, using the default syntax with the '%' to name registers. Then I built it without using the --register-prefix-optional switch and tried to debug the file. Result: FAIL. I still get the same error ("No source file named <asm_file>."), but the file is there for sure.

..snip...

The stuff I tried to debug in assembly runs during HBLANK. Could this be the problem?

So I did a quick test by moving the VINT handler out of sega.s into a separate assembly source file. I was able to set a breakpoint in the handler and source level debugging worked fine (at least in plain gdb, I don't have Code::Blocks setup to test with). So it would seem there's no problem with debugging assembly code in an interrupt handler assuming everything is setup correctly.

What flags are you passing to as for your own files? Any differences besides --register-prefix-optional?

doragasu wrote:Then I tried rebuilding SGDK library with debug information, built a project, started the debug session, and voila! I can step over SGDK calls without a problem! This is really neat!

Glad that's working at least.

doragasu · Post by **doragasu** » Mon Mar 17, 2014 7:39 am

I have no access to my files right now, but IIRC, I'm not directly building the assembly files with as, but with gcc instead. Also I think I'm only passing -m68000 to it right now, but I have to verify it.

Gotta try repeating your test (moving the VINT handler to a separate file) when I get some spare time.

Stef · Post by **Stef** » Mon Mar 31, 2014 9:54 pm

doragasu>I guess you compiled your GDB for linux system, can you tell me which version are you using ? I tried to setup code::blocks with GDK support with the last GensKMod (i have not yet tried to compile BlastEm for windows) and so far i have only partially working debugging :-/
I tried GDB version 7 and i cannot get it to work at all, right now i'm using an older version (6.5.50) and it somehow works, except that trying to stepping will always get me in the VInt code, and removing breakpoint do not work (always stop to the breakpoint). All these problems make it completely useless for now... did you experienced similar troubles ? co you have an idea from where it comes from ? so far i tried many different setting without many success :-/

doragasu · Post by **doragasu** » Tue Apr 01, 2014 6:27 am

@Stef: Yes, I built GDB for Linux. I can't recall the version exactly, but I think it was the latest (7.7), and it built nicely on 64-bit ArchLinux.

I didn't have the problem you mention about single stepping getting you into VInt code. But I also had problems clearing breakpoints. Unfortunately I had no time to investigate what causes this problem (I'm extremely busy ATM), but this might be a problem with how C::B interacts with GDB, because I had also this problem when debugging on a Stellaris Launchpad (ARM microcontroller board) using C::B + GNU toolchain. I don't remember having this problem when using e.g. Eclipse + GNU toolchain... I should try Eclipse if I get some time...

Stef · Post by **Stef** » Tue Apr 01, 2014 9:17 am

Thanks for the info so Code::Blocks seems to have some responsibilities in these problems (at least for breakpoints) , i will try to drive GDB debugging manually and see what happen. The problem about stepping is really annoying, i hope i will be able to sort it out !

doragasu · Post by **doragasu** » Tue Apr 01, 2014 9:24 am

Also did you build SGDK (and your program) with debug information? It doesn't look like, but could your problem be related to the first I had about not being able to single step through SGDK functions?

Stef · Post by **Stef** » Tue Apr 01, 2014 6:12 pm

Yeah of course i built them with debug infos, tried -g or -g3 but does not make any difference :-/
I will give more chances to it this week end, i would really like to get real debugging features in SGDK

Mask of Destiny · Post by **Mask of Destiny** » Tue Apr 01, 2014 6:20 pm

Just to get the other "obvious" stuff out of the way, you're using a copy GDB built for m68k-elf, right?

Stef · Post by **Stef** » Tue Apr 01, 2014 6:25 pm

yeah of course, the version 7 i used first was maybe for another target, but this one is m68k-elf. Also when i'm stepping it goes to vint code, but then it works perfectly there (or almost). It's just that it is not stepping where i want X'D

SpritesMind.Net

Debugging using BlastEm!

Debugging using BlastEm!

Re: Debugging using BlastEm!