devkitPro

Also, there's another problem. In crt0, it overwrites the SBSS section with junk data, because it's copying from __ewram_start__ to __ewram_end__, which is past the end of the SBSS section. It should be copying up to __sbss_start__ instead. In the crt0.s file, change this: @-------------------------...

I was just spending the last few hours trying to track down a problem in devkitarm. I was having a problem where "__data_start__" came in memory after "__data_end__", so when the crt0 code copies data into ram, it copies a negative number (big number) of bytes, and crashes. After...

Works perfectly now, big thanks!

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.

Here, I'm doing a 64-bit unsigned division. This is a call to the function __aeabi_uldivmod. So it depends on these functions: __aeabi_uldivmod from _aeabi_uldivmod.o __aeabi_ldiv0 from _dvmd_tls.o (this appears to be a blank function, the only content is "bx lr", it's probably the divisio...

I have now tried that, but it didn't work. My makefile line now looks like LDFLAGS = -g $(ARCH) -Wl,-Map,$(notdir $@).map,--gc-sections EDIT: When I look through "libgcc.a", I see this odd symbol table stuff in "bpabi.o". There are references to "aeabi_unwind_cpp_pr0", ...

I have confirmed that including this ASM code makes 64-bit division compatible with NO$GBA: .text .align .pool .global __aeabi_ldivmod .global __aeabi_uldivmod __aeabi_ldivmod: cmp r3, #0 cmpeq r2, #0 bne 0f cmp r1, #0 cmpeq r0, #0 movlt r1, #-2147483648 @ 0x80000000 movlt r0, #0 mvngt r1, #-2147483...

I'm sorry, it's just that these posts usually come immediately after I've been trying for about 4 hours to frantically figure out what's going on, and I'm really frustrated at the time I'm posting them. I just really don't understand how code that isn't referenced anywhere ends up in the program. Wh...

I'm used to getting compiler errors when you try to promote a const u32* to a plain u32*. Is this a non-standard extension of GCC that a const pointer can be promoted to a non-const void pointer, or is it perfectly legal?
I do get warnings when it happens.

I'm having problems with unnecessary code getting linked into my project. I can't figure out where these symbols are coming from: abort _Unwind_decode_target2 __aeabi_unwind_cpp_pr0 restore_core_regs __gnu_unwind_execute __libc_init_array After I disassemble my .elf file with objdump, I can't find a...