From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4JLlOuLMCGBEbQAAWB0awg (envelope-from ) for ; Wed, 20 Jan 2021 19:37:54 -0500 Received: by simark.ca (Postfix, from userid 112) id 616301EF80; Wed, 20 Jan 2021 19:37:54 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 62D311E590 for ; Wed, 20 Jan 2021 19:37:53 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B44D9385782F; Thu, 21 Jan 2021 00:37:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B44D9385782F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611189472; bh=aRzJGxQY0OV0PIB2mpdW01S656285mNHChsjwFW4te0=; 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=pO+9wh85AVT9zJBjx3t6QAyYlxjDDnsEJxtDpta0kdNGH4zknShjTCc6zlDouIog5 /gUmp5rwsDxHLe0w+3q7GvpTXhmR+IcEkGBeoiws5YZXeXoRSSXGKYzAkaj87aeR3i fqpYhiTK4+Z/XusqO2Vs+kjZiCwCAbvC4VjseDvg= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id B9BF2385782F for ; Thu, 21 Jan 2021 00:37:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B9BF2385782F 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 82AF1340F46; Thu, 21 Jan 2021 00:37:46 +0000 (UTC) Date: Wed, 20 Jan 2021 19:37:45 -0500 To: Tom Tromey Subject: Re: [PATCH] sim: testsuite: push $arch out to targets Message-ID: Mail-Followup-To: Tom Tromey , Andrew Burgess , gdb-patches@sourceware.org References: <20210117160945.1362-1-vapier@gentoo.org> <20210118095201.GN265215@embecosm.com> <8735yv5qs3.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8735yv5qs3.fsf@tromey.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 Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 20 Jan 2021 12:53, Tom Tromey wrote: > Mike> as we do multibuilds, we'll have multiple ports active, so a single > Mike> variable won't cut it. moving it here and out of autotols enables > Mike> that. as we do multitarget, this will help smooth the transition as > Mike> we won't have to juggle each arch as it migrates. > > I'm curious to hear about the plan here, specifically if you plan to > tackle the "gdb can only include one sim" problem. i've been slowly reworking the sim core to flip it from "the port owns the central data structure" to "the core owns everything, and ports are just given a pointer to their data structure". that would allow for the core to pick the backend instead of the backend picking the core. there's other settings that make this difficult in the sim as it binds a lot of configure-time settings into the build (like register & addresss sizes & endianness). so i'd expect at first we'd be able to do compatible ports in a single build (e.g. all 32bit little endian). where to go from there will require experimentation. i'm thinking the core compiles all variants (32/64 le/be) and then the ports use defines to pick the right ones for their subdir. part of this work has been removing the ability for ports to deviate at all: just make a single decision in the core, and everyone uses that. we've given ports way too much leeway for too long. at the very least, i have it working now where each subdir can be built and installed in a single build. this is helpful for doing quick tests that changes at least compile. obviously can't link a single gdb from this, but gotta start somewhere. i'm trying to do this incrementally rather than flip a switch and have everyone migrate in a single commit. especially because not all ports support even the common/ code atm. sim $ ls aarch64 config.cache d10v h8300 m32r mips ppc testsuite arm config.log erc32 igen m68hc11 mn10300 pru v850 avr config.status foo iq2000 Makefile moxie rl78 bfin cr16 frv lm32 mcore msp430 rx bpf cris ft32 m32c microblaze or1k sh sim $ ls */run */libsim.a aarch64/libsim.a d10v/run m32r/libsim.a msp430/run aarch64/run erc32/libsim.a m32r/run or1k/libsim.a arm/libsim.a erc32/run m68hc11/libsim.a or1k/run arm/run frv/libsim.a m68hc11/run ppc/libsim.a avr/libsim.a frv/run mcore/libsim.a ppc/run avr/run ft32/libsim.a mcore/run pru/libsim.a bfin/libsim.a ft32/run microblaze/libsim.a pru/run bfin/run h8300/libsim.a microblaze/run rl78/libsim.a bpf/libsim.a h8300/run mips/libsim.a rl78/run bpf/run iq2000/libsim.a mips/run rx/libsim.a cr16/libsim.a iq2000/run mn10300/libsim.a rx/run cr16/run lm32/libsim.a mn10300/run sh/libsim.a cris/libsim.a lm32/run moxie/libsim.a sh/run cris/run m32c/libsim.a moxie/run v850/libsim.a d10v/libsim.a m32c/run msp430/libsim.a v850/run -mike