From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eF2oDuNFvmfZsT0AWB0awg (envelope-from ) for ; Tue, 25 Feb 2025 17:36:19 -0500 Received: by simark.ca (Postfix, from userid 112) id 39B571E105; Tue, 25 Feb 2025 17:36:19 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 C6FEA1E05C for ; Tue, 25 Feb 2025 17:36:18 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B9C93858C60 for ; Tue, 25 Feb 2025 22:36:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B9C93858C60 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id 408463858CD9 for ; Tue, 25 Feb 2025 22:35:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 408463858CD9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 408463858CD9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740522939; cv=none; b=Fm6nJ4gg8TzeNm3mycqaB9SAyM0UnvCNPu9/WPT2EGmTJ4hwYJa30pFHMmUKycIgIlKuwX8hfmSQrwzgXjosbBeFiE+8Wkq5HQQOUiLZV6qqFTEQwYkANhAByN5/9XDdhT/wQDv9ZBoRm/kwVLRYZT8p28DYYGNWgb+QKj+KuqM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740522939; c=relaxed/simple; bh=5fEhcz8UzZcQV6sInQSekI/zSVjBwE1JISlvZdwHfxE=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=U64SSk/lBx4r6kjYJpoUuntfM8DiXPjcdVuvI8R1J//f4CeoGkyiz4gLCZClR9RyNPiY/8SWe7/3RxjFYbLAlm7STVwke7uOMurNSRXlD8I2e0+fQxT90eMMPNr3kNgWxg7LgoWUPeeYcPuM0m6jmfbUbNlf9Ug4y38Jj1/KWL0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 408463858CD9 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 7337B92009C; Tue, 25 Feb 2025 23:35:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 6C34992009B; Tue, 25 Feb 2025 22:35:38 +0000 (GMT) Date: Tue, 25 Feb 2025 22:35:38 +0000 (GMT) From: "Maciej W. Rozycki" To: Milica Matic cc: Djordje Todorovic , Milos Kalicanin , Simon Marchi , Chao-ying Fu , Andrew Burgess , Kevin Buettner , gdb-patches@sourceware.org Subject: Re: [PATCH v12 2/2] gdb: mips: Add MIPSR6 support In-Reply-To: <20250219130125.356900-4-milica.matic@htecgroup.com> Message-ID: References: <20250219130125.356900-1-milica.matic@htecgroup.com> <20250219130125.356900-4-milica.matic@htecgroup.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Wed, 19 Feb 2025, Milica Matic wrote: > Introduce new instruction encodings from Release 6 of the MIPS > architecture [1]. Support breakpoints and single stepping with > compact branches, forbidden slots, new branch instruction and > new atomic load-store instruction encodings. I have now skimmed over your change and obviously branch decoding is the huge update and the most problematic part. At high level I find new code a little bit hairy and hard to follow in some places, and will go over it in details double-checking all is in order, and maybe trying to untangle it a little. I won't be able to do it before this coming weekend though at which point I'm going on holiday for a fortnight. Please be a little patient meanwhile. Also you may have seen my response to an earlier version where I reported how I tried to do verification against my 74K Malta only to see it run unreliably. Sadly the 5Kc core card I previously used broke a couple of years ago and the replacement newer module does not seem to run equally well (also it's 32-bit only while the 5Kc was 64-bit). I suspect it just wasn't debugged as thoroughly as the older one, there are issues with PCI handling both in Linux and even in the YAMON firmware, and I think this instability in running GDB verification can be attributed to cache coherency maintenance issues in Linux, which can be hairy. I may not have the resources available at hand though to get it sorted quickly. It doesn't appear to me that the 74K core card is at fault as I have two of them, slightly different and carrying a 74Kc and a 74Kf each, so if it was owing to a faulty card, then I imagine they wouldn't behave exactly the same. Also glibc and GCC verification seems more reproducible. The old 5Kc core card was rock-solid, I used it for 20 years until it failed. So instead I made an attempt the other day to use alternate test machines I have in my remote lab, and that also hit obstacles. One of the systems refused to respond on the serial console. I've seen it before and it is likely owing to its lithium coin cell powering the configuration memory having run out of energy, making the system revert to the video console, which I have no remote access to. So I cannot make use of that machine for the time being, until the cell has been replaced and configuration restored. The other system booted just fine and completed reference GDB testing. On second iteration however it broke with uncorrectable multiple-bit ECC errors reported by DRAM making the system unusable. The errors persisted after a reboot and firmware testing pointed at just one problematic DRAM module (out of eight installed total). I have seen this before as well and cleaning contacts and/or reseating the module should clear the issue. At worst the module can be removed, reducing system RAM from 256MiB down to 224MiB, which should still be fine for the purpose of this testing. I have a maintenance visit scheduled to my lab tomorrow, so I'm going to address these issues. I'll report back and, fingers crossed, I should at least be able to verify the lack of regressions from your change for older systems, possibly by the end of this week. I will appreciate your understanding of my constraints. Maciej