#46578 - paladine - Mon Jun 27, 2005 5:01 pm
I'm having problems debugging with VisualBoyAdvance 1.7 and above. A half-year ago I was working on a game and was able to debug using VBA. I had a 32 bit linux machine as my development host. I have since switched to 64 bit linux and began a new game and after rebuilding my development tools I can no longer debug.
When I issue the 'cont' command in gdb the program goes into a weird state where nothing executes as it should and no breakpoints are reached. The interesting thing however is that I can single step instruction-wise through the code. However this is a long and tedius task because I want to get to the troublesome parts quickly.
Are there are known issues with the VBA debugger or newer gcc's? I'm using gcc 3.4.3 with VBA 1.7.2 and gdb 6.0-6.3 and all have failed.
#46597 - Quirky - Mon Jun 27, 2005 9:48 pm
I have had similar problems with the source builds of 1.7.2 and only the precompiled vba version 1.7 would debug correctly. That's the version I use at the moment, perhaps try downloading the earlier source and compile it with DEV_VERSION defined (or similar, check the source or configure for the right names/flags). There seems to have been some 'entropy' in later releases and nobody is maintaning the code by the looks of things. It could be a compiler issue though, as I have gcc 3.4.3 too.
http://forum.gbadev.org/viewtopic.php?t=5243&highlight=
#50746 - ribrdb2 - Fri Aug 12, 2005 5:29 pm
I think this is probably a compiler problem. The problem I'm having is that gdb always trys to set ARM breakpoints, but almost all of my code is THUMB, so naturally debugging doesn't work. Digging through gdb's code, it seems that gcc isn't outputting the information that gdb looks for to determine whether a function is ARM or THUMB. I don't know if this is because the compiler is configured incorrectly, or if newer versions of gcc are storing this information in a different format. As a workaround, you can compile all your code in ARM mode.
#50747 - NoMis - Fri Aug 12, 2005 5:32 pm
I have the same problem with new GCC versions. I can debug flawlessly with devkitarm r8. But when I update to a newer devkitarm nothing works anymore.
NoMis
_________________
www.gamedev.at - The austrian gamedev site
hde.gamedev.at - The Handheld Dev Env plugins for Eclipse
#50878 - ribrdb2 - Sun Aug 14, 2005 3:12 am
It seems that the thumb eabi has changed. GDB in cvs is supposed to support it, although I haven't gotten it to work yet. However, using ARM for everything works just fine.
#50963 - Quirky - Sun Aug 14, 2005 10:26 pm
I've got GNU/Linux devkitARM releases 8-15 installed here and I symlink devkitARM to the directory devkitARM_rN to build with the version 'N' that I require. Clunky but it works for this test. I also have built-from-source VBA SDL and the 'official' Linux SDL build 1.7 . I've created a bare minimum gba program in C and compiled it with r8, r11 and r13. r15 uses gcc 4.0 and I imagine will not work at all, a few quick tests show code fails debugging in a similar way to r13.
Here are my findings using the built in debugger ( i.e. started using VisualBoyAdvance -d r8.elf ):
Source build of VBA : no version with r8-r13, arm or thumb compiled, will break at main.
Code compiled with r8 and r11 are correctly recognised as thumb, r13 is recognised only as ARM no matter what it really is.
VBA 1.7 : r8 and r11 stop at breakpoint at main successfully and vba recognises it as thumb code when compiled that way.
r13.gba says it is ARM code and fails to break when compiled thumb. Compiled as ARM, r13 code stops at the breakpoint successfully.
Conclusions:
Something is wrong with the VBA debugging code in cvs
In order to debug code (on Linux at least), use binary-only VBA version 1.7. Use DevkitARM r11, or compile all your code as arm - I use r11 for now.
NB: this is not a bug report on DevkitARM! Any problems are obviously with VBA and it not handling the changes to the embedded application binary interface in gcc.
EDIT: I've just compiled VBA version 1.7 from cvs and it debugs r8-r11 fine. To do this you can run:
$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/vba login
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/vba co -r VBA_1_7 VisualBoyAdvance
Then read INSTALL (I also had to change src/memgzio.h as it got in a muddle with zlib.h defines) That might help the OP.
#51005 - ribrdb2 - Mon Aug 15, 2005 8:28 am
It looks like getting vba to use the new eabi should be easy. In sdl/debugger.cpp, add these lines to debuggerBreak
| Code: |
if(type == 0x02 || type == 0x0d) {
int i = debuggerNumOfBreakpoints;
int size = 0;
// new code -- handle eabi change
if (address & 1) {
type = 0x0d;
address &= ~1;
}
// end new code
if(type == 2)
size = 1;
|
I haven't tested this however, since I use gdb. Using gdb from cvs, I was able to set breakpoints in THUMB functions, although I couldn't get a breakpoint in main to work.[/code]
#51020 - Quirky - Mon Aug 15, 2005 1:59 pm
Excellent work! If you patch VBA 1.7 (src/debugger.cpp) that stops on break points with thumb code compiled with release 8 to release 15.
When you say that you use GDB... with which VBA are you using it? The latest version of VBA just refuses to stop on breakpoints no matter what debugger I use - arm-elf-insight or arm-elf-gdb or the built in debugger - are you using an older VBA? I ask because it's not healthy to have VBA broken in cvs, and if it isn't broken then I must be doing something wrong and would like to know what it is.
#51031 - wintermute - Mon Aug 15, 2005 6:51 pm
I've had trouble getting debug to work with anything other than the VBA SDL version. This is available for download in the devkitpro.org downloads section.
As for the thumb eabi problem - it may help if the debug output is specified when compiling
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options
I haven't tried this yet but I'm working on getting a later version of Insight/gdb together.
#51054 - ribrdb2 - Mon Aug 15, 2005 10:59 pm
I'm using the sdl version, I think it's from cvs. Although I do remember having some problems with cvs -- I may be using something older. I'll check tonight.
#51071 - ribrdb2 - Tue Aug 16, 2005 2:41 am
Looks like I'm using CVS from July 4, which is essentially the current CVS minus one gfx change. I'm running on a mac, so it's compiled with the c-core. Maybe that's part of the problem.
#51085 - wintermute - Tue Aug 16, 2005 7:12 am
| ribrdb2 wrote: |
| Looks like I'm using CVS from July 4, which is essentially the current CVS minus one gfx change. I'm running on a mac, so it's compiled with the c-core. Maybe that's part of the problem. |
you need source for 1.7.1, I've never got debugging to work right on anything later.
#51256 - rodolforg - Wed Aug 17, 2005 6:32 pm
I'm using it on Windows, devkitARMr15 and their insight-5.2.1. I can't even connect to VBA regarless its version (1.8.0 beta, 1.7.2 dev, 1.7.1 dev and 1.7 dev). Could anyone help me?
#51371 - ribrdb2 - Thu Aug 18, 2005 8:51 pm
Did you enable BKPT_SUPPORT in the makefiles for 1.7.2? I don't think the configure script sets it by default any more. I am starting to notice wierdness after hitting a breakpoint though -- I'll try 1.7.1 and see if it's any better.
#51448 - Quirky - Fri Aug 19, 2005 6:45 pm
| ribrdb2 wrote: |
| Did you enable BKPT_SUPPORT in the makefiles for 1.7.2? I don't think the configure script sets it by default any more. I am starting to notice wierdness after hitting a breakpoint though -- I'll try 1.7.1 and see if it's any better. |
Absolute blinding work that man. configure.in has a change to the CXXFLAGS, -DBKPT_SUPPORT has gone awol. I changed that to support when dev-version compiled and also applied the above eabi change to debugger.cpp and now I can debug again in VBA 1.7.2. Insight/GDB has the usual problems, but this is a major plus for me. Thanks ribrdb2.
I've posted the patch to the VBA sourceforge project for anyone who might be interested.
#54653 - wintermute - Wed Sep 21, 2005 7:52 am
what version of Insight/gdb are you using?
I've just managed to get 6.3 up & running on windows and I'm having some weird problems with vba (sdl version) both 1.7.2 & 1.8.0.
I've applied your patch to vba but still no joy atm.
#54705 - Quirky - Wed Sep 21, 2005 8:52 pm
Well, it's funny you should say this.... I've just tried it again now, using insight and it doesn't blummin work. I don't know what I was smokin' before. The 'fix' worked when I tested it, perhaps it only sorts out the built-in debugger, which definitely works.
| Code: |
$ arm-elf-insight -v
GNU gdb 6.1
|
The problem I am seeing is this:
| Code: |
int main(void)
{ ************ BREAK HERE **********
initialise_gba();
while (1) {
// intro sequence
start();
main_loop(); ************ BREAK HERE **********
}
return 0;
}
|
It stops at main ok, but when I continue, it doesn't show the intro sequence, and breaks at some completely random unrelated place (a keypad interrupt for sleep mode fwiw).
If I use vba with the -d switch, internal debugger , place breaks at main and main_loop, it stops as expected. The code is compiled in dkarm r11 and debugs correctly in SDL 1.7
Why do I get a horrible feeling of deja vu?
#54885 - ribrdb2 - Fri Sep 23, 2005 8:25 am
Yes the fix is only for VBA's builtin debugger. I had to build the gdb source from CVS to get it to work. Don't know anything about insight.