AArch64 port general discussion thread

[a1batross]

AArch64 support is getting mandatory on many platforms. On iOS it's only supported for a long time and Play Market will require it at the end of this year, so Xash3D FWGS should be stable on AArch64 too.

While it should be easy for engine, as it ported for x86_64 already(thanks, @mittorn!), it's hard for games. I think engine should check ELFCLASS of game libraries and show an error, if library was built for 32-bit platform. It may be useful for x86_64 too!

Any suggestions or patches are welcome.

[ryan-sg]

Would it be possible to have build stop requiring flags to build on 64bit? Just let it build that way if CMake detects its on i.e. x86_64?

Another question in similar vein is if there can stop being '64' added to libs and stuff.

I hope this isn't too off-topic for this issue, but the above two things being resolved would make it a heck of a lot easier for me to get a port going for OpenBSD 👍 Otherwise I may need to have local patches to stop that from happening, as a port that generates different library filenames if 32 bit vs 64 bit can be a bit hard to work with.

If I understand your above proposal properly, using ELFCLASS to check would prevent the need for separate filenames as the engine can check what it needs yes?

Cheers :-)

[mittorn]

64bit build will be incompatible with mods. Just imagine number of issues like "This mod is known to be compatible with xash3d and why it does not work?" like in android version now

[nekonomicon]

@mittorn, BSD does not have multilib, so suffix "64" really looks strange on such OSes. Need to drop checks with "-m32" flag for BSD and arm too.

[a1batross]

@ryan-sg it's not offtopic :)

A "fool-check" for 64 bit was done for PC platforms, where engine should run games "out-of-box". And there is no games compiled for 64 bit. Because GoldSource, it had HLDS & CS server only for amd64 which aren't working anymore.

Mobile platforms is like a second chance for games to support 64 bit.

@mittorn That's why I suggest a runtime check. Engine should look into library header to make sure, does it compiled for 64 bits. If yes, it will loaded. If not, an error will be shown, like "install 32-bit engine". For Android I think we can provide a package for 32&64 bits by default and a compability package with only 32 bits libraries.

[mittorn]

But there are no reason to have 64bit engine on platforms with multilib availiable. We need disable 64bit on windows and linux by default. Some mods like XDM will not work in amd64/aarch64 engine correctly: it looses some models and i have no idea how to fix it.

[a1batross]

I said this already. PC platforms does have multilib and does not have games. There is no reason to allow 64 bit build without special key to CMake or Makefiles.

Mobile platforms(remember? It's about AArch64) may not have multilib. iOS already does not have it. I suppose Android will remove it in near future.

[mittorn]

aarch64 gcc does not support multilib at all, so non-x86 platforms should not have anything forcing -m32 (and there are no ia32 abi meant by -m32 on arm at all)

[a1batross]

I thought, forcing -m32 means switching triplet from x86_64-- to i686-- and similar on ARM: aarch64-- -> arm--.

So even code built with -m32 on 64 bit toolchain can be run on 32-bit machine.

[MoeMod]

I can build Linux, macOS, iOS to 64bit without any problem. However, it seems that the current string pool doesn't support 64bit on Android or Windows. Hope that it can be fixed. (tested on 0.19.2)

[mittorn]

on windows, we need to replace mmap by VirtualAlloc with fixed address. But i not sure if 64 bit version really need on windows (because x86 version will support mods without porting) But what wrong with android version? mmap fails? If string pool not allocated near the server, it still whould work correctly if you applied 64 bit support patches from hlsdk xash3d (fallback to ALLOC_STRING when MAKE_STRING does not fits to 32bit ptrdiff). It will allocate many strings, but it should be enough for multiplayer. BTW, on android it may be implemented different way: you may just load server library to specified address near engine. android linker has extension for that with android_dlopen_ext function. And third way is the way how original goldsource amd64 implementation worked: before enabling ASLR specially prelinked libraries was loaded to specific addresses. But i do not know, if ASLR may break prelink.

[MoeMod]

@mittorn I am still using NDK r12b to build the Android binary... maybe it's too outdated, and I will try with a newer one. For Windows, I feel it necessary to provide with 64bit binary if all game dlls needed can be complied on 64bit just for consistency. Dlls will be loaded to specific addresses only in legacy builds (such as 3266), but the ones on newer 5xxx, 6153, 7561, etc seems to be loaded to dynamic base address.

[a1batross]

@MoeMod anyway, Windows does allow and will allow run 32-bit apps. We already have problems with mods because of broken compatibility in GoldSrc: VGUI update in 2013 and SDL2 clients.

We use r10e for compiling Android port. android_dlopen_ext is supported since Android 21, i.e. Lollipop. Meanwhile, Lollipop was the first Android version introduced AArch64 support.

We can reserve address space and point android_dlopen_ext to it, so server code can be loaded near the game engine address space.

[MoeMod]

@MoeMod anyway, Windows does allow and will allow run 32-bit apps. We already have problems with mods because of broken compatibility in GoldSrc: VGUI update in 2013 and SDL2 clients.

We use r10e for compiling Android port. android_dlopen_ext is supported since Android 21, i.e. Lollipop. Meanwhile, Lollipop was the first Android version introduced AArch64 support.

We can reserve address space and point android_dlopen_ext to it, so server code can be loaded near the game engine address space.

[Windows x86_64] I can build with VS2017 and tested with Windows 10 1703 x64 and works fine now. And something should be modified, check https://github.com/FWGS/xash3d/pull/430

[Android arm64-v8a] With Android SDK 21 and NDK r12b, 0.19.2 can be built with dlsym_weak removed. However, it cannot load any .so library with both arm64-v8a and x86_64.

BTW, why are there client64.dll and menu64.dll but not mp64.dll / hl64.dll ???

[nekonomicon]

Valve used _i386 and _amd64 suffixes for linux libraries before steampipe update in 2013. No idea about libraries for Xash3D.

[a1batross]

Because Old Engine is a mess of hacked and quick solutions.

Different and not logic names, a big hack to support mostly non used anymore _amd64 GoldSource libraries and so on.

[mittorn]

It was not hack, just linux not used aslr and all libraries was fit to 32bit address space. And i think, it is still possible now, but only with prelink

[a1batross]

I mean, it's a hacky way to load them.

Yeah, things was changed when aslr was started to be used everywhere. But anyway, nothing was even compatible with 64bit HLDS, so... should we try to support this thing?

[mittorn]

hl, cs, metamod, amxmodx

[a1batross]

So wut? No one uses them in 64-bit versions today.

чт, 21 февр. 2019 г., 23:02 mittorn notifications@github.com:

hl, cs, metamod, amxmodx

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/358#issuecomment-466145431, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgV91qJ1SJvlOt9OE_lo1wihNa80_ks5vPvtVgaJpZM4SbGk2 .

[a1batross]

https://forums.alliedmods.net/showthread.php?t=46712

2006...