gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Using Moonshell to discover bugs

#168143 - headspin - Sat Apr 11, 2009 5:34 am

During the testing of a game I'm writing I've found that running it from Moonshell on the GBA Movie Player sometimes the game will crash and from that have found a bug in the game (an str to the wrong register for example).

Would this be because IWRAM is not clear when the game is run? Is it possible to have some sort of loader for Slot-1 cards that will essentially fill IWRAM before running the game to help track down bugs? Perhaps using dmaFillWords with 0xFFFFFFFF?
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#168144 - TwentySeven - Sat Apr 11, 2009 11:46 am

I was always partial to 0xDEADBEEF

#168146 - Mighty Max - Sat Apr 11, 2009 11:50 am

How about using a different crt0 for testing builds that does some fuzzing with the uninitialized memory before jumping to your code?
_________________
GBAMP Multiboot

#168148 - headspin - Sat Apr 11, 2009 1:33 pm

TwentySeven wrote:
I was always partial to 0xDEADBEEF


Of course! Good point!

Mighty Max wrote:
How about using a different crt0 for testing builds that does some fuzzing with the uninitialized memory before jumping to your code?


I guess I would have to figure out where the unintialized memory is and how large it is before filling it. Any ideas on how to go about that?
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#168150 - Mighty Max - Sat Apr 11, 2009 2:24 pm

The end and start of the several sections are stored in some symbols. Have a look at te linkscript for their names. Add some more if you need more for detailed infos where what is.
_________________
GBAMP Multiboot

#168157 - headspin - Sun Apr 12, 2009 8:00 am

I don't believe knowing where the sections are is enough to get the location of unallocated memory and the size of it. There in the problem writing over itself.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#168159 - Mighty Max - Sun Apr 12, 2009 10:00 am

Oh it does.

If you would have had a look at the named files you know which memory areas are allready initialzied and which ones are at a state where a loader could have left data.

The ds_arm9_crt0.s does copy data to
- __itcm_start to __itcm_end
- __dtcm_start to __dtcm_end
and clears data at
- __bss_start to __bss_end
- __sbss_start to __sbss_end

it does not do anything (and thus might be vulnerable to junk) at
- fake_heap_start - fake_heap_end
- __ewram_end to __ewram_end +4k (where the firmware stores user settings, exception vector etc)
- special memory sections (i.e. graphics ram)
_________________
GBAMP Multiboot

#168160 - headspin - Sun Apr 12, 2009 11:55 am

Added the following to "initSystem" which is called by the arm9 crt0 just after it does some memory clearing.

Code:
ldr r0, =0xDEADBEEF
ldr r1, =fake_heap_start
ldr r2, =fake_heap_end
sub r2, r1
bl dmaFillWords

ldr r0, =0xDEADBEEF
ldr r1, =__ewram_end
ldr r2, =4096
bl dmaFillWords


The write to __ewram_end causes a crash on hardware and even manages to crash No$ after a while.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

#168161 - Mighty Max - Sun Apr 12, 2009 12:44 pm

Yes it does. As expected ;-)

There are some vital data points in that part, that's why it isn't used as heap. You need to keep that in mind when fuzzing. (Old IPC-Struct, Exception Vector and Stack, Card-Header-Info [including that startup loop of passme])

The values are usually initialized by the firmware on startup, but there is no warrenty that it isn't manipulated by a seperate loader. Doesn't mean that you can write everything there ;-) just that you could notice and ths have to expect some (limited) changes in there
_________________
GBAMP Multiboot