From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Philip Blundell Cc: gdb@sources.redhat.com Subject: Re: gdbserver in configure scripts Date: Wed, 08 Nov 2000 03:33:00 -0000 Message-id: <3A093870.3FEF9522@cygnus.com> References: X-SW-Source: 2000-11/msg00043.html 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 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 ", 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 . 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 means . 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