From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quality Quorum To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdbserver: integrated vs. separated Date: Fri, 20 Jul 2001 16:54:00 -0000 Message-id: References: <20010720143133.A32237@nevyn.them.org> X-SW-Source: 2001-07/msg00305.html On Fri, 20 Jul 2001, Daniel Jacobowitz wrote: > 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 suppose it is a right thing to do. > > 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 > Thanks, Aleksey