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

[Michael Snyder <msnyder at cygnus dot com>]

Andrew Cagney wrote:
> 
> Michael Snyder wrote:
> [....]
> 
> The protocol appears to overlaps two separate but related operations -
> shared library load and symbol load. If I remember right, a symbol can
> also be loaded using things like ``(gdb) symbol file''.  Is the shared
> library notification even needed and should this be tied to the shared
> library hook?

The shared library notification from gdb to the target simply lets
the target know that new symbols may be available.  The target could
of course use the notification for other purposes (but I don't know
of any).  I could see extending the notification to cover the "symbol-file"
command as well, but since I don't need that, I might leave it for 
someone else to do.

> What happens if the target program has no shared libraries?  Will the
> target still get an oportunity to request a symbol?

No -- I'm aware of that short-coming, but haven't thought of a solution yet.
Perhaps I could send down a symbol file notification from remote_open?


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