I'm using KGDBoE to for debugging Linux kernel.
KGDBoE start a server at a certain udp port, I can easily connect to the server running on the embedded target using gdb via command line.
Now I want to use Eclipse IDE to make gdb debugging more interactive.
Problem is that I can't find option to use UDP port for gdb connection in Eclipse Attach Application Debug launch.
Anyone has idea how to accomplish that.
Making things simpler, I want to use UDP connection rather than TCP to connect to the GDBserver running on my embedded board. Its's very straightforward using GDB CLI but I want to use Eclipse for that.
Thanks
Related
I'm debugging an embedded application that runs in a Linux environment on a remote target. The only usable interface to the board is a single serial interface. Right now that's hooked up /bin/sh on init. I'm connecting with minicom, (re-)loading my application with lrzsz, and using printfs to get the job done.
I'd like to use gdbserver for more fine-grained debugging, but connectivity seems like a problem. Normally I'd connect over ethernet, but that's not available on this hardware. I understand gdbserver can run on a serial line, but right now my one comm port belongs to the shell.
Is there a good way to work around this restriction? Ideally I'd like to be able to run gdbserver and get back to a shell when I'm finished. I've tried starting gdbserver from the shell using the one available serial interface (/dev/ttyS0), then quitting minicom and starting GDB on my host, but it's messy & doesn't appear to work (even after setting remotebaud appropriately). Should that work? What's the sane thing to do in this situation?
How about the old-school solution? Use PPP to run IP networking over your serial line. You can then ssh (or even telnet) to your board, and connect to gdb at the same time. Given your circumstance, I'd recommend starting pppd manually to reduce the risk of locking yourself out through misconfiguration. The LDP link dates from 2000, but contains a lot of debugging advice.
I have come across a couple of proprietary applications on Linux platform which are administered via telnet. Remote telnet is not enabled but on the host you do a telnet session. You get an interface where you enter commands to make the application work. I was wondering how a telnet interface is built for any particular application. Not looking for a step-by-step, just a basic/general/big-picture answer of how one can approach building a telnet interface for an application.
telnet is based on the TCP/IP protocol. To "do" telnet from a C program, you'd start messing with sockets, accept()-ing connections and reading and writing to them using fork()-d threads (that's VERY briefly it).
If the app is already there, and already communicates to the console via stdin/stdout, you can rig a telnet interface on to it using (a) some configuration in your Internet daemon, (x)inetd, or by misusing the Swiss Army knife of TCP/IP, netcat.
The docs for both those programs describe how to set things up, vaguely. If you need more help, you know where to ask!
Currently I need to develop some program that will communicate with cisco devices over serial line. I want to build testing environment on my development linux machine. So, I found dynamips cisco emulator. This emulator can provide interface via serial line with '-U /dev/ttyS0' option. Well, this causes dynamips to open hardware serial port and communicate via it. I'm able to connect to this hardware serial port from another linux machine with serial client like minicom.
However, since i'm using virtualbox for both linux machines, I link serial ports via virtualbox ability to forward serial port to named pipe. This scheme seems to be working, but very redunant. I'm looking for a method to run dynamips and minicom on a single linux machine.
I found that pseudo-terminals could be useful in my case. But I've tried to run dynamips with '-U /dev/ptmx' and then connect with minicom to created /dev/pts/... port and vice versa. In both cases I've got input/output error on both sides.
Unfortunately, modern pseudo-terminals aren't that easy. After opening the master with posix_openpt() or open("/dev/ptmx"), you must call grantpt() and unlockpt() on the master FD before it and its corresponding slave device are usable. (The openpty() etc. utility functions simplify this.)
As a workaround, the ever handy socat may be of use.
# terminal 1
socat pty:link=$PWD/pts unix-l:$PWD/ptm-pipe &
dynamips -U $PWD/pts
# terminal 2
socat unix:$PWD/ptm-pipe -
I'm running Xorg and my (Qt) program daemonises itself. Now I log out and restart the X server. When I log in again my process is still running fine, but I can't see it.
Is there a way of attatching the new incarnation of the X server to the old process?
If I don't restart the whole server, but log out and in again, is there a way to look at the old process?
Thanks
xpra should achieve your requirement. And it can also start tcp connection (without need of ssh). Start it on the you server:
xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:10000
Connect it on your client:
xpra attach tcp:SERVERHOST:10000
You can also use mac or windows xpra app to connect it. I tried in on win7 and osx10.10.2. The download link:
windows: https://www.xpra.org/dists/windows/Xpra_Setup.exe
mac: https://www.xpra.org/dists/osx/x86/Xpra.dmg
After the connection to the X server is lost, it is not possible to regain it.
There was an xserver proxy called xmove, but it is quite deprecated and doesn't work with several newer X extension, which are likely used by modern toolkits.
You could try to run your process in another virtual X server like xvnc or (better) NX. NX is a X proxy technology developed by NoMachine. There exist free implementations of NX servers as well.
If you run your program inside such a server, it is possible to attach and detach from it from arbitrary graphical environments.
Use something like Xpra: it allows you to run applications on an off-screen X11 server to which you can re-attach whenever needed, and from remote machines too. It supports "seamless" sessions too so the windows will appear just like local windows.
Practical example:
xpra start :10 --start-child=/bin/YOURAPP
Then whenever you want to re-attach (say after an X11 server restart):
xpra attach :10
Or from a remote machine:
xpra attach ssh://THESERVERHOSTNAMEORIP/10
What is the best way to setup one Linux box to listen on its serial port for incoming connections? I've done a lot of googling but I can't find the right combination of commands to actually get them to talk!
My main objective is to provide a serial interface to running instances of kvm/qemu VMs. They currently only have a VNC interface (they are on headless servers, no X). I can get the VM to create a serial device by starting it with the -serial file: flag, but how to talk to it, is a whole other problem. Both boxes are running Ubuntu 8.04.
The Linux Serial HOWTO has a lot of detailed information about serial communication in general. The more-specific Linux Remote Serial Console HOWTO is what you're really looking for if you want to be able to log into your virtualized systems using the serial port as if you were at the console. As Hein indicated, you'll need a null modem cable and need to run minicom on the remote terminal.
The Linux console is used in two ways, each of which must be configured separately for serial use. You can configure the kernel to copy its messages over the serial port, which is occasionally interesting for watching the system boot and nearly indispensable if you're doing kernel debugging. (This requires kernel support and updating the boot parameters so the kernel knows you want serial output; see chapter 5 of the second howto.) You're probably more interested in logging in via the serial port, which requires running getty on the serial port after boot (just like your system already runs getty on the virtual terminals after boot), which is described in detail in chapter 6 of the howto.
I assume you connect the two serial ports using a "null modem" cable.
Use a program like minicom to talk to remote system -- you probably need to set up the communication parameters and possibly turn off hardware flow control (if your cable doesn't have the flow-control lines connected).
Say you're doing this on /dev/tty1.
in the shell
chown *youruser* /dev/tty1
then in a Perl script called example.pl
open PORT, "</dev/tty1" || die "Can't open port: $!";
while (defined ($_ = <PORT>))
{
do_something($_);
}
close PORT;
Obviously there is more to do if you want this to start automatically, and respawn on error, and so on. But the basic idea is to read from the serial port like a file.