This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: libremote activation
- To: Rudy Folden <rfolden at redhat dot com>
- Subject: Re: libremote activation
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Thu, 09 Nov 2000 21:42:08 +0000
- CC: gdb at sourceware dot cygnus dot com
- Organization: Red Hat Canada Ltd. - Toronto
- References: <3A0B0F63.254C569A@redhat.com>
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