So, apparently, I was able to get raspi-armhf native to build with few issues by configuring in a separate build directory (Well, actually I did have to comment out the build rule for workbench-datatypes-heic, since that library tries to use C++ exceptions, even though they are disabled in the compiler flags). No idea why it decided to work this time.
I've started debugging with qemu and gdb, but I've noticed something strange. Many of the jump labels are offset by +8, and this seems to make function calls not work properly (basically skipping the function prologue), and I can't breakpoint on functions either because of this. You can see this in the objdump output (notice the +0x8 on all the bl instructions).
AROS-build/bin/raspi-arm/gen/rom/boot/aros-arm-raspi.img.elf: file format elf32-littlearm
Disassembly of section .text:
00008000 <bootstrap>:
8000: e10f4000 mrs r4, CPSR
8004: e204401f and r4, r4, #31
8008: e3a0801a mov r8, #26
800c: e1540008 cmp r4, r8
8010: 0a000007 beq 8034 <leave_hyper>
00008014 <continue_boot>:
8014: f1020013 cps #19
8018: e59fd030 ldr sp, [pc, #48] ; 8050 <tmp_stack_ptr>
801c: ee114f50 mrc 15, 0, r4, cr1, cr0, {2}
8020: e384460f orr r4, r4, #15728640 ; 0xf00000
8024: ee014f50 mcr 15, 0, r4, cr1, cr0, {2}
8028: e3a04101 mov r4, #1073741824 ; 0x40000000
802c: eee84a10 vmsr fpexc, r4
8030: ea000096 b 8290 <boot+0x8>
00008034 <leave_hyper>:
8034: e24f4028 sub r4, pc, #40 ; 0x28
8038: e12ef304 .word 0xe12ef304
803c: e10f4000 mrs r4, CPSR
8040: e204401f and r4, r4, #31
8044: e3844013 orr r4, r4, #19
8048: e16ef304 .word 0xe16ef304
804c: e160006e .word 0xe160006e
00008050 <tmp_stack_ptr>:
8050: 00000ff0 45562400 61203a52 72736f72 .....$VER: arosr
8060: 69707361 676d692e 30347620 2036342e aspi.img v40.46
8070: 6e754a28 20323220 33323032 00000029 (Jun 22 2023)...
00008080 <query_vmem>:
8080: e92d40f0 push {r4, r5, r6, r7, lr}
8084: e30d0244 movw r0, #53828 ; 0xd244
8088: e24dd014 sub sp, sp, #20
808c: e3400000 movt r0, #0
8090: e3076000 movw r6, #28672 ; 0x7000
8094: e3406003 movt r6, #3
8098: eb0003c0 bl 8fa0 <kprintf+0x8>
809c: e3a03a01 mov r3, #4096 ; 0x1000
80a0: e3a05000 mov r5, #0
80a4: e3a04008 mov r4, #8
80a8: e3a02020 mov r2, #32
80ac: e5832000 str r2, [r3]
80b0: e5835004 str r5, [r3, #4]
80b4: e3a02006 mov r2, #6
80b8: e3402001 movt r2, #1
80bc: e5832008 str r2, [r3, #8]
80c0: e583400c str r4, [r3, #12]
80c4: e1a02003 mov r2, r3
80c8: e5835010 str r5, [r3, #16]
80cc: e30b7880 movw r7, #47232 ; 0xb880
80d0: e5835014 str r5, [r3, #20]
80d4: e1a01004 mov r1, r4
80d8: e5835018 str r5, [r3, #24]
80dc: e583501c str r5, [r3, #28]
80e0: e5960000 ldr r0, [r6]
80e4: e0870000 add r0, r7, r0
80e8: eb000444 bl 9200 <vcmb_write+0x8>
80ec: e5960000 ldr r0, [r6]
80f0: e1a01004 mov r1, r4
80f4: e0870000 add r0, r7, r0
80f8: e3a07003 mov r7, #3
80fc: eb000427 bl 91a0 <vcmb_read+0x8>
8100: e1a04000 mov r4, r0
8104: e5901014 ldr r1, [r0, #20]
8108: e5942018 ldr r2, [r4, #24]
810c: e30d025c movw r0, #53852 ; 0xd25c
8110: e3400000 movt r0, #0
8114: eb0003a1 bl 8fa0 <kprintf+0x8>
8118: e596c004 ldr ip, [r6, #4]
811c: e3a0301c mov r3, #28
8120: e34833d0 movt r3, #33744 ; 0x83d0
8124: e3a0201d mov r2, #29
8128: e34823d0 movt r2, #33744 ; 0x83d0
812c: e58c3000 str r3, [ip]
8130: e3a03001 mov r3, #1
8134: e5941014 ldr r1, [r4, #20]
8138: e28cc010 add ip, ip, #16
813c: e50c2008 str r2, [ip, #-8]
8140: e594e014 ldr lr, [r4, #20]
8144: e5942018 ldr r2, [r4, #24]
8148: e50c100c str r1, [ip, #-12]
814c: e5940014 ldr r0, [r4, #20]
8150: e08ee002 add lr, lr, r2
8154: e5941014 ldr r1, [r4, #20]
8158: e5942018 ldr r2, [r4, #24]
815c: e50ce004 str lr, [ip, #-4]
8160: e586c004 str ip, [r6, #4]
8164: e58d5008 str r5, [sp, #8]
8168: e88d00a0 stm sp, {r5, r7}
816c: eb00035d bl 8ee8 <mmu_map_section+0x8>
8170: e28dd014 add sp, sp, #20
8174: e8bd80f0 pop {r4, r5, r6, r7, pc}
It seems the raspi-armhf-system nightly from April 30th also has this issue.
