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 > easy guru exception handler

#162041 - a128 - Sat Aug 23, 2008 11:12 pm

Here is a modified guru exception handler.

http://www.freewebtown.com/festival2005/EasyGuruStacktrace.tgz

Use
Code:
STACK_TRACE();


in your code. The handler records the last 21 STACK_TRACE() calls and prints the history (filename + line number) at guru meditation on the top screen of the NDS. Hope it's usefull for someone.
It prints somethink like that

Trace1:Yourfile.cpp 234

234 is the linenumber of that STACK_TRACE()

#162043 - chuckstudios - Sun Aug 24, 2008 12:02 am

Firefox does not like your webhost because it is a "Reported Attack Site!".

#162050 - a128 - Sun Aug 24, 2008 8:40 am

chuckstudios wrote:
Firefox does not like your webhost because it is a "Reported Attack Site!".


This is offtopic but ok,

http://forums.mozillazine.org/viewtopic.php?f=38&t=812995

I do not care if FF via google blocks a whole domain. Which is craszy because freewebtown is a free web hoster . Are all pages infected ?

Last edited by a128 on Sun Aug 24, 2008 2:29 pm; edited 1 time in total

#162054 - keldon - Sun Aug 24, 2008 12:17 pm

000webhost.com uses subdomains, rather than subdirectories - making it much easier for google to make web browsing safer.

Sure it could be argued that the web will still not be 100% safe as warnings do not guarantee complete freedom from malware, but common sense will tell you that being warned of 90% is much safer than being warned of 0% ^_^

#162055 - Maxxie - Sun Aug 24, 2008 12:56 pm

a128 wrote:

Use
Code:
STACK_TRACE();



Why don't you walk the stack (possibly LR itself on the first iteration) for values that point directly after a BX(non lr), BL ,BXL & co? Instead of actively marking your way on the cost of cpu time and programming overhead in each project you want to get traced.
_________________
Trying to bring more detail into understanding the wireless hardware

#162057 - a128 - Sun Aug 24, 2008 2:28 pm

Maxxie wrote:

Why don't you walk the stack (possibly LR itself on the first iteration) for values that point directly after a BX(non lr), BL ,BXL & co? Instead of actively marking your way on the cost of cpu time and programming overhead in each project you want to get traced.


what do you mean?
Feel free to improve my method and let's share this via source code

looking thru registers is not very sexy..sometimes

#162179 - chishm - Wed Aug 27, 2008 2:05 pm

Maxxie wrote:
Why don't you walk the stack (possibly LR itself on the first iteration) for values that point directly after a BX(non lr), BL ,BXL & co? Instead of actively marking your way on the cost of cpu time and programming overhead in each project you want to get traced.

One possible problem is that there's no tracking of the stack window. Once you go up to the parent function you won't be able to tell how large its stack window was or where the LR was saved. At least without tracing through the function's return code.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#162183 - Maxxie - Wed Aug 27, 2008 4:35 pm

chishm wrote:
Maxxie wrote:
Why don't you walk the stack (possibly LR itself on the first iteration) for values that point directly after a BX(non lr), BL ,BXL & co? Instead of actively marking your way on the cost of cpu time and programming overhead in each project you want to get traced.

One possible problem is that there's no tracking of the stack window. Once you go up to the parent function you won't be able to tell how large its stack window was or where the LR was saved. At least without tracing through the function's return code.


That is not a real problem.

The return addresses are pretty obvious to spot (Addressrange and content just before), and it is very unlikely that you push such an address onto the stack that points just behind a call/branch that is not a bx lr and in the right form (arm/thumb)

The few cases that it will create false positives shouldn't bother. And might (if they really bother you) be filtered by limiting the address of the suspected callee somewhere near the already identified point of execution.


Shame i can't work on it right now.
_________________
Trying to bring more detail into understanding the wireless hardware