This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: parcelling up struct gdbarch


> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]