spirv: Fix gl_spirv_validation when OpLine with strings is present

Fix issue by handling the OpString instructions when walking through
the preamble for validation.

The gl_spirv_validation() creates a vtn_builder() and walks the
instructions looking for a subset of the information.  However
our current way to walk the instructions will also perform tracking
of OpLine/OpNoLine, that may make references to OpString instructions
that were being previously ignored by gl_spirv_validation().
This would cause the parsing to fail.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9004
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22973>

1 files changed, 9 insertions, 1 deletions

diff --git a/src/compiler/spirv/gl_spirv.c b/src/compiler/spirv/gl_spirv.c
index 5ef38928edd..9b5e351c6c0 100644
--- a/src/compiler/spirv/gl_spirv.c
+++ b/src/compiler/spirv/gl_spirv.c
@@ -33,14 +33,22 @@ vtn_validate_preamble_instruction(struct vtn_builder *b, SpvOp opcode,
                                   const uint32_t *w, unsigned count)
 {
    switch (opcode) {
+   case SpvOpString:
    case SpvOpSource:
    case SpvOpSourceExtension:
    case SpvOpSourceContinued:
+   case SpvOpModuleProcessed:
+      /* We need this since vtn_foreach_instruction automatically handles
+       * OpLine / OpNoLine and relies on the SpvOpString from preamble being
+       * handled.
+       */
+      vtn_handle_debug_text(b, opcode, w, count);
+      break;
+
    case SpvOpExtension:
    case SpvOpCapability:
    case SpvOpExtInstImport:
    case SpvOpMemoryModel:
-   case SpvOpString:
    case SpvOpName:
    case SpvOpMemberName:
    case SpvOpExecutionMode: