From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Who owns gdbserver? Date: Fri, 22 Jun 2001 09:04:00 -0000 Message-id: <20010622090351.A14790@nevyn.them.org> References: <01062113504401.01520@CyberMax> <3B336763.2090807@cygnus.com> X-SW-Source: 2001-06/msg00183.html On Fri, Jun 22, 2001 at 11:42:27AM -0400, Andrew Cagney wrote: > The main reason that GDBSERVER is breaking is that gdb targets are being > converted to multi-arched (read cleaned up). The multi-arch mechanism > isn't compatible with the way GDBSERVER has been abusing (?) GDB's > interfaces to get to the things it wants. > > I don't don't want this multi-arch cleanup to stagnate because people > feel that GDBSERVER should continue to build. Instead, I think the > people using GDBSEVER should be looking at that code and figuring out > the exact interfaces that are needed and get them properly defined. Definitely. My current inclination is that, after we enumerate precisely what interfaces are needed, we may need to break some of the nat and tdep files up into smaller pieces, so that gdbserver can link in the parts it really needs - and the parts it can reasonably include the support code for. [To be honest, my gut instinct is to also start moving platform-specific code to config directories at the same time. I don't know if that would meet with general approval, though] > As a second problem. In many cases, I don't think building GDBSERVER > actually makes sense. Consider a typical case - user doing a > cygwin-X-embedded-linux gdbserver (host=cygwin, target=linux, > build=cygwin?). GDBSERVER needs to be compiled with a cygwin-X-linux > compiler and the configury for that isn't trival - it means that you're > trying to canadian cross compile GDBSERVER (and GDB). Well, actually, we had to address this at MontaVista. We were fortunate in that we had a relatively easy way out - we build a cross gdb, and a target gdb for those who prefer native debugging (or want threads, which gdbserver does not yet handle... etc.) The target gdb is cross compiled, and gdbserver is built then. Building it along with the cross gdb would not be hard, though - we'd just need to standardize on an "appropriate" variable for the target compiler if it was available - something like $CC_FOR_TARGET, but since the eventual target platform is not really our "target" at this stage of the build that might not be the best choice. > Both these problems leave GDBSERVER at a cross road. It can either > become more tightly integrated into GDB (kind of my preference) or start > to distance its self (becoming a separate independant program like the > stubs). More tightly integrated is definitely also my preference, if you couldn't tell from above. I'm willing to work to make that happen. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer