devkitPro

Except that, as far as I can tell from digging through this code what it's actually supposed to do is raise a signal which can potentially make use of the unwind machinery. In our case we don't have signal handlers since there's no underlying OS and, as far as I can tell, no exception will ever be thrown.

tueidj wrote:I say leave it as is. If I want an exception when I divide by zero then I should get one. If someone else doesn't, they can write their own long division function.

The division by zero handler it uses is completely blank, and can't possibly throw any exceptions.

WinterMute wrote:devkitARM is intended to be a lot more generic than just a compiler that targets GBA/NDS so I need to be pretty careful about making changes for one particular use case.

In our case we don't have signal handlers since there's no underlying OS

Well something doesn't seem right here, either it should be suitable to use as a generic compiler or it's only useful for standalone "bare-metal" apps.

By generic I mean useful for a range of arm processors and a bare metal environment, trying to support all possible configurations of board and OS is probably not feasible.

People use devkitARM for GBA, DS, Wii starlet code and a crazy variety of arm based experimenter boards, I try to keep things as platform agnostic as possible. For instance, quite a few people have asked for the tools to use the DS hardware math functions and/or the GBA bios provided math functions instead of the gcc provided libraries - obviously stuff like this is going to make it harder to then build code that runs on something like a Leaflabs Maple board.

devkitARM release 35 should fix this for you - http://devkitpro.org/viewtopic.php?f=13&t=2952

let me know if it's still pulling in anything odd.

Works perfectly now, big thanks!