This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libremote activation


Rudy Folden wrote:
> 
> Michael Snyder and I are working on what we believe to be the first
> native version of libremote for an embedded Linux system.
> 
> One thing that is not clear is just how libremote should be activated.
> 
> Right now everything is pretty much manual (GDB runs on a host machine
> and libremote runs on a target machine).
> 
> Currently, in a minicom window connected to the target's serial port, we
> activate the libremote server by hand.  The serial port acts as the
> target's console, so we sinply type a command, of the form:
> "/bin/server <port>  <program>",  which activates the server, which will
> listen to the port specified on the command line, and wait for
> communication from GDB.  And in a separate  window we fire up GDB and
> tell it to connect to the remote target using <port> .  When GDB exits,
> the libremote server also exits and a new one must be started before
> another session can take place, again, manually.  NOTE that <port> means
> <socket number>.
> 

I have added a "-d" option to gdbcodecon (the libremote server for CodeTAP)
and instead of exit it goes waiting for a new connection.


> I believe that the way this SHOULD work is to simply fire up GDB on the
> host and somehow the server on the target gets activated automatically.
> 
> This being the case, my question to this members of this newsgroup is
> "how?"
> 
> To get the discussion rolling:
> 
> One way that Unix/Linux handles servers of this class is via the inet
> daemon.  A well defined socket number is assigned to a specific server
> daemon, and when inet gets activity on the socket, it activates the
> server automatically, passing the socket number to the server for
> subsequent communication. I don't know if we can use this method since I
> am not sure how to get a "well known socket number" assigned to
> libremote/gdbserver, nor do I know if we could get one assigned if we
> wanted to.  These are defined in some RFC and are probably under some
> committee's control.
> 

Also, more than one user may want to use libremote things on the same machine.

If you could get a fix port number you could have a launcher of libremotes
which would start one and return the port you should use to you.

Or you can use the RPC port mapper.  But I believe Sun controls the numbers
there as well, and I don't know if it is portable.


> Another way we might do it is to start libremote up when the target's OS
> comes up.  One problem with this approach is that these little systems
> are short on resources and running libremote automatically is wasteful.
> For instance the system I am currently working on has 8Meg for Linux,
> its applications, AND ITS RAM DISK.  There is no disk, so everything
> must be stored in rom or ram.   Another problem is that libremote
> CURRENTLY is serial: it starts up with the program and port number
> defined on the command line and exits when GDB exits.  To just hang
> around looking for work to do, it would need modification so that it is
> resets itself.   Also, only one copy of the server could be run at one
> time using this technique (unless multi-threading or some such technique
> is added).  This is not too important in the embedded world, but applies
> to libremote, in general.
> 

This would work for a single user.


> Well, these are a couple of ideas.
> 
> I believe that some policy should be defined for the activation of
> libremote,
> 

Well, IMHO libremote should be started in its own little xterm.  The
inferior program output (and perhaps input) should occur in there.
Depending on the target, some off-band commands could be issued from that
terminal as well.  Log messages can go there as well.

With the "-d" command line switch (so it does not have to be restarted)
I don't see much problem with the current setup.  I have been using it like
this for several months and it never bothered me (and I am lazy ;-).

P.S.: I also have to start the server that actually talks to the board.
It is a CORBA server supplied by the target manufacturer.  I started these
things last week and I have been using them for days for testing and fixing
things in gdb/gdbtk without ever having to bother with restarting them.




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]