From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DFepAtldDGCASwAAWB0awg (envelope-from ) for ; Sat, 23 Jan 2021 12:33:13 -0500 Received: by simark.ca (Postfix, from userid 112) id EFB191EF80; Sat, 23 Jan 2021 12:33:12 -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.4 required=5.0 tests=DKIM_SIGNED,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,T_DKIM_INVALID,URIBL_BLOCKED autolearn=no 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 81C691E590 for ; Sat, 23 Jan 2021 12:33:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 909A0387090D; Sat, 23 Jan 2021 17:33:11 +0000 (GMT) Received: from gateway22.websitewelcome.com (gateway22.websitewelcome.com [192.185.46.194]) by sourceware.org (Postfix) with ESMTPS id A04793858025 for ; Sat, 23 Jan 2021 17:33:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A04793858025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway22.websitewelcome.com (Postfix) with ESMTP id B79AC6060 for ; Sat, 23 Jan 2021 11:33:07 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 3MmZlyBZMsvw93MmZlC1dL; Sat, 23 Jan 2021 11:33:07 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=41ojRGyjgsIlHLMG16tEOgpQrMMG0l/v24JGY1he7kY=; b=Ye6F+EDe/CFH9TDdEDY+MQmQ2T iT4fyVLdNf7mm9NGwSnvNm6xIqZ83HivhKD6l9cm1+Md8zrVGtcoYC5Io1KfPOabS9ZGDhE3zl/Bh ok4hEjD5j4qXN3NIE9x+b89NZ; Received: from 97-122-91-54.hlrn.qwest.net ([97.122.91.54]:55510 helo=localhost.localdomain) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l3MmZ-001ULq-FV; Sat, 23 Jan 2021 10:33:07 -0700 From: Tom Tromey To: Tom Tromey Subject: Re: [PATCH] sim: testsuite: push $arch out to targets References: <20210117160945.1362-1-vapier@gentoo.org> <20210118095201.GN265215@embecosm.com> <8735yv5qs3.fsf@tromey.com> <87lfclndee.fsf@tromey.com> X-Attribution: Tom Date: Sat, 23 Jan 2021 10:33:06 -0700 In-Reply-To: (Mike Frysinger's message of "Fri, 22 Jan 2021 23:35:31 -0500") Message-ID: <87eeib8sod.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.91.54 X-Source-L: No X-Exim-ID: 1l3MmZ-001ULq-FV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-91-54.hlrn.qwest.net (localhost.localdomain) [97.122.91.54]:55510 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Mike> it is kind of nice that you can connect/use the sim today with only gdb Mike> and not have to juggle another program (especially its lifecycle). We could keep "target sim" around as a simple wrapper for "target remote", and it could launch the sim for you. It's not quite as ideal as having the sim linked in -- the external sim could be misinstalled somehow -- but it seems like it would be good enough. >> This would support my long-term goal of making gdb always target-async. >> Not all the targets are async-ready, but remote-sim is one that really >> cannot be made async at all... Mike> couldn't it create the sim in a thread ? the sim should be maintaining Mike> all its own state by itself and not go smashing global state. or fork Mike> it as a background process and have gdb maintain a control pipe. I think the control pipe basically winds up as gdbserver. It would need some subset of the existing gdbserver commands -- fetch/store registers/memory, breakpoints, etc. It seems better not to invent another way to do this. A secondary goal for me is for all the targets in gdb to be multi-target-capable. If a sim needs globals, then that wouldn't work. If the sims are well-behaved about global state, then yes, threads would be ok. It was my impression, though, that they are not. Is that true? >> One problem with this idea is that the sim can renumber registers. >> So I guess the sims would have to send over an XML register description. >> Maybe there are gotchas here, I'm not sure. Mike> i'm not sure what you mean by the sim renumbering registers. I stumbled across this in gdbarch.sh: # MAP a GDB RAW register number onto a simulator register number. See # also include/...-sim.h. m;int;register_sim_regno;int reg_nr;reg_nr;;legacy_register_sim_regno;;0 This seems to be implemented by a number of architectures, though some of them seem to be unnecessary and/or copy-paste. I didn't really know how to tackle this and after poking at it a bit I got discouraged. I guess figuring out the XML stuff and hacking up the sim seemed like too much for a random side project. Also I don't really know how to run even the simplest thing in the sim. Is there a simple way to get started? >> Another problem is that this would lose CLI completion for sim commands. >> However I suppose we could add a remote protocol request for this if we >> really cared. Mike> i'm not familiar with the full range of the remote protocol. ignoring Mike> command completion, how would it even send custom commands ? i flipped Mike> through the manual but nothing caught my eye. The gdb "monitor" command sends a string to the remote for interpretation. I guess in this approach we could make the "sim" command an alias for "monitor". I see a few benefits from all this, including the multi-build stuff you are working on. We sometimes break remote-sim.c, because right now you have to specially request it for a particular target. If remote-sim were not linked to the sim itself, this would never be a problem. And, if the sim handled --enable-target=all, maintainers could simply build it all the time. thanks, Tom