From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cvToFOcHF2DEbwAAWB0awg (envelope-from ) for ; Sun, 31 Jan 2021 14:41:27 -0500 Received: by simark.ca (Postfix, from userid 112) id 47CD81EF80; Sun, 31 Jan 2021 14:41:27 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 4A9A31E945 for ; Sun, 31 Jan 2021 14:41:22 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C8E9C3857C68; Sun, 31 Jan 2021 19:41:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C8E9C3857C68 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1612122081; bh=maJwj0hwCiTWyC1ACMVzgaoZY9tDPZzXm4k5qp7dc6Q=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=vcK7yOpwT3eNVn+buy3rZtsU/GRA7UyGBrcHUuECKtrT+zdv+Vx8UiVWN2eV3Kcvl 5JTDROZMw6Nu+oxtGh7Cr+zBeERC8MjgCKa9/5+C5YhJp6rUI/dceHoetD3zVBXxaE AT9AB3zGBvCsrX0h1gEY1S5vBZweFAKbCMrGyOo0= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 52E9D3857C68 for ; Sun, 31 Jan 2021 19:41:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52E9D3857C68 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 7A794340F2B for ; Sun, 31 Jan 2021 19:41:18 +0000 (UTC) Date: Sun, 31 Jan 2021 14:41:17 -0500 To: gdb-patches@sourceware.org Subject: Re: [PATCH] sim: testsuite: push $arch out to targets Message-ID: Mail-Followup-To: gdb-patches@sourceware.org References: <20210117160945.1362-1-vapier@gentoo.org> <20210118095201.GN265215@embecosm.com> <20210121092253.GW265215@embecosm.com> <20210131105438.GQ265215@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210131105438.GQ265215@embecosm.com> 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 Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 31 Jan 2021 10:54, Andrew Burgess wrote: > * Mike Frysinger [2021-01-22 01:36:05 -0500]: > > On 21 Jan 2021 09:22, Andrew Burgess wrote: > > > * Mike Frysinger [2021-01-18 13:01:53 -0500]: > > > > On 18 Jan 2021 09:52, Andrew Burgess wrote: > > > > > * Mike Frysinger [2021-01-17 11:09:45 -0500]: > > > > > > This is needed to move to automake & its dejagnu-provided logic, > > > > > > and eventually by the unified sim logic. > > > > > > > > > > I looked through this patch and I didn't understand what's going on > > > > > here. > > > > > > > > > > If this needs doing at all, could it not be done in some global location? > > > > > > > > the sim ports use a unique subdir for their `run` program. the tests > > > > need to find that path. this $arch value is what binds the specific > > > > subdir to the test. > > > > > > I don't understand that paragraph I'm afraid. > > > > > > I guess my question is each *.exp file gets invoked by dejagnu, but > > > there are other hooks that dejagnu calls, like the ${tool}_init proc. > > > Could we not use that to set these things instead? It seems like > > > there's a 1:1 mapping between [istarget ????] patterns and the values > > > pushed into both arch and all_machs. > > > > i'm not seeing how any hooks would help. the targets need to know where > > their sim program lives. let me brain dump on you :p. > > > > lets look at a bfin & frv build tree. > > build-bfin-elf/ > > `-- sim/ > > `-- bfin/ > > `-- run > > build-frv-elf/ > > `-- sim/ > > `-- frv/ > > `-- run > > > > sim/testsuite/frv/*.exp files need to know to look for $(builddir)/frv/run > > while sim/testsuite/bfin/*.exp files need $(builddir)/bfin/run. > > > > i know the variable is called $arch and that can be confusing. i could > > rename it if it helps. just keep in mind that this is used for exactly > > one thing: where to find `run` under $(builddir)/. > > > > when we invoke dejagnu, it was with --tool=sim. if we had combined trees > > with other tools (gas/gdb/etc...), this would make sense, but it doesn't, > > so we changed it to --tool="". now when you run `runtest`, it will find > > all *.exp files under sim/testsuite/ and attempt to execute them. > > OK. I don't understand why changing tool from "sim" to "" is either > necessary, or a good thing, but, whatever.... i covered that here: https://sourceware.org/pipermail/gdb/2021-January/049098.html https://sourceware.org/pipermail/gdb-patches/2021-January/175115.html > For gdb we have a 'gdb_init' proc, which is called based on > '${tool}_init' from within GDB. Now that we have no tool set does > this prevent us having an 'init' proc? it does not mean that. we have `sim_init` in lib/sim-defs.exp and it is still called via config/default.exp. (i'll delete the part of your email below that talks about not having it) > Lets assume for one moment that we _did_ have an init proc. Could > that proc not just have one huge [istarget ???] { set arch ... } tree > that handled all known istarget patterns? we could do that. i don't think that's better than what i'm proposing with setting the arch in the / subdirs. it seems slightly worse because the [istarget ???] patterns that we use in the / subdirs need to be replicated -- some have a 1-to-many map of arch-to-targets. although we can prob have the centralized logic use target mappings that capture more than necessary as long as it's still unique between each other. e.g. we can glob cris* even though the cris port itself uses cris-*-* & crisv32-*-*. imo, this is the wrong direction: anytime we have a centralized place where we have arch-specific logic, we're doing it wrong. we already have a centralized list today that i want to move away from. the sim/configure.tgt is setting up $arch based on the target. but it doesn't work when doing multi-target (--enable-targets=all) because there isn't a single port testsuite to bind to, hence it needs a new home. > I think you say that right now we have pretty much one test script for > each arch, but there's no reason which this has to be the case > forever, right? correct. but i don't see how that's necessarily relevant to this thread. even if we were to fragment the arch .exp files (somewhat akin to what gdb does with some of its testsuites), we would still be able to have each port share a common file (e.g. testsuite/bfin/common.exp) where we could put the arch-specific settings. on a related note, imo, dejagnu is a dead end. Ian wrote a good post: https://www.airs.com/blog/archives/499 but dejagnu is even more unnecessary for the sim as we have no need for any of the target hooks. e.g. the ability for people to say "in order to execute this program, copy the file to this remote system, then ssh over to it, and run it like so". those are useful to gas, gdb, etc... but would never be used by the sim. so really we should be looking at throwing out dejagnu entirely from the sim and switching to something like automake's builtin test runners. we use this in some projects in the tree already when the test does not require any target execution. > It just seems weird to me to say that each test is required to start > with a highly predictable bit of boiler plate... i don't disagree. but to be clear, i don't see any of this as the end state long term. this is all intermediate steps for a better future. sometimes that process means taking on a little tech debt to unblock the next step, and then slowly collapsing that back as the common code improves. so here we're taking a configure-time constant that locks the testsuite to a single specific target and moving it to the tests. then as we unify the sim ports into a single build, we'd delete the setting from their testsuites in the process. -mike