From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ynOoJda+gGC5SAAAWB0awg (envelope-from ) for ; Wed, 21 Apr 2021 20:09:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 8CA971F104; Wed, 21 Apr 2021 20:09:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D68EA1E783 for ; Wed, 21 Apr 2021 20:09:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2FD0C3857809; Thu, 22 Apr 2021 00:09:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2FD0C3857809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619050197; bh=ZiTFlBORgp6Nkxs0ArJsu3W+LG/Gqy7D7KXnTJwqiSE=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VWvh+oTrz6bkW3oZjCZS4jQ9cvkENnUzrLdd60PrEfmT3c1etCWU+A+XF7AxwSPvx 08BOPrNYpodMW3nbEtmfOVyveZDHgFKhqVlLBuNtNRFZZkGGHWjVZB3oH2xM4kJbKY Od2nrzJBSemV5U2TvyYXtnYkJdgHFGTOAOb2P5wU= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 4140E3857C74 for ; Thu, 22 Apr 2021 00:09:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4140E3857C74 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 504A833FE60; Thu, 22 Apr 2021 00:09:54 +0000 (UTC) Date: Wed, 21 Apr 2021 20:09:52 -0400 To: Jim Wilson Subject: Re: [PATCH 03/24] RISC-V sim: Atomic fixes. Message-ID: Mail-Followup-To: Jim Wilson , gdb-patches@sourceware.org, Kito Cheng References: <20210417175831.16413-1-jimw@sifive.com> <20210417175831.16413-4-jimw@sifive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: Kito Cheng , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 21 Apr 2021 16:00, Jim Wilson wrote: > On Sun, Apr 18, 2021 at 8:56 PM Mike Frysinger wrote: > > On 17 Apr 2021 10:58, Jim Wilson wrote: > > > Handle aq and rl. Fix wrong value when rd is zero register. Fix > > > amoswap when rd and rs2 are the same register. > > > > lgtm. can you add tests for these things, and for the other fixes ? > > Tests for these amo issues would be useful, as this isn't well tested by > the gcc testsuite. I will look into that. > > Most of the other stuff is well tested just by running the gcc testsuite. imo, "just run the gcc testsuite" is not reasonable. it is extremely large and slow and not conducive to iterative/fast development. it happening to hit a bug sometimes depending on the current codegen behavior isn't the same as having good targetted logic. that isn't to say the gcc testsuite isn't valuable. it certainly is as a large stress when you're pretty confident that the sim/whatever is ready to run against it. but i'm not running it every day (or even some months) when working on the sim, and most projects i've worked on run it daily at best on servers. that said, i'm not advocating for 1000% coverage on the sim side. having a few important high level things to start with is fine, and then taking the approach like gcc where we fill it out based on regressions. > I'm working on the gdb sim as a side project while working on other > projects, and if I have to write a lot of tests there could be a > significant delay in completing the patch set. I'd prefer if some of this > stuff could be handled with follow up patches. my concern is that this becomes a convenient "we'll get to it later" and then later never comes. i'm not saying you don't have good intentions, but they often don't last with real world pressures. the only carrot/leverage that exists is not yet being merged. so maybe, maybe, you get a pass now, but this isn't the status quo moving forward. -mike