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

[Michael Snyder <msnyder@cygnus.com>]

Andrew Cagney wrote:
> 
> Just FYI,
> 
> Some quick comments on the protocol as it currently stands.  I'd suggest
> waiting until the actual protocol spec has been resolved first though.
> 
>         Andrew
> 
> --
> 
> >         QSharedObject:libc.so.1
> 
> Given that the replies are:
> 
>         ""
>         OK
>         Some value
> 
> I would strongly prefer the ``q'' packet over the ``Q'' packet (I think
> the latter is redundant :-).  The ``q'' packet implicitly allows a value
> to be returned - which in turn gives the RPC mechanims that you're
> implementing.

You keep calling it 'rpc'.  I don't see how it is rpc.  It's just a query.
But I don't mind changing it from 'Q' to 'q', even though it doesn't make
sense to me.  The shared library message is more of a notification than
a query, I think.

> The symbol and file value is being passed as ascii text.  I think they
> should be hex encoded so that we're 100% certain that they will never
> contain unprintable or protocol data.  This was the rationale behind the
> qRcmd packet carrying HEX data.

Does anyone else have an opinion?  I don't like unreadable messages.

> Is the protocol stateless?  That is, would repeating the query:
> 
>         qSymbol::__pthread_max_threads
> 
> always return the same value?

It's not stateless; both the target and the debugger have state.
On the debugger, the 'state' is whether the symbol is available or not.
On the target, the state is whether this symbol's value has been obtained.
Also whether it has been requested since the last shared library event.
The target should ask for a given symbol only once per shared library
event.  There won't be any harm in asking for the same symbol twice --
except for the possibility of getting into an infinite loop.