Re: [RFC] Extend remote protocol to allow symbol look-up service.

[Andrew Cagney <ac131313@cygnus.com>]

[this really belongs on gdb@]

> > Could a target encounter a situtation where it needed symbol values
> > before it could report back a program status?  The problem is very much
> > like the input/output cases where the target is wanting to nest a query
> > request within the normal packet flow.  Should input/output and this
> > query all use the same mechanism?
> 
> I can't see it.  The target may need the symbols earlier, but until the
> shared library is loaded, they aren't available.  Should the target just
> keep polling gdb for the symbols?  That would be terribly inefficient.
> This way, the target won't ask for them until there's at least some
> reason to believe that they might have become available.

Ah, yes, ok.  It's a trade off between:

	a)	GDB learning new symbol info
		and prompting the target.

	b)	The target finding it would
		like a symbol and prompting
		GDB.

For case a) could there be a situtation where, when GDB discovers more
symbols and informs the target but the target doesn't yet know all the
symbols that it will need?  Given you've got your thread-db code working
I'd guess that you've solved this problem for your case.

--

SinceGDB is prompting the target is because it has discovered new symbol
info rather than it has loaded a shared library, should the initiation
be a message saying ``psst target, wana buy some new symbol info?''
rather than ``so, nudge nudge, wink wink, its a shared library, ...''. 
That way the exact purpose of the query is clear.  It should also mean
that the cases:

	o	static program with all
		symbols available

	o	symbols loaded via symbol
		file or such command.

can eventually be fixed without a further protocol change.  In each
case, since new symbol info has become available, the target should be
notified.

	Andrew