slaanesh
Certified Guru
I seem to be having some problems with constructors in C++. It looks like they are not firing at all.
I'm using the EABI SDL++ libraries with devkitARM release 26 toolchain.
Linking with -nostartfiles -specs=gp32.specs crt0.o
The gp32.specs is from devkitARM.
Sample Code:
GpPrintf is my debugging function which lets me print as per printf-like statements.
The above debug is printing (null) when I am clearly expecting it to be "/gpmm/kuklomen" (yes, I'm trying to port Kuklomenos).
There seem to be other bits of code that are exhibiting similar behavior - values are not initialized.
It seems like the .init_array list of constructor functions is NOT being called.
What am I doing wrong? Comments and help very welcome.
I know there are workarounds for the above example, but I'd like to get a real fix for this (if indeed this is the problem).
I'm thinking it's something in crt0.o which is built from the following EABI SDL++ file.
The official GPSDK calls something like __libc_init_array() but there's nothing like this here.
And as far as I can see, the EABI SDL++ libc.a does not have a __libc_init_array() - though some other equivalent maybe. Dunno.
I'm using the EABI SDL++ libraries with devkitARM release 26 toolchain.
Linking with -nostartfiles -specs=gp32.specs crt0.o
The gp32.specs is from devkitARM.
Sample Code:
Code:
const string dataPath = "/gpmm/kuklomen/";
ifstream* openDataFile(string relPath)
{
ifstream* f = new ifstream;
GpPrintf("%s", dataPath.c_str());
f->open((dataPath+relPath).c_str(), ios::binary);
return f;
}GpPrintf is my debugging function which lets me print as per printf-like statements.
The above debug is printing (null) when I am clearly expecting it to be "/gpmm/kuklomen" (yes, I'm trying to port Kuklomenos).
There seem to be other bits of code that are exhibiting similar behavior - values are not initialized.
It seems like the .init_array list of constructor functions is NOT being called.
What am I doing wrong? Comments and help very welcome.
I know there are workarounds for the above example, but I'd like to get a real fix for this (if indeed this is the problem).
I'm thinking it's something in crt0.o which is built from the following EABI SDL++ file.
The official GPSDK calls something like __libc_init_array() but there's nothing like this here.
And as far as I can see, the EABI SDL++ libc.a does not have a __libc_init_array() - though some other equivalent maybe. Dunno.
Code:
@////////////////////////////////////////////////////////////////////////////@
@/ crt0.S /@
@////////////////////////////////////////////////////////////////////////////@
.TEXT
.CODE 32
.ALIGN
.GLOBAL _start
.GLOBAL atexit
.GLOBAL exit
.EXTERN main @ user entry point
.EXTERN x_gp32_SetPrintBase
.EXTERN x_gp32_ShutdownGraphics
.EXTERN x_gp32_SetLcdBuffer
.EXTERN x_gp32_init_timer
.EXTERN x_gp32_initFramebuffer
.EXTERN SmcInit
_start:
b start_vector
@ AXF addresses
_text_start:
.word __text_start
_ro_end:
.word __ro_end
_data_start:
.word __data_start
.word __bss_end
_bss_start:
.word __bss_start
_bss_end:
.word __bss_end
@ GamePark magic sequence
.word 0x44450011
.word 0x44450011
.word 0x01234567
.word 0x12345678
.word 0x23456789
.word 0x34567890
.word 0x45678901
.word 0x56789012
.word 0x23456789
.word 0x34567890
.word 0x45678901
.word 0x56789012
.word 0x23456789
.word 0x34567890
.word 0x45678901
.word 0x56789012
start_vector:
mrc p15, 0, R5, c1, c0, 0 @ read control register
bic r5,r5,#2 @ align control OFF
orr r5,r5,#0x1000
orr r5,r5,#4
mcr p15, 0, R5, c1, c0, 0 @ write control register
ldr sp, =0x0c78fffc
bl SmcInit
@ mov r0, #8
@ bl x_gp32_SetGraphicsMode
mov r1, #8 @ BPP
mov r2, #60 @ refresh rate
mov r0, #208666624 @ framebuffer base
add r0, r0, #737280 @ framebuffer address
bl x_gp32_initFramebuffer
mov r0, #208666624
add r0, r0, #737280
bl x_gp32_SetLcdBuffer
mov r0, #208666624
add r0, r0, #737280
bl x_gp32_SetPrintBase
bl x_gp32_init_timer
bl main @ jump to entry point
exit:
bl x_gp32_ShutdownGraphics
ldr lr,=0x00000000
@ dummy function to keep gcc happy
atexit:
mov pc,lr
.POOL
.END