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

[jlarmour@redhat.com (Jonathan Larmour)]

In article < 3ADCD1B8.772C5247@cygnus.com > you write:
>Surprising as  it may seem, there are circumstances when a remote
>target stub may need to know the values of symbols in the debuggee.
>The case that I'm working from is multi-threaded debugging under
>Solaris and Linux.  Both platforms make use of a debugging support
>library called libthread-db, which exports a debugging interface
>into the native thread library.  It shields the debugger from 
>knowledge about the thread library internals, but in return it 
>needs to know the addresses of thread library data objects in the
>child, so that it can go rooting around in them.

I had a very similar situation with the libremote work I was doing,
which involved grubbing around in the target. For libremote
to be able to ask for a symbol would have made life much easier
than what I ended up implementing. libremote can be put in a
difficult situation - it neither has the knowledge of the debugger
nor the knowledge of the target/executing program. It is mostly
just a conduit.

>The scheme that I propose is this: whenever the debugger detects
>a new shared library being loaded in the remote child process, 
>it will send a notification to the remote stub in the form of
>a 'Q' (miscelaneous set value) packet, like this:
>
>	QSharedObject:libc.so.1
>
>The target may as usual reply with an empty packet meaning
>"I don't understand", or with an "OK" acknowledgement, but
>in addition to those the target may reply with a request
>for the value of a symbol:
>
>	qSymbol:__pthread_max_threads

The situation I would have used it for had nothing to do with shared
libraries. I would much prefer it if the qSymbol could be received
at any point, and not just after a QSharedObject primitive.

Thanks,

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine