Fix ABI identifier of loongarch64 in specification/loader/runtime.adoc.

[qiangxuhui]

Fix the ABI identifier of loongarch64 in specification/loader/runtime.adoc. Similar to x86_64 and aarch64, the ABI identifier of loongarch64 should match the output of $(uname -m):

OpenXR-SDK-Source:/# uname -m
loongarch64

[rpavlik]

We cannot change this now without breaking compatibility, FYI. The original identifier was chosen due to matching Debian, IIRC, which is the pattern where it made sense on less common architectures. See https://wiki.debian.org/LoongArch and https://wiki.debian.org/Ports/loong64

How prevalent is OpenXR usage on loongarch64? Is it still in testing/development or is there actually usage in the field? Is there a runtime that uses it? (does Monado run?) I'm trying to judge the impact of making this breaking change.

I do not have a loongarch64 machine (or remote access to one) to test on. Is there some way access to a machine can be arranged?

What is the benefit of making this change? For the most part, the only code that needs to care about this is the loader (which is already done), and however one installs a runtime manifest, if you are installing multiple architectures of the client side of your runtime but the .so filename differs or otherwise cannot use the same soname in the respective dynamic loader search path. (This -- just specifying soname and placing runtime in dynamic loader search path -- is how the loader was intended to be used for multi-arch on Linux, and how e.g. the Monado packages on Debian are meant to work. The architecture suffixes were primarily for Android where the runtime typically cannot be placed in the default dynamic loader search path.)

[sunhaiyong1978]

“Loongarch64” is the official architecture name, most software that uses $(uname -m) output ("loongarch64") as the architecture name, such as Linux kernel, gcc, binutilities, Python, LLVM, etc., all use "loongarch64" as the architecture judgment and setting name in code. The distribution managed by RPM package also uses "loongarch64", such as Alpine. Only some software and distributions rename this architecture name, such as debian,golang， But usually these software or distributions also rename other architectures, such as "x86_64->amd64","aarch64->arm64"。
Because other architectures in OpenXR-SDK software use the output of $(uname -m) as XR_ARCH-ABI, such as "x86_64","aarch64"， So using "loongarch64" here can be done in the same way as other architectures.

[rpavlik]

Thanks for that info. This does make sense, though I wish this had been raised before this was originally merged.

Can you address my other questions? (existing openxr software on the arch that would be potentially broken by this, access to dev/test hardware)

[sunhaiyong1978]

Thanks for that info. This does make sense, though I wish this had been raised before this was originally merged.

Can you address my other questions? (existing openxr software on the arch that would be potentially broken by this, access to dev/test hardware)

LoongArch is a relatively new architecture, I haven't found any damage at the moment.

[rpavlik-bot]

An issue (number 2429) has been filed to correspond to this pull request in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2429 ), to facilitate working group processes.

This GitHub pull request will continue to be the main site of discussion.