[RFA]: Remote protocol symbol lookup service.

[RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Andrew, 

I've changed the initial message from "Q" to "q" as you suggested, and
I've hexified the filenames and symbol names, so that they are not 
vulnerable to embedded special characters.  If you have a name for the
initial message that you would prefer over "qSharedObject", I'm open
to suggestions.

Michael

Re: [RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Michael Snyder wrote:
> 
> Andrew,
> 
> I've changed the initial message from "Q" to "q" as you suggested, and
> I've hexified the filenames and symbol names, so that they are not
> vulnerable to embedded special characters.  If you have a name for the
> initial message that you would prefer over "qSharedObject", I'm open
> to suggestions.

And I seem to have sent it without the attachment.  Try again...
2001-05-02  Michael Snyder  <msnyder@redhat.com>

	* remote.c (remote_open_1): Call no_shared_libraries, so that
	symbols for shared libraries can be reloaded per session.
	(remote_async_open_1): Ditto.
	(remote_new_objfile): New function.  Send notification to target
	for each new object file (shared library), and answer any requests
	from the target for symbol lookup.

*** save/remote.hex2bin.c	Wed May  2 14:48:17 2001
--- ./remote.c	Wed May  2 14:54:45 2001
*************** serial device is attached to the remote 
*** 2130,2135 ****
--- 2130,2140 ----
       someday have a notion of debugging several processes.  */
  
    inferior_pid = MAGIC_NULL_PID;
+ 
+ #ifdef SOLIB_CREATE_INFERIOR_HOOK
+   /* First delete any symbols previously loaded from shared libraries. */
+   no_shared_libraries (NULL, 0);
+ #endif
    /* Start the remote connection; if error (0), discard this target.
       In particular, if the user quits, be sure to discard it
       (we'd be in an inconsistent state otherwise).  */
*************** serial device is attached to the remote 
*** 2148,2159 ****
        putpkt ("!");
        getpkt (buf, PBUFSIZ, 0);
      }
    /* FIXME: need a master target_open vector from which all 
       remote_opens can be called, so that stuff like this can 
       go there.  Failing that, the following code must be copied
       to the open function for any remote target that wants to 
       support svr4 shared libraries.  */
! #ifdef SOLIB_CREATE_INFERIOR_HOOK
    if (exec_bfd) 	/* No use without an exec file. */
      SOLIB_CREATE_INFERIOR_HOOK (inferior_pid);
  #endif
--- 2153,2166 ----
        putpkt ("!");
        getpkt (buf, PBUFSIZ, 0);
      }
+ #ifdef SOLIB_CREATE_INFERIOR_HOOK
    /* FIXME: need a master target_open vector from which all 
       remote_opens can be called, so that stuff like this can 
       go there.  Failing that, the following code must be copied
       to the open function for any remote target that wants to 
       support svr4 shared libraries.  */
! 
!   /* Set up to detect and load shared libraries. */
    if (exec_bfd) 	/* No use without an exec file. */
      SOLIB_CREATE_INFERIOR_HOOK (inferior_pid);
  #endif
*************** serial device is attached to the remote 
*** 2230,2235 ****
--- 2237,2246 ----
       implemented. */
    wait_forever_enabled_p = 0;
  
+ #ifdef SOLIB_CREATE_INFERIOR_HOOK
+   /* First delete any symbols previously loaded from shared libraries. */
+   no_shared_libraries (NULL, 0);
+ #endif
    /* Start the remote connection; if error (0), discard this target.
       In particular, if the user quits, be sure to discard it
       (we'd be in an inconsistent state otherwise).  */
*************** serial device is attached to the remote 
*** 2251,2262 ****
        putpkt ("!");
        getpkt (buf, PBUFSIZ, 0);
      }
    /* FIXME: need a master target_open vector from which all 
       remote_opens can be called, so that stuff like this can 
       go there.  Failing that, the following code must be copied
       to the open function for any remote target that wants to 
       support svr4 shared libraries.  */
