#164270 - strat - Sat Oct 25, 2008 4:15 am
Looking through a disassembly of the game I'm working on (using arm-eabi-objdump -D), it has three lines that say "Address is out of bounds" They show up in section .bss, .debug_info, and .debug_line. I know .bss is the initialization of RAM, but how would I correct that in the debug sections? I'm hoping this solves the mystery of why this rom works in VBA and GBA, but crashes in no$.
#164271 - Cydrak - Sat Oct 25, 2008 5:48 am
Well, if you go in with a hex editor, you should find these don't even appear in the final NDS image... which is normal. BSS is zeroed at runtime, and debug sections have little use on the NDS itself. So, I doubt this would affect anything.
As for the strange message, "objdump -D" will grind through everything, even data. Although it stops at the end of each section, it looks like it's trying to disassemble the "last instruction" even if there aren't enough bytes left. You can see this from the size in the section table ("arm-eabi-objdump -x foo.elf").
Use "-d" if you want code, "-s" for a hex dump with runtime offsets. Arguments like "-j.data" (just section .data) are also useful.
#164287 - silent_code - Sun Oct 26, 2008 10:19 am
I am not very well informed about this (I haven't looked into it for a long time), but I'll post this anyway, so you can check it out for yourself. Also, I just got up. :^p
Isn't the bigger address space just wrapped to the physical size?
Some addresses are also mapped multiple times, sometimes with different functionality, like without caching.
Anyways, Cydrak's post sounds reasonable. :^)
Does it work on hardware?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#164295 - strat - Mon Oct 27, 2008 7:29 am
Yeah, it runs on hardware. Also it's a GBA game.
It runs on hardware and VisualBoyAdvance, but not nocash which is supposed to be a more accurate emulator. For some reason nocash says it has exactly one error and that low power mode is not supported. So I'm worried that this error will drain the battery even if it runs on hardware (it uses the VBlankIntrWait bios call and an isr, so that's not an issue).
I found that pre-allocating too much EWRAM causes the game to break in nocash, but it also happened after adding an array of function pointers to a subroutine.
I'm hoping the no$ debugger would be helpful, but apparently there's no way to get it if Martin's not around.
Cydrak - You're probably right that what I found in the dump doesn't affect anything. I was hoping it would be another cause.