[SPIR-V] Incorrect encoding for string literals on big-endian machines

[cwabbott0]

The SPIR-V spec says, in the definition of "literal string," "the UTF-8 octets (8-bit bytes) are packed four per word, following the little-endian convention (i.e., the first octet is in the lowest-order 8 bits of the word)." But when emitting literal strings here, we just reinterpret an integer as a character array, which won't work on big-endian systems, since we'll end up packing them according to the big-endian convention instead.

[johnkslang]

Agreed glslang is creating octets in address order instead of significant-byte order, and hence glslang only generates correct SPIR-V when executing on a little-endian system.

[tjaalton]

so this is why the tests fail on s390x/sparc/power/hppa?

[johnkslang]

If we have a real big-endian system to test glslang on, I can fix this.

[tjaalton]

should've failed on m68k too, but didn't:
https://buildd.debian.org/status/package.php?p=glslang

[mhillenbrand]

This issue has surfaced in QtShaderTools on s390x and ppc64, where the implementations in glslang and SPIRV-cross conflict: glslang encodes strings incorrectly while spirv-cross attempts to decode them correctly, resulting in reordered characters (https://bugreports.qt.io/browse/QTBUG-93101).

Both the SPIR-V generation and disassembly use incorrect encoding/decoding, so calling gslangValidator -H (generating binary SPIR-V and then disassembling) produces correct output, while the binary results are clearly wrong. Thus, it appears to me that none of the test failures are caused by this issue, since they are checking against the textual representation. Vice versa, fixing SPIR-V generation and not yet the disassembler introduces new test failures.

[mhillenbrand]

I have a fix mostly working for the encoding and for the "disassembly" and printing of strings. I still need to change how the disassembly code collects id descriptions (decorations), as in

        Name 23  \"FragColor\"
        Decorate 9 Location 0
        Decorate 23(garFoloC) RelaxedPrecision
        Decorate 23(garFoloC) Location 0

[mhillenbrand]

For reference, other issues about endianness: #2797 #2802