! #ifdef SOLIB_CREATE_INFERIOR_HOOK
    if (exec_bfd) 	/* No use without an exec file. */
      SOLIB_CREATE_INFERIOR_HOOK (inferior_pid);
  #endif
--- 2262,2275 ----
        putpkt ("!");
        getpkt (buf, PBUFSIZ, 0);
      }
+ #ifdef SOLIB_CREATE_INFERIOR_HOOK
    /* FIXME: need a master target_open vector from which all 
       remote_opens can be called, so that stuff like this can 
       go there.  Failing that, the following code must be copied
       to the open function for any remote target that wants to 
       support svr4 shared libraries.  */
! 
!   /* Set up to detect and load shared libraries. */
    if (exec_bfd) 	/* No use without an exec file. */
      SOLIB_CREATE_INFERIOR_HOOK (inferior_pid);
  #endif
*************** build_remote_gdbarch_data (void)
*** 5705,5710 ****
--- 5718,5778 ----
    remote_address_size = TARGET_ADDR_BIT;
  }
  
+ /* Saved pointer to previous owner of the new_objfile event. */
+ static void (*remote_new_objfile_chain) (struct objfile *);
+ 
+ /* Function to be called whenever a new objfile (shlib) is detected. */
+ static void
+ remote_new_objfile (struct objfile *objfile)
+ {
+   char *msg, *reply, *prev, *tmp;
+   struct minimal_symbol *sym;
+ 
+   if (remote_desc != 0)		/* Have a remote connection */
+     {
+       msg   = alloca (PBUFSIZ);
+       reply = alloca (PBUFSIZ);
+ 
+       /* Inform target of new objfile. */
+ 
+       /* NOTE: you might say that I should use SLASH_CHAR here, but
+ 	 not so!  SLASH_CHAR is defined for the host, while the shared
+ 	 libraries are relevant to the target. */
+       if (objfile)
+ 	{
+ 	  tmp = strrchr (objfile->name, '/');
+ 	  if (tmp == NULL)
+ 	    tmp = strrchr (objfile->name, '\\');
+ 	  if (tmp == NULL)
+ 	    tmp = objfile->name;
+ 	  bin2hex (tmp + 1, reply, 0);
+ 	  sprintf (msg, "qSharedObject:%s", reply);
+ 	}
+       else
+ 	strcpy (msg, "qSharedObject:");
+ 
+       putpkt (msg);
+       getpkt (reply, PBUFSIZ, 0);
+       while (strncmp (reply, "qSymbol:", 8) == 0)
+ 	{
+ 	  msg[hex2bin (&reply[8], msg, 0)] = '\0';
+ 	  sym = lookup_minimal_symbol (msg, NULL, NULL);
+ 	  if (sym == NULL)
+ 	    sprintf (msg, "QSymbol::%s", &reply[8]);
+ 	  else
+ 	    sprintf (msg, "QSymbol:%s:%s", 
+ 		     paddr_nz (SYMBOL_VALUE_ADDRESS (sym)),
+ 		     &reply[8]);
+ 	  putpkt (msg);
+ 	  getpkt (reply, PBUFSIZ, 0);
+ 	}
+     }
+   /* Call predecessor on chain, if any. */
+   if (remote_new_objfile_chain != 0 &&
+       remote_desc == 0)
+     remote_new_objfile_chain (objfile);
+ }
+ 
  void
  _initialize_remote (void)
  {
*************** _initialize_remote (void)
*** 5734,5739 ****
--- 5802,5811 ----
  
    init_remote_cisco_ops ();
    add_target (&remote_cisco_ops);
+ 
+   /* Hook into new objfile notification.  */
+   remote_new_objfile_chain = target_new_objfile_hook;
+   target_new_objfile_hook  = remote_new_objfile;
  
  #if 0
    init_remote_threadtests ();
From msnyder@cygnus.com Wed May 02 17:21:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: kettenis@wins.uva.nl
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Add explicit makefile rules
Date: Wed, 02 May 2001 17:21:00 -0000
Message-id: <3AF0A472.27E75572@cygnus.com>
References: <3AEF193F.2308A026@cygnus.com>
X-SW-Source: 2001-05/msg00020.html
Content-length: 1265

This has not been my week for submitting patches cleanly.  Try again:
2001-05-01  Michael Snyder  <msnyder@redhat.com>

	* Makefile.in: Add rules for thread-db.o, lin-lwp.o, proc-service.o.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.80
retrieving revision 1.81
diff -c -3 -p -r1.80 -r1.81
*** Makefile.in	2001/04/27 00:19:08	1.80
--- Makefile.in	2001/05/01 20:15:43	1.81
*************** sol-thread.o: sol-thread.c $(defs_h) gdb
*** 1759,1764 ****
--- 1759,1774 ----
  linux-thread.o: linux-thread.c $(breakpoint_h) $(gdbcmd_h) gdb_wait.h \
  	gdbthread.h $(gdbcore_h) $(inferior_h) target.h $(defs_h)
  
+ thread-db.o: thread-db.c $(defs_h) gdb_assert.h gdb_proc_service.h \
+ 	gdb_thread_db.h $(bfd_h) gdbthread.h $(inferior_h) $(symfile_h) \
+ 	objfiles.h $(target_h) $(regcache_h)
+ 
+ lin-lwp.o: lin-lwp.c $(defs_h) gdb_assert.h gdb_wait.h gdbthread.h \
+ 	$(inferior_h) $(target_h) $(gdbcmd_h) $(regcache_h)
+ 
+ proc-service.o: proc-service.c $(defs_h) $(inferior_h) gdb_proc_service.h \
+ 	$(symtab_h) $(target_h) gregset.h
+ 
  gnu-regex.o: gnu-regex.c gnu-regex.h $(defs_h) gdb_string.h
  
  remote-adapt.o: remote-adapt.c $(defs_h) $(gdbcore_h) \
From ezannoni@cygnus.com Wed May 02 17:24:00 2001
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] More file-name related fixes
Date: Wed, 02 May 2001 17:24:00 -0000
Message-id: <15088.42284.377283.79524@kwikemart.cygnus.com>
References: <3791-Wed02May2001202656+0300-eliz@is.elta.co.il> <1010502202816.ZM3883@ocotillo.lan>
X-SW-Source: 2001-05/msg00021.html
Content-length: 555

