Re: shared library support hookin the remote.c

[Kevin Buettner <kevinb at redhat dot com>]

On Mon, 28 Jun 2004 14:41:24 -0700
"Stephen P. Smith" <ischis2@cox.net> wrote:

> Kevin Buettner wrote:
> 
> >I think we need more detail.  Which functions in remote.c would
> >be affected?   What would the interface look like and how would
> >it be used?
>
> It would affetc remote_async_wait() and remote_wait().  From the last 
> time, I know that we don't want to
> add extraneous functionality to the remote protocol unless the target 
> requires it.  This method would abstact
> that out. 

How does the remote target communicate the necessary details to GDB
then?

It sounds to me as though you want to add the hook so that you can add
a private protocol extension.

IMO, it's better to hash out the details of a public remote protocol
extension for shared library support.

> What I haven't figured out is the preferred means of intializing such a 
> variable across the two subsystems.
> 
> There would be a statement something like this:
>    if ( remote_protocol_solib_hook_funcion )
>        (*remote_protocol_solib_hook_funcion) ();
> 
> Does something like this seem reasonable?
> 
> >Also, please note that I am not the maintainer of remote.c...
>
> True  - but the use of this pointer would be in the solib area.  Since 
> the target is always queried, this is the way the solib
> subsystem would know when it is safe to ask about shared library values 
> that it needs from a particular target.

This may indeed be a reasonable way to approach things, but I'd like
to first understand how communication of shared library information
between GDB and the stub is accomplished and what the protocol looks
like.

Kevin