tags:

views:

286

answers:

3

Hi, I'm mostly developing C++ applications with g++ on solaris 10, x64 boxes. These applications are built and deployed with symbols, but without sources on the remote site. When debugging you can then set breakpoints and inspect variables, but you have to "manually" map the reported line numbers to an editor (usually vim/gvim) where you keep opened the relevant source file available locally. Is there anything that automates that? My idea would be to have a local vim/gvim instance running with access to the local sources, while the remote gdb sessions tells it "go to this file, at this line" each time I step in the remotely debugged code. I've searched a bit, but it seems I couldn't find anything for that. Clewn did seem promising, but as far as I could understand, it requires a vim/gvim running on the deployed host (while my sources are on my local host) side by side with gdb.

EDIT: As a further clarification: local machines are usually Windows PC, or other solaris 10 hosts. To remove some already investigated options upfront: gdbserver is not an option for me because:

  • Solaris 10 (x86 or Sparc) platform is not supported
  • Even if supported, it would make using windows pc as local machines very difficult since I'd need to run a cross-compiling gdb there.

Thanks, Andrea.

A: 

You should check out gdbserver. It allows you to connect a local gdb instance to a remotely running program. I'm curious what environment you are running gdb in? If its on the command line you can't get it to automatically go to lines in source files anyways even if they are on the local machine. Unless you use gdb with Emacs. This site says emacs will "automatically find the source file for that frame and puts an arrow (=>) at the left margin of the current line. Emacs uses a separate buffer for source display, and splits the screen to show both your gdb session and the source. " Not sure if that can be done remotely though.

controlfreak123
and if you have copies of the source for the deployed programs why can't you just run and inspect them from your local machine to begin with?
controlfreak123
See my edited question for why gdbserver is not an option.Emacs with gdb doesn't seem to be able to work remotely, so no way there either. Finally, I can't run those programs locally because well, they _have_ to be deployed on remote machines. The source for the data they process is simply not something I can have locally in an effective way for me to debug.
abigagli
checkout http://bvrde.sourceforge.net/ It says "It runs on a Windows NT platform and connects to almost any UNIX / LINUX system. It requires Windows 2000 or better installed, but all the development tools (compiler, linker, debugger) should be located on the remote system." I would be very cautious about debugging software that is on a live system though. As soon as you put those tools on the remote host anybody can debug the program and find flaws.
controlfreak123
BVRDE seems to be able to drive a remote gdb on a site and access sources on another, so that may be an option, although being for windows only this rules out the possibility of viewing sources on local solaris hosts... But is anyway a step in the right direction
abigagli
+1  A: 

GrandUnifiedDebugger # Remote gdb

Do you know any way to run gdb on a remote host under GUD?

I have this little script:

#!/bin/sh

u=$2
shift
shift
sudo -u $u gdb -fullname $*

To make gdb run as another user (call it as “gdb-wrapper.sh USER GDBARGS”). You could change the sudo to ssh.

M-: (setq gud-gdb-command-name "gdb-wrapper.sh") or something like that, before you enter M-x gdb, should do the trick.

ephemient
Ok, I missed that, but does this actually allow to have _local_ emacs access _local_ sources while controlling the remote gdb? I'd like to be sure this isn't simply a "GUI" for gdb that nonetheless requires sources to be available on the same host where gdb runs on, which is not an option for me
abigagli
+1  A: 

Ok, I'm answering myself since I just discovered, after a better read at clewn documentation, that it's really what I was looking for. That is, it doesn't require sources to be available on the target machine, but they can stay on the development machine where an instance of vim will be there used to access them locally.

From clewn's documentation:

3.3 Remote debugging:

The '-x' option with its mandatory parameter pathnames_map, is used to do remote debugging on a target where clewn and GDB are running, from a host where the development is done and where VIM is running.

abigagli