Kevin Buettner writes:
 > On May 2,  8:26pm, Eli Zaretskii wrote:
 > 
 > > +#if 0
 > > +
 > >  static struct sym_and_file {
 > >    char *sym;
 > >    char *file;
 > > @@ -3352,6 +3340,8 @@ make_file_symbol_completion_list (char *
 > >    return (return_val);
 > >  }
 > >  
 > > +#endif
 > > +
 > 
 > Is there any reason for leaving the code disabled by the #if 0
 > in place?
 > 
 > Kevin
 > 

I think that Eli made a patch against some private version of symtab.c
in his own tree. (specifically symtab.c~). That code is not in symtab.c
at all.

Elena

Re: [RFA]: Remote protocol symbol lookup service.

[Jonathan Larmour]

In article < 3AF090AE.4D31F3A@cygnus.com > you write:
>-=-=-=-=-=-
>
>Michael Snyder wrote:
>> 
>> Andrew,
>> 
>> I've changed the initial message from "Q" to "q" as you suggested, and
>> I've hexified the filenames and symbol names, so that they are not
>> vulnerable to embedded special characters.  If you have a name for the
>> initial message that you would prefer over "qSharedObject", I'm open
>> to suggestions.

I still think a target should be able to request this at any point
in the remote protocol, and not just when told of a shared object.

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

Re: [RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Jonathan Larmour wrote:
> 
> In article < 3AF090AE.4D31F3A@cygnus.com > you write:
> >-=-=-=-=-=-
> >
> >Michael Snyder wrote:
> >>
> >> Andrew,
> >>
> >> I've changed the initial message from "Q" to "q" as you suggested, and
> >> I've hexified the filenames and symbol names, so that they are not
> >> vulnerable to embedded special characters.  If you have a name for the
> >> initial message that you would prefer over "qSharedObject", I'm open
> >> to suggestions.
> 
> I still think a target should be able to request this at any point
> in the remote protocol, and not just when told of a shared object.

Yeah?  Would you be willing to implement that?  ;-)

Re: [RFA]: Remote protocol symbol lookup service.

[Jonathan Larmour]

Michael Snyder wrote:
> 
> Jonathan Larmour wrote:
> >
> > In article < 3AF090AE.4D31F3A@cygnus.com > you write:
> > >-=-=-=-=-=-
> > >
> > >Michael Snyder wrote:
> > >>
> > >> Andrew,
> > >>
> > >> I've changed the initial message from "Q" to "q" as you suggested, and
> > >> I've hexified the filenames and symbol names, so that they are not
> > >> vulnerable to embedded special characters.  If you have a name for the
> > >> initial message that you would prefer over "qSharedObject", I'm open
> > >> to suggestions.
> >
> > I still think a target should be able to request this at any point
> > in the remote protocol, and not just when told of a shared object.
> 
> Yeah?  Would you be willing to implement that?  ;-)

