Issue with code generation with larger executables

[gameblabla]

This needs more tests but it was annoying enough that i feel like i should post about it here... Whenever the program becomes sufficiently large (in my case, it was only 6.1kb large for the final compiled binary) when frame pointer + mprolog-function (the latter implies the former), the application will start misbehaving or crash. The moment i disabled those + -fomit-frame-pointer, it started to work again (i did not have to change my code). I encountered this with not just one program but several others. I don't think its a coincidence but perhaps it is. I thought you had fixed that in 2022 or so but i guess it was another issue xox

EDIT: It seems that it was a coincidence and it still happens even with those two disabled. As soon as the executable reaches a certain size, the issue happens.

[gameblabla]

I have attached an example (both with prebuilt binaries) : one with just extra lines of code

eris_low_cdda_set_volume(63,63);
eris_pad_init(0);
eris_king_set_kram_read(0, 1);
eris_king_set_kram_write(0, 1);

and one without (the extra lines don't do anything here, it's just to increase the codesize to trigger the bug).

Works works.zip

Doesn't boot doesntwork.zip

I noticed that for affected executables that if you run them from FX-BMP instead they would start to work sometimes. But since this example relies on CD access, that's no solution.

The generated source code isn't of much use either, it's almost identical. This seems to indicate a linker issue of sorts. Doesn't boot :

    .file   "scsi_dma.c"
    .section    .text.startup,"ax",@progbits
    .align 2
    .global _main
    .type   _main, @function
_main:
    mov lp, r1
    jal __save_r29_fp
    mov 0,r6
    jal _Initialize_ADPCM
    jal _eris_king_init
    jal _eris_tetsu_init
    movea 63,r0,r6
    mov r6,r7
    jal _eris_low_cdda_set_volume
    mov 0,r6
    jal _eris_pad_init
    mov 0,r6
    mov 1,r7
    jal _eris_king_set_kram_read
    mov 1,r7
    mov 0,r6
    jal _eris_king_set_kram_write
    mov 5,r6
    jal _Set_Video
    mov 6,r6
    movea 512,r0,r7
    movhi hi(122880),r0,r8
    movea lo(122880),r8,r8
    jal _eris_cd_read_kram
    movea 84,r0,r6
    movea 26624,r0,r8
    movhi hi(60416),r0,r29
    movea lo(60416),r29,r29
    mov r29,r7
    jal _eris_cd_read_kram
    mov 0,r6
    mov r29,r7
    movea 26624,r0,r8
    jal _Play_ADPCM
.L2:
    br .L2
    .size   _main, .-_main
    .ident  "GCC: (GNU) 4.9.4"

Boots :

    .file   "scsi_dma.c"
    .section    .text.startup,"ax",@progbits
    .align 2
    .global _main
    .type   _main, @function
_main:
    mov lp, r1
    jal __save_r29_fp
    mov 0,r6
    jal _Initialize_ADPCM
    jal _eris_king_init
    jal _eris_tetsu_init
    mov 5,r6
    jal _Set_Video
    mov 5,r6
    movea 512,r0,r7
    movhi hi(122880),r0,r8
    movea lo(122880),r8,r8
    jal _eris_cd_read_kram
    movea 83,r0,r6
    movea 26624,r0,r8
    movhi hi(60416),r0,r29
    movea lo(60416),r29,r29
    mov r29,r7
    jal _eris_cd_read_kram
    mov 0,r6
    mov r29,r7
    movea 26624,r0,r8
    jal _Play_ADPCM
.L2:
    br .L2
    .size   _main, .-_main
    .ident  "GCC: (GNU) 4.9.4"

[jbrandwood]

The VirtualBoy dev community has been using this compiler for quite some time and successfully generating roms much larger than 6 or 7KB. Please provide more information, and an example of exactly where you believe that the linker is creating an incorrect relocation.

[gameblabla]

Yeah my bad : P I forked the pcfx stnicc demo and started from here, and it was able to compile fine this time... I looked at the makefile and it seemed no different besides O3.

I'm a bit baffled as to why this would happen but i'm guessing that i'm probably not dealing with the KRAM and stuff properly hence the weird behaviour. the STNICC was much bigger afterall...

I'll close this for now but if i can find the true cause, i will open this again.