From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112809 invoked by alias); 22 Mar 2018 01:37:05 -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 112311 invoked by uid 89); 22 Mar 2018 01:37:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=H*Ad:D*ne.jp, sh2, H*Ad:D*jp X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 01:37:02 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1eypA3-000294-00; Thu, 22 Mar 2018 01:36:59 +0000 Date: Thu, 22 Mar 2018 01:37:00 -0000 From: Rich Felker To: gdb@sourceware.org Cc: 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: Moving forward with gdb sh native support? Message-ID: <20180322013659.GA8118@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00036.txt.bz2 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? I know lack of sh native support has been a longstanding issue and Adrian has been doing a likely-painful job of keeping the patches up-to-date for a long time now, so whatever we do I hope we can work out a solution that gets it upstream soon. Rich