From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: gdbserver: integrated vs. separated Date: Fri, 20 Jul 2001 14:31:00 -0000 Message-id: <20010720143133.A32237@nevyn.them.org> X-SW-Source: 2001-07/msg00301.html Before I invest any more time in patching gdbserver, I think I need to know which way to take it: towards GDB or away from. Andrew Cagney wrote, in a message not long ago: > I think, in terms of better splitting up gdbserver and gdb it is pretty > much a requirement. I can but dream of the day when GDBSERVER stops > including defs.h :-) Well, I can't dream of it - I can see it. KERNEL_U_ADDR, a few *_REGNUM variables, REGISTER_BYTES/REGISTER_RAW_SIZE/REGISTER_BYTE, and some prototypes are all it's currently getting from defs.h. I've removed the include entirely in my local sources. It'll take some weeding to make all the gdbserver ports (or at least most of them) compile in this situation, but it can be done. Right now I still get CORE_ADDR by including "bfd.h", but I can probably make that go away too. The question is, should I do all this, or should we go the other way? I think splitting is the only reasonable answer, and I think that it will simplify gdbserver substantially in addition to forcing me to improve documentation of the remote protocol. If the world agrees with me, I'll do the cleanup necessary and work out a postable solution. My extreme temptation is to move gdbserver to a separate top-level directory; then we can enforce independence from gdb's private headers, and perhaps put things like the target_signal enum and definitions of remote protocol register packets in include/ (or include/gdb/?). I'm probably going to break a couple of gdbserver targets in the process, for lack of testing ability; I can't find a lot of these systems to test on. I have my doubts about when they last built, though, so it doesn't make me weep. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer