From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: parcelling up struct gdbarch Date: Mon, 16 Jul 2001 15:30:00 -0000 Message-id: <3B536B0C.3060908@cygnus.com> References: <20010713001635.A19524@nevyn.them.org> <3B4F4D7F.6010201@cygnus.com> <20010713145356.A4898@nevyn.them.org> <3B506250.5080502@cygnus.com> <20010716112536.A19620@nevyn.them.org> <3B533AAD.1060300@cygnus.com> <5mae24vfc1.fsf@jtc.redback.com> X-SW-Source: 2001-07/msg00189.html > > Andrew> If GDBserver is going to be come more tightly integrated into GDB then > Andrew> it is going to need to pick up some baggage like ui-file. > > Can you explain your vision (or provide pointers to previous articles) > of a tightly integrated gdbserver? My, er ``vision'' is more focused on the target stack. By tightly integrated I really mean, have gdbserver steal some of what GDB currently does. For instance, imagine (this will take some imagination) a GDB with a cleanly implemented single step. WFI would tell the target to single step (WFI has been fixed to not know about h/w or s/w single step) the target, since it didn't know how to single step, would use software single step and tell the next target down to run. the remote.c target would get this and send it to the server. gdbserver would run/stop the target If GDB and gdbserver share a common framework then it should be possible to push layers (such as single step) down into the remote server. > I expect and accept some baggage, > but at the moment I cannot comprehend why it would need high level > constructs like ui-file. If gdbserver is going to use more chunks of GDB then it and gdb will would probably want to start sharing certain bits of infrastructure - the event loop, the error output, serial.* How much can/should be shared, I don't know. From what Daniel has said, I gather that his immediate focus is on getting a very thin gdbserver working. Andrew