#55318 - Epinephrine - Tue Sep 27, 2005 6:41 pm
1. I started out with VBA 1.7 SDL after reading about the numerous issues with later versions.
2. I started with the latest devkitARM, but then went back to r8 after reading that the latest devkitARM doesn't work with VBA either.
I still can't debug. When I set breakpoints, either Visual Boy Advance or arm-elf-gdb (maybe both) appear to freeze (however, it does appear to execute to the first breakpoint, but seems to detach or something after that).
I had an account on gbadev.org a while back, but lost my login information, and have done some GBA programming before, so I'm not a newcomer trying to be out of line when I ask "Why aren't these issues resolved yet?" I have come back to GBA dev. for the time being... anyone want to try and tackle these things with me (fix the new versions of VBA)? Someone who knows a lot about the issues (Wintermute maybe?) perhaps? Am I correct in assuming that all of the issues are with VBA? If someone knows of a fully working (as a set) VBA version/devkitARM combination, and wouldn't mind helping me get up to speed debugging, I would appreciate it. I am surprised that the incompatibility issues have gone on for so long -- are people abandoning these tools simply to go on to more exciting things (Nintendo DS tools perhaps)? Thanks for any info.
#55328 - Quirky - Tue Sep 27, 2005 7:29 pm
VBA appears to be semi-abandoned. No release since May 2004. Though there have been updates to the Windows specific version outside the SF project these changes haven't found their way back into the main version, which is a real shame. There have also been changes made in CVS as recently as the start of September, so all may not be lost.
The problem with debugging seems to have occured around the 1.7 - 1.7.1 transition. I use VBA Linux SDL version 1.7 and r11 of dkarm for debugging with no problems. That's with Insight/gdb version 6.1.
#55331 - Epinephrine - Tue Sep 27, 2005 7:55 pm
Thank you. I will try devkitARM r11.
#55361 - cosmic4z - Wed Sep 28, 2005 12:54 am
Isn't DevkitARM just responsible for compilation / linking / production of the game ROM image or .ELF file?
Surely once that .ELF file is produced, DevkitARM has no place in debugging.
What gives? Am I missing something?
_________________
Qwak - www.qwak.co.uk | Forum - www.qwak.co.uk/forum/
#55363 - tepples - Wed Sep 28, 2005 1:33 am
It's alleged that there are some incompatibilities between the dialect of ELF produced by a given version of devkitARM and the dialect of ELF understood by VisualBoyAdvance. Whether the deviation from the ELF spec is in devkitARM or in VBA is the issue.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#55440 - cosmic4z - Wed Sep 28, 2005 3:03 pm
tepples wrote: |
It's alleged that there are some incompatibilities between the dialect of ELF produced by a given version of devkitARM and the dialect of ELF understood by VisualBoyAdvance. Whether the deviation from the ELF spec is in devkitARM or in VBA is the issue. |
Ahh, that makes sense, thanks tepples.
I also have problems debugging .ELF files (that I've created with devkitARM) on a snsystems hardware debugger (.ELF files created by their tool-chain work fine though).
Do the various dialects actually stay within the .ELF standard, or are they breaking the rules alltogether?
Is there any way to convert from one dialect to another? Should be possible to code an app for that I should think, perhaps I'm showing my ingnorance though :o
_________________
Qwak - www.qwak.co.uk | Forum - www.qwak.co.uk/forum/
#55444 - wintermute - Wed Sep 28, 2005 3:30 pm
tepples wrote: |
It's alleged that there are some incompatibilities between the dialect of ELF produced by a given version of devkitARM and the dialect of ELF understood by VisualBoyAdvance. Whether the deviation from the ELF spec is in devkitARM or in VBA is the issue. |
There isn't any deviation in either.
The arm eabi and the ELF format was updated around the time of the r11 release, neither gdb nor vba are currently capable of working with it. In the case of VBA this is exhibited by some labels being displayed as tags instead of the actual label and an inability to place thumb breakpoints via labels. The breakpoint issue can be worked around by using a patch which is available here -> http://sourceforge.net/tracker/index.php?func=detail&aid=1264075&group_id=63889&atid=505531
In the case of insight/gdb support for the new eabi is still working it's way in and currently thumb code from versions later than r8 cannot be debugged.
#55451 - NoMis - Wed Sep 28, 2005 4:15 pm
So basically we will need a new version of GDB and it will work with the VBA Fix applied?
NoMis
_________________
www.gamedev.at - The austrian gamedev site
hde.gamedev.at - The Handheld Dev Env plugins for Eclipse
#55459 - wintermute - Wed Sep 28, 2005 6:18 pm
NoMis wrote: |
So basically we will need a new version of GDB and it will work with the VBA Fix applied?
NoMis |
They're two entirely separate issues. A version of gdb that understood the latest eabi would work perfectly well with an unpatched VBA. The VBA fix is only for the internal debugger.
#55464 - paladine - Wed Sep 28, 2005 7:03 pm
I am using gcc 3.3 series in addition to gdb 6.0 with VBA 1.7. It works for me.
#55467 - Quirky - Wed Sep 28, 2005 7:36 pm
wintermute wrote: |
They're two entirely separate issues. A version of gdb that understood the latest eabi would work perfectly well with an unpatched VBA. The VBA fix is only for the internal debugger. |
According to ribrdb2 the gdb in cvs is patched to take care of this. I might try it out now, see how it goes, though cvs builds are usually a touch "fruity".
EDIT: just tried the nightly GDB CVS snapshot (gdb-6.3.50.20050928) with the very latest VBA and it displays the same behaviour as the last Linux SDL release and insight 6.1. i.e. breaks fine at main, but any break after that and it's pot luck where it stops.
#55545 - Epinephrine - Thu Sep 29, 2005 6:57 am
Some new questions after playing w/ some things today.
1. I just now realized (even though I've heard other mention it... even in this thread) that VBA has an internal debugger. Is this debugger pretty sufficient? Is it often that you need to rely on GDB to solve a problem, or is using GDB more of a preference?
2. If I understand what everyone is saying, I should be able to use a NEW gdb/insight, r8 devkitARM, and the VBA 1.7.1 SDL together with no problems?
3. "In the case of insight/gdb support for the new eabi is still working it's way in and currently thumb code from versions later than r8 cannot be debugged." Is there a way to compile in non-thumb mode (for devkitARM releases post-r8), and if so, do some of these incompatibility issues go away?
Thanks again.
#55553 - wintermute - Thu Sep 29, 2005 9:20 am
Quirky wrote: |
wintermute wrote: | They're two entirely separate issues. A version of gdb that understood the latest eabi would work perfectly well with an unpatched VBA. The VBA fix is only for the internal debugger. |
According to ribrdb2 the gdb in cvs is patched to take care of this. I might try it out now, see how it goes, though cvs builds are usually a touch "fruity".
EDIT: just tried the nightly GDB CVS snapshot (gdb-6.3.50.20050928) with the very latest VBA and it displays the same behaviour as the last Linux SDL release and insight 6.1. i.e. breaks fine at main, but any break after that and it's pot luck where it stops. |
Yep, I have exactly the same problems here, trying to figure out how gdb is supposed to recognise thumb code atm. Running one native gdb on vba and another on arm-elf-gdb while debugging a gba elf is such fun :)
#55591 - ribrdb2 - Thu Sep 29, 2005 8:07 pm
Quirky wrote: |
wintermute wrote: | They're two entirely separate issues. A version of gdb that understood the latest eabi would work perfectly well with an unpatched VBA. The VBA fix is only for the internal debugger. |
According to ribrdb2 the gdb in cvs is patched to take care of this. I might try it out now, see how it goes, though cvs builds are usually a touch "fruity".
EDIT: just tried the nightly GDB CVS snapshot (gdb-6.3.50.20050928) with the very latest VBA and it displays the same behaviour as the last Linux SDL release and insight 6.1. i.e. breaks fine at main, but any break after that and it's pot luck where it stops. |
Did you compile VBA with -DBKPT_SUPPORT? I don't believe it is enabled by default in the latest version. The easiest fix is to search for -DDEV_VERSION in configure and add -DBKPT_SUPPORT, then reconfigure.
#55594 - wintermute - Thu Sep 29, 2005 8:32 pm
CVS gdb still doesn't recognise thumb instructions and tries to set ARM breakpoints. I've tried in both windows & linux.