* Re: gdbserver in configure scripts
2000-09-09 13:40 gdbserver in configure scripts Philip Blundell
@ 2000-11-08 3:33 ` Andrew Cagney
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2000-11-08 3:33 UTC (permalink / raw)
To: Philip Blundell; +Cc: gdb
Philip Blundell wrote:
>
> It doesn't currently work to build a cross GDB targeting, say, m68k-linux (or
> any other gdbserver-enabled platform). The configure script fails with:
>
> linking /usr/src/sourceware/src/gdb/gdbserver/../config/nm-empty.h to nm.h
> configure: error: /usr/src/sourceware/src/gdb/gdbserver/../config/nm-empty.h: File not found
> configure: error: /usr/src/sourceware/src/gdb/gdbserver/configure failed for gdbserver
FYI,
I've checked in a patch to this specific problem (it shouldn't create
the link). tm-linix.h still doesn't build though.
Andrew
> This would be prevented by the following commented-out code in configure.in:
>
> # else
> # GDBserver is only useful in a "native" enviroment
> # configdirs=`echo $configdirs | sed 's/gdbserver//'`
>
> Does anybody know of a reason why this code should not be enabled?
>
> (I'm not sure what the story is with nm-empty.h. I don't have one in my tree;
> the ChangeLog suggests that it used to exist, but I didn't see anything
> referring to its removal.)
>
> Thanks
>
> p.
From rfolden@redhat.com Thu Nov 09 13:01:00 2000
From: Rudy Folden <rfolden@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: libremote activation
Date: Thu, 09 Nov 2000 13:01:00 -0000
Message-id: <3A0B0F63.254C569A@redhat.com>
X-SW-Source: 2000-11/msg00044.html
Content-length: 2882
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 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.
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.
Well, these are a couple of ideas.
I believe that some policy should be defined for the activation of
libremote,
Discussions?
-Rudy Folden
^ permalink raw reply [flat|nested] 2+ messages in thread