Moving forward with gdb sh native support?
Rich Felker <[email protected]>
| Newsgroups | gmane.comp.gdb.devel,gmane.linux.debian.ports.superh,gmane.linux.ports.sh.devel |
|---|---|
| Message-ID | <[email protected]> |
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