[PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW

[PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW

[Jan Dubiec]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3329 bytes --]

On Windows, qsort() uses an unstable sorting algorithm, which results
in a "shuffled" opcode table rather than a properly sorted one, causing
the entire simulator to hang.

The simulator happens to work on Linux, but this behavior is not
guaranteed, because the glibc documentation clearly states that "If
two elements compare equal, their order after sorting is unpredictable."

This patch introduces two additional sort keys to the instruction
comparator function, making the resulting opcode table as close as
possible to the one that would be produced by a stable sorting algorithm.

It also fixes an issue in the instruction decoder where, for example,
mov.l @er7+,er1 is recognized as ldm.l @er7+,(er0-er1) if the opcode
table is sorted “the wrong way”, i.e. when ldm appears before mov
in the table.

No regressions were found.

---
 sim/h8300/compile.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/sim/h8300/compile.c b/sim/h8300/compile.c
index 06988095228..0feb58fe183 100644
--- a/sim/h8300/compile.c
+++ b/sim/h8300/compile.c
@@ -509,7 +509,15 @@ decode (SIM_DESC sd, sim_cpu *cpu, int addr, unsigned char *data, decoded_inst *
 		}
 	      else if ((looking_for & MODE) == DATA)
 		{
-		  ;			/* Skip embedded data.  */
+		  /* Special case for ldm.l and stm.l. Otherwise, if the
+		    h8_opcodes[] table is sorted in a particular order,
+		    the instruction decoder may incorrectly recognize
+		    e.g. mov.l @er7+,er1 as ldm.l @er7+,(er0-er1).  */
+		  if (((OP_KIND (q->how) == O_LDM) ||
+		       (OP_KIND (q->how) == O_STM)) &&
+		      ((thisnib < 1) || (thisnib > 3)))
+		    goto fail;
+		  /* Skip embedded data for the rest.  */
 		}
 	      else if ((looking_for & MODE) == DBIT)
 		{
@@ -1586,6 +1594,7 @@ instruction_comparator (const void *p1_, const void *p2_)
 {
   struct h8_opcode *p1 = (struct h8_opcode *)p1_;
   struct h8_opcode *p2 = (struct h8_opcode *)p2_;
+  int cmp;
 
   /* The 1st sort key is based on whether or not the
      instruction is even available.  This reduces the
@@ -1605,7 +1614,45 @@ instruction_comparator (const void *p1_, const void *p2_)
     return p2_available - p1_available;
 
   /* Secondarily sort based on the first opcode nibble.  */
-  return p1->data.nib[0] - p2->data.nib[0];
+  if (p1->data.nib[0] != p2->data.nib[0])
+    return p1->data.nib[0] - p2->data.nib[0];
+
+  /* The 3rd sort key  */
+  cmp = strcmp (p1->name, p2->name);
+  if (cmp)
+    {
+      /* Two different opcodes  */
+      size_t l1 = strlen (p1->name);
+      size_t l2 = strlen (p2->name);
+      ptrdiff_t i1 = strchr (p1->name, '.') - p1->name;
+      ptrdiff_t i2 = strchr (p2->name, '.') - p2->name;
+      char c1, c2;
+
+      if ((l1 == l2) && (i1 == i2) && (i1 > 0))
+	{
+	  /* Check for different mnemonics of the same length,
+	     e.g. add.w vs. and.b  */
+	  cmp = strncmp (p1->name, p2->name, i1);
+	  if (cmp)
+	    return cmp;
+
+	  /* At this point we expect only b, w or l suffix,
+	     where b < w < l  */
+	  c1 = p1->name[i1+1];
+	  c2 = p2->name[i2+1];
+	  if (c1 == 'b')
+	    return -1;
+	  else if (c1 == 'w')
+	    return (c2 == 'b') ? 1 : -1;
+	  else
+	    return 1;
+	}
+
+      return cmp;
+    }
+
+  /* The 4th sort key  */
+  return p1->how - p2->how;
 }
 
 
-- 
2.55.0

Re: [PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW

[Jan Dubiec]

Gentle ping.

/J.D.

Re: [PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW

[Simon Marchi]

On 9/9/26 9:58 PM, Jan Dubiec wrote:
> On Windows, qsort() uses an unstable sorting algorithm, which results
> in a "shuffled" opcode table rather than a properly sorted one, causing
> the entire simulator to hang.
> 
> The simulator happens to work on Linux, but this behavior is not
> guaranteed, because the glibc documentation clearly states that "If
> two elements compare equal, their order after sorting is unpredictable."
> 
> This patch introduces two additional sort keys to the instruction
> comparator function, making the resulting opcode table as close as
> possible to the one that would be produced by a stable sorting algorithm.
> 
> It also fixes an issue in the instruction decoder where, for example,
> mov.l @er7+,er1 is recognized as ldm.l @er7+,(er0-er1) if the opcode
> table is sorted �the wrong way�, i.e. when ldm appears before mov

The characters around "the wrong way" seem to suffer from bad encoding.

> @@ -1605,7 +1614,45 @@ instruction_comparator (const void *p1_, const void *p2_)
>      return p2_available - p1_available;
>  
>    /* Secondarily sort based on the first opcode nibble.  */
> -  return p1->data.nib[0] - p2->data.nib[0];
> +  if (p1->data.nib[0] != p2->data.nib[0])
> +    return p1->data.nib[0] - p2->data.nib[0];
> +
> +  /* The 3rd sort key  */
> +  cmp = strcmp (p1->name, p2->name);
> +  if (cmp)
> +    {
> +      /* Two different opcodes  */
> +      size_t l1 = strlen (p1->name);
> +      size_t l2 = strlen (p2->name);
> +      ptrdiff_t i1 = strchr (p1->name, '.') - p1->name;
> +      ptrdiff_t i2 = strchr (p2->name, '.') - p2->name;
> +      char c1, c2;
> +
> +      if ((l1 == l2) && (i1 == i2) && (i1 > 0))
> +	{
> +	  /* Check for different mnemonics of the same length,
> +	     e.g. add.w vs. and.b  */
> +	  cmp = strncmp (p1->name, p2->name, i1);
> +	  if (cmp)
> +	    return cmp;
> +
> +	  /* At this point we expect only b, w or l suffix,
> +	     where b < w < l  */
> +	  c1 = p1->name[i1+1];
> +	  c2 = p2->name[i2+1];
> +	  if (c1 == 'b')
> +	    return -1;
> +	  else if (c1 == 'w')
> +	    return (c2 == 'b') ? 1 : -1;
> +	  else
> +	    return 1;
> +	}
> +
> +      return cmp;
> +    }
> +
> +  /* The 4th sort key  */
> +  return p1->how - p2->how;

I'd suggest using a

  SIM_ASSERT (p1->how != p2->how)

above, since we never want two entries to compare equal.

Otherwise, I don't have enought knowledge about this architecture to
really review the patch.

Simon