Isn't it just a case of pretty much cut-and-pasting the bit that acts on a
symbol request from the target into remote_wait()?

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

Re: [RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Jonathan Larmour wrote:
> 
> Michael Snyder wrote:
> >
> > Jonathan Larmour wrote:
> > >
> > > In article < 3AF090AE.4D31F3A@cygnus.com > you write:
> > > >-=-=-=-=-=-
> > > >
> > > >Michael Snyder wrote:
> > > >>
> > > >> Andrew,
> > > >>
> > > >> I've changed the initial message from "Q" to "q" as you suggested, and
> > > >> I've hexified the filenames and symbol names, so that they are not
> > > >> vulnerable to embedded special characters.  If you have a name for the
> > > >> initial message that you would prefer over "qSharedObject", I'm open
> > > >> to suggestions.
> > >
> > > I still think a target should be able to request this at any point
> > > in the remote protocol, and not just when told of a shared object.
> >
> > Yeah?  Would you be willing to implement that?  ;-)
> 
> Isn't it just a case of pretty much cut-and-pasting the bit that acts on a
> symbol request from the target into remote_wait()?

Hmmm...  I suppose so, under the right set of assumptions.
Such as that the target is not really stopped, and we do not
need to restart it (as with the 'O' packet).

Andrew?  J.T.?  Anybody else have an opinion about letting GDB
respond to new requests while in remote_wait?  Basically it's a
switch statement, so it doesn't really have much impact on 
performance or anything...  and of course I could abstract the
code that responds to the symbol requests into a function.

Or, we could just wait and do this if there's ever a need to.
For my application (the thread_db interface), this would not
be useful.

Re: [RFA]: Remote protocol symbol lookup service.

[Jonathan Larmour]

Michael Snyder wrote:
> 
> Hmmm...  I suppose so, under the right set of assumptions.
> Such as that the target is not really stopped, and we do not
> need to restart it (as with the 'O' packet).

I don't see any special treatment with the 'O' packet. If the target is
stopped, how could it have made a request?

If you do take this route, don't forget remote_async_wait().

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

Re: [RFA]: Remote protocol symbol lookup service.

[Andrew Cagney]

> Michael Snyder wrote:
> 
>> 
>> Andrew,
>> 
>> I've changed the initial message from "Q" to "q" as you suggested, and
>> I've hexified the filenames and symbol names, so that they are not
>> vulnerable to embedded special characters.  If you have a name for the
>> initial message that you would prefer over "qSharedObject", I'm open
>> to suggestions.

