Moving forward with gdb sh native support?

Moving forward with gdb sh native support?

[Rich Felker]

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

Re: Moving forward with gdb sh native support?

[John Paul Adrian Glaubitz]

On 03/22/2018 10:36 AM, 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.

Cool \o/

> 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
> (...)
> 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.

FWIW, Yutaka Niibe has managed to determine the original author of the
SH patchset and it turns out this was not Takashi Yoshii who wrote the
patch but Toshinobu Sugioka. Yutaka has contacted him and asked him
to sign the copyright assignment for GDB. So, with me and Toshinobu
having signed the copyright assignment, it should now be possible to
get my out-of-tree patch merged upstream to GDB.

Can anyone from GDB upstream comment on this? Is there anything else
we need?

CC'ed Yutaka so he can comment if necessary. I would love to have
native SH support finally merged upstream. I'm happy to make any
changes necessary.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Moving forward with gdb sh native support?

[NIIBE Yutaka]

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> FWIW, Yutaka Niibe has managed to determine the original author of the
> SH patchset and it turns out this was not Takashi Yoshii who wrote the
> patch but Toshinobu Sugioka. Yutaka has contacted him and asked him
> to sign the copyright assignment for GDB. So, with me and Toshinobu
> having signed the copyright assignment, it should now be possible to
> get my out-of-tree patch merged upstream to GDB.

Mostly 20 years ago, if I remember correctly, it was me who implemented
the ptrace syscall in SuperH kernel, and put something to GDB for native
debugging.  It was under the GNU/Linux for SuperH Project.  Me, Kaz
Kojima, Toshinobu Sugioka, and Takashi Yoshii were all working together
at that time.

Before the ptrace system call, or any part of the kernel, as a start, I
wrote my own initial program loader for SuperH which has GDB serial
debug support.  Then, I ported the kernel to SH-3.  After my first
submission of the patch to lkml, I realized that Kaz, Toshinobu, and
Stuart Menefy were also having their own ports of SuperH.  I managed to
merge all efforts.

I and Kaz designed the shared object ABI for SuperH, and implemented in
glibc, gcc, binutils, and GDB.  For all of GNU toolchain changes and
glibc, I assigned my copyright to FSF.  So did Kaz Kojima.

After that, it was Toshinobu Sugioka who kept working the GDB patchset,
as well as other patches to distribute his own RPM based distribution.

Last year, I determined that the GDB patchset (of Adrian) was originally
came from Toshinobu Sugioka, via Takashi Yoshii.  So, I asked his
copyright assignment to FSF.  He did.  It was handled with the ticket of
[gnu.org #1227959].  I received the confrmation from FSF, in the
message of:

	Date: Wed, 26 Jul 2017 10:06:13 -0400
	Message-ID: <rt-4.2.13-5-gc649048-17168-1501077972-1368.1227959-6-0@rt.gnu.org>

... which was also sent to GDB maintainers.
-- 

Re: Moving forward with gdb sh native support?

[Simon Marchi]

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