• Moving forward with gdb sh native support?

    From Rich Felker@21:1/5 to All on Thu Mar 22 03:20:01 2018
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Rich Felker on Thu Mar 22 10:10:01 2018
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Marchi@21:1/5 to Rich Felker on Thu Mar 22 13:10:02 2018
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NIIBE Yutaka@21:1/5 to John Paul Adrian Glaubitz on Fri Mar 23 04:00:01 2018
    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.
    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)