Trying to a build classic_armv8_a35 libretro core

[asoderq]

Hi Irixxxx,

I am trying to build a slightly modified target of classic_armv8_a35 in Makefile.libretro. Only thing I have changed are some flags that my compiler didn't like, namely: -marm -mfpu=neon-fp-armv8 -mfloat-abi=hard. I get errors when linking the library, example:

pico/memory.c:168:1: note: type 'u32' should match type 'uint16_t'
pico/memory.c:168:1: note: 'm68k_read16' was previously declared here
pico/memory.c:168:1: note: code may be misoptimized unless -fno-strict-aliasing is used
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `MAC_L':
<artificial>:(.text+0x740): undefined reference to `p32x_sh2_read32'
/usr/bin/ld: <artificial>:(.text+0x77c): undefined reference to `p32x_sh2_read32'
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `MAC_W':
<artificial>:(.text+0x8f8): undefined reference to `p32x_sh2_read16'
/usr/bin/ld: <artificial>:(.text+0x934): undefined reference to `p32x_sh2_read16'
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `scan_block':
<artificial>:(.text+0x3f64): undefined reference to `p32x_sh2_get_mem_ptr'
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `sh2_drc_mem_setup':
<artificial>:(.text+0x5848): undefined reference to `Pico32xMem'
/usr/bin/ld: <artificial>:(.text+0x5850): undefined reference to `Pico32xMem'
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `sh2_drc_flush_all':
<artificial>:(.text+0x58c8): undefined reference to `Pico32xMem'
/usr/bin/ld: <artificial>:(.text+0x58d8): undefined reference to `Pico32xMem'
/usr/bin/ld: <artificial>:(.text+0x5a10): undefined reference to `Pico32xMem'
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o:<artificial>:(.text+0x5b3c): more undefined references to `Pico32xMem' follow
/usr/bin/ld: /tmp/ccL31RkD.ltrans0.ltrans.o: in function `ILLEGAL':

The list goes on, but all seems related to 32x. Any idea what is wrong, or what I am doing wrong? I am using a debian based arm64 qemu chroot, installed according to these instructions: https://github.com/christianhaitian/arkos/wiki/Building#to-create-debian-based-chroots-in-a-linux-environment

EDIT: Full log is here: https://pastebin.com/HCvyuGJD

[irixxxx]

That warning stems from a wrong extern declaration in platform/libretro/libretro.c, just change the return type to uint32_t.

However, I have no idea why all those symbols are reported missing. The functions are definitely there, they are declared and defined globally, and the object file containing them is included in the link instruction. Really strange.

[irixxxx]

Ah, I just saw that pico/32x/memory.c and pico/32x/sh2soc.c are the only files compiled with -fno-lto. The reason for this is roughly explained in the Makefile (just look for no-lto). Seems like you need to take out that -fno-lto, and the arm64 declaration for the SH2 SR register in cpu/sh2/compiler.h. That will however come at the cost of being a bit slower for 32X.

[asoderq]

Thanks for the hints. Wasn't sure what to change in cpu/sh2/compiler.h, so I decided to build it without lto which also works. However Demons of Asteborg save states are still broken, that was the reason I wanted to build it, to test that.

[irixxxx]

How exactly was your test scenario?

[asoderq]

1. Start new game
2. Go to the second area.
3. Create save state.
4. Restart the game.
5. Immediately on logo load state.
6. The level loads with enemies, no glitchy graphic but sound is glitchy.
7. As soon as you go forward one area it hangs with black screen.

It does seem to have improved though, as the graphics no longer are glitchy.

[irixxxx]

Are you using the games' built-in save function, or are you saving the emulator state via retroarch?

[asoderq]

I am using save state via retroarch.

[irixxxx]

Ah ok. The fix I took over only fixes in-game saving/loading via the save ram on the cart. I was not aware that save/load via the emulator isn't ok. However, working on that is on my work list for 1.99 anyway.

[irixxxx]

Could you possibly check with a current build from my repo? I improved save/load of the VDP state, that might at least improve the case here.

[asoderq]

I will try it, at latest during the weekend.

[asoderq]

Nope, still doesn't work.

[irixxxx]

Hmm, I fixed an issue where save/load of the bad apple demo failed due to incomplete restore of the ssf2 bank mapping. I suspect this might also be the case for your issue. Could you check this again please?

[asoderq]

Yes, it seems to work now. Thanks a lot!

[irixxxx]

Fixed as a sideeffect by f8dba3f. Thanks for testing.