From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40051 invoked by alias); 22 Mar 2018 11:45:47 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 39933 invoked by uid 89); 22 Mar 2018 11:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*Ad:D*ne.jp, H*Ad:U*gdb, sh2, H*Ad:D*jp X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 11:45:33 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2MBjHAH012154 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 22 Mar 2018 07:45:22 -0400 Received: by simark.ca (Postfix, from userid 112) id C1F8D1E7A6; Thu, 22 Mar 2018 07:37:10 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id B7A2D1E4B2; Thu, 22 Mar 2018 07:37:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 22 Mar 2018 11:45:00 -0000 From: Simon Marchi To: Rich Felker Cc: gdb@sourceware.org, John Paul Adrian Glaubitz , Hector Oron , Nobuhiro Iwamatsu , takasi-y@ops.dti.ne.jp, debian-superh@lists.debian.org, linux-sh@vger.kernel.org Subject: Re: Moving forward with gdb sh native support? In-Reply-To: <20180322013659.GA8118@brightrain.aerifal.cx> References: <20180322013659.GA8118@brightrain.aerifal.cx> Message-ID: <3181a3f0c3af46ab45378feafbe627d7@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 22 Mar 2018 11:45:17 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00038.txt.bz2 On 2018-03-21 21:36, Rich Felker wrote: > I've recently gotten a chance to get back into gdb support for the sh > architecture, and have a series of related patches I'm going to be > submitting upstream soon. The ones that aren't specific to > SH2/J2/nommu stuff are adding support for software single-step (the > hardware single-step assumed in the current linux-sh-low does not seem > to be supported, as least not by Linux, on the vast majority of real > and emulated hardware) and some minor bugfix prerequisites for that. > Currently my changes here only cover gdbserver since there's no > upstream sh-native support in gdb. > > In conjunction with this I began looking again at the old sh native > patches, which Adrian Glaubitz has been maintaining for the Debian > side here: > > https://github.com/glaubitz/binutils-gdb/commits/linux-sh > > Having just looked at the gdbserver-side code for linux-sh, it looks > like there's a nontrivial amount of code duplication, and like there > will be even more if I copy my branch decoding (sh_get_next_pcs) code > for single-step over. > > Is this how it's supposed to be, or is there a recommended way to > refactor it to share code between gdb and gdbserver? If so, does it > make sense to go forward with the existing patches for sh native and > then tweak to share some things, or would it make more sense to redo > the native support along with a heavier refactoring? Hi Rich, Historically there has been a lot of duplication (and there still is) between GDB and GDBserver, but now we try to share as much as possible. This helps reducing the gap in behavior when debugging natively vs remotely, and helps for maintenance (fixing a bug in common code should fix it for both). the gdb/arch directory contains architecture-specific files meant to be shared. The code should be so that there is not "#ifdef GDBSERVER". Code that should be shared between GDB and GDBserver but is not arch-specific goes in gdb/common. IMO, it would make more sense to submit patches as you intend the code to be in the end, rather than submitting the non-shared version and fixing it after. Simon