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 searching for the ...

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 division by 0 ...

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", but they do not appear in ...

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 ...

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 ...

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 ...