The best I can think of is ``qSymbol:'' - an initial empty symbol to get 
things started.

As with the other packets, it will need the ``set remote XXXX-packet 
enable/disable'' command and logic to detect when it was simply ignored. 
  If it was ignored ("" vs "OK"), it shouldn't be retried.

Could I also suggest moving the code doing the work in:

> + /* Function to be called whenever a new objfile (shlib) is detected. */
> + static void
> + remote_new_objfile (struct objfile *objfile)

to a separate function and adding a call to it from remote_open_*().  As 
far as I know, that will cover all cases

Don't forget the doco.

	Andrew

Re: [RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Michael Snyder wrote:
> >
> >>
> >> Andrew,
> >>
> >> I've changed the initial message from "Q" to "q" as you suggested, and
> >> I've hexified the filenames and symbol names, so that they are not
> >> vulnerable to embedded special characters.  If you have a name for the
> >> initial message that you would prefer over "qSharedObject", I'm open
> >> to suggestions.
> 
> The best I can think of is ``qSymbol:'' - an initial empty symbol to get
> things started.

Ok.
 
> As with the other packets, it will need the ``set remote XXXX-packet
> enable/disable'' command and logic to detect when it was simply ignored.
>   If it was ignored ("" vs "OK"), it shouldn't be retried.

Ok.
 
> Could I also suggest moving the code doing the work in:
> 
> > + /* Function to be called whenever a new objfile (shlib) is detected. */
> > + static void
> > + remote_new_objfile (struct objfile *objfile)
> 
> to a separate function and adding a call to it from remote_open_*().  As
> far as I know, that will cover all cases

Ok.

> Don't forget the doco.

Ok.

Re: [RFA]: Remote protocol symbol lookup service.

[Andrew Cagney]

> Could I also suggest moving the code doing the work in:
>> 
> 
>> > + /* Function to be called whenever a new objfile (shlib) is detected. */
>> > + static void
>> > + remote_new_objfile (struct objfile *objfile)
> 
>> 
>> to a separate function and adding a call to it from remote_open_*().  As
>> far as I know, that will cover all cases
> 
> 
> Ok.
> 

But did it work? :-) Try creating a static threaded program and see what 
happens.

	Andrew

Re: [RFA]: Remote protocol symbol lookup service.

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Could I also suggest moving the code doing the work in:
> >>
> >
> >> > + /* Function to be called whenever a new objfile (shlib) is detected. */
> >> > + static void
> >> > + remote_new_objfile (struct objfile *objfile)
> >
> >>
> >> to a separate function and adding a call to it from remote_open_*().  As
> >> far as I know, that will cover all cases
> >
> >
> > Ok.
> >
> 
> But did it work? :-) Try creating a static threaded program and see what
> happens.

No, it will not work in that context.  The thread-db library will not 
be called soon enough.  Although hmm... perhaps there's something I could
look at in that regard on the target side...

Re: [RFA]: Remote protocol symbol lookup service.

[Andrew Cagney]

> Hmmm...  I suppose so, under the right set of assumptions.
> Such as that the target is not really stopped, and we do not
> need to restart it (as with the 'O' packet).
> 
> Andrew?  J.T.?  Anybody else have an opinion about letting GDB
> respond to new requests while in remote_wait?  Basically it's a
> switch statement, so it doesn't really have much impact on 
> performance or anything...  and of course I could abstract the
> code that responds to the symbol requests into a function.
> 
> Or, we could just wait and do this if there's ever a need to.
> For my application (the thread_db interface), this would not
> be useful.


See previous discussion about getting input working across the protocol. 
  The suggestion was:

	o	target stop with bogus signal 0

	o	gdb chat to target: qSymbol? qInput?

	o	gdb resume target

part of the chat could include a check qSymbol check.  A variation might 
have the target return a symbol request instead of a stop status.

	Andrew