From: Simon Marchi <simon.marchi@polymtl.ca>
To: Rich Felker <dalias@libc.org>
Cc: gdb@sourceware.org,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Hector Oron <zumbi@debian.org>,
Nobuhiro Iwamatsu <iwamatsu@debian.org>,
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?
Date: Thu, 22 Mar 2018 11:45:00 -0000 [thread overview]
Message-ID: <3181a3f0c3af46ab45378feafbe627d7@polymtl.ca> (raw)
In-Reply-To: <20180322013659.GA8118@brightrain.aerifal.cx>
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
prev parent reply other threads:[~2018-03-22 11:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 1:37 Rich Felker
2018-03-22 9:02 ` John Paul Adrian Glaubitz
2018-03-23 2:09 ` NIIBE Yutaka
2018-03-22 11:45 ` Simon Marchi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3181a3f0c3af46ab45378feafbe627d7@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=dalias@libc.org \
--cc=debian-superh@lists.debian.org \
--cc=gdb@sourceware.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=iwamatsu@debian.org \
--cc=linux-sh@vger.kernel.org \
--cc=takasi-y@ops.dti.ne.jp \
--cc=zumbi@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox