From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EPvWAwlzumo96xEAWB0awg (envelope-from ) for ; Mon, 28 Sep 2026 10:00:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1790604040; bh=b87lBKxOWQpPPMpvnWo64B5cCTpcl8NxPjFp4wIHxWc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lgW25KL5RwH1AukYM30EcHJmZMjZrhqznr2v7o8vVy8hPdMmiprAzhSBnx2E9vYof RPU3vlwAy0gJRn/MudA+nFW+b1Zr+/tFGlFfFHd3NkWgcsK9n2y15/wc6dNQ0x3AEI Pctn2TT63E53xd37lrInDLK8dXgW50gmxhUX6mLw= Received: by simark.ca (Postfix, from userid 112) id EE8D11E01F; Mon, 28 Sep 2026 10:00:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=wnmIpXwi; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5D6701E01F for ; Mon, 28 Sep 2026 10:00:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D58E04BAE7D3 for ; Mon, 28 Sep 2026 14:00:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D58E04BAE7D3 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=wnmIpXwi Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D7B864BA2E27 for ; Mon, 28 Sep 2026 14:00:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D7B864BA2E27 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D7B864BA2E27 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790604014; cv=none; b=rMhHt+PjJ9GX6NDaYshFSN54DpdX4Wc7A0QJiI0Pkvx4EGlPIQzuxUQS+B5b/LPIReghPelKMoG5C+7vhLM2BVNYbhLF+AErI77zE2KdGEK8jkQqAWLjIpiZCRnUGkqCB5HHpWNiDHrN/wJ0OhP/i/Ygs0FpkPms09z0WMBTnFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790604014; c=relaxed/simple; bh=b87lBKxOWQpPPMpvnWo64B5cCTpcl8NxPjFp4wIHxWc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kbcNOWYW003afcRnaNZ9VN9266RfVvqnM88R4N/HXxNXrLWwanbmQrC2KqzQd6lqQJWBH7ToH/Wv4e6TcxFLzd5feetCam78UdrvfJ+sUCyJxLEO3+++k9xfY1Gd/3ozY6Jw9d9wYf6kVwzH6xf0aZE0VwPUK7J4rKv3zaCDmhY= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=wnmIpXwi DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D7B864BA2E27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1790604013; bh=b87lBKxOWQpPPMpvnWo64B5cCTpcl8NxPjFp4wIHxWc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=wnmIpXwio88axwihZ8cZUWIjeRaZtEwm3DmeOUgUC0zUBe8fqJHHFk+M5MYevewdg rtasDuKJEc3WlzbZkmkfq9/mVNSHjI3OF1YYceHSshlwPxUAQ/4/JZgHhqplb2CKwQ yojd5t1uS0YDIraWU65o3utxY9v3Z26FP4wax0JU= Received: by simark.ca (Postfix) id 027F61E01F; Mon, 28 Sep 2026 10:00:12 -0400 (EDT) Message-ID: <189579af-6c0d-4643-a26c-338dc34fe8b6@simark.ca> Date: Mon, 28 Sep 2026 10:00:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] H8/300: sim: Fix simulator hang caused by qsort on Windows/MinGW To: Jan Dubiec , gdb-patches@sourceware.org Cc: Jeffrey Law , Andrew Burgess References: <20260910020110.493902-1-jdx@o2.pl> Content-Language: fr From: Simon Marchi In-Reply-To: <20260910020110.493902-1-jdx@o2.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org 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