I ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.
Related
I was wondering if there was any way that I could debug a floppy disk emulation in Linux.
The main thing I want to be able to do is to see the values of registers and custom defined bytes and words as the emulation runs.
Another thing I would like to be able to do is to run the emulation one step at a time, and see what line of code my emulation is currently on.
I am currently just running my floppy disk image under qemu-system-x86_64 and letting it run without any feedback besides the emulation.
If anyone can supply me with something along the lines of command line statements that accomplish this sort of thing, and what programs I could either move to or install alongside to help me out, it would be much appreciated.
I don't have enough idea of qemu because I haven't used it much. But from your requirement perspective, I think you should try bochs emulator. It's quite easy to use and comes with a built-in debugger. Only thing is, you need to compile it from source (if on Linux) making sure the --enable-debug and --enable-disasm switches are enabled (alongwith any other options you might want to enable). (On Windows however, the debugger comes as a pre-built (separate) executable in the installation, but that's sort of irrelevant in your case I guess.)
Over the years, I just can't seem to find a free debugger that suits me. Normally, I just connect to my university's cluster and use DDT, but I'd like to find something free that I can use locally on my machine. I've been playing with gdb -tui, but it doesn't have a window to show the other project files or a window for watched variables. I can't find a way to open up another file in the project in the source window so that I can scan the source code and see where I want to set my breakpoint. I have to open the other file in vim, find the line number, then set the breakpoint in gdb. I have switched to doing all my code writing in vim, and that seems to work pretty well for me, but I still haven't found a good all-in-one package for debugging the code after I write it. Any suggestions from anybody who have a good code development setup would be greatly appreciated.
Here is what I want to do:
I want to run Mathematica on another Mac from my Mac (both Snow Leopards). I want to do this because the remote Mac has multiple cores/processors while my local Mac is rather shabby. I would like to have the front end still locally (i.e. the graphical interface).
What I've learned:
I used to do this type of thing from multiple Linux machines and was expecting to have similar success for Mac-to-Mac operation. However no such luck.
The problem seems to be a display issue (front end).
Mac front end runs in Aqua while X11 is what is really needed (this is why there is no problem on Unix). While Macs have X11, for some reason Mathematica can't use it.
So how do I get around this issue?
Possible solutions that I have had to rule out are: 1. screen sharing. Not practical since someone else will be using the remote Mac on another account. Screen sharing only uses the active screen. 2. Installing Unix on the remote computer. Not possible in my situation.
Thanks.
You should be able to set up a remote kernel on the other Mac. This is done through the Evaluation > Kernel Configurations menu item. The you can set the remote kernel for a given notebook using Evaluation > Notebook's Kernel or globally via Evaluation > Default Kernel.
I haven't done this in a while, and it's sometimes useful to test things from a terminal with something like
ssh <user>#<remote.machine.com> </path/to/remote/Mathematica.app/Contents/MacOS/MathKernel>
Why not use the command line kernel? I have a script math which does:
#!/bin/bash
rlwrap /Applications/Mathematica.app/Contents/MacOS/MathKernel
I built rlwrap from source, but basically that tool gives you readline behaviors. You can just do
ssh remote-machine /Applications/Mathematica.app/Contents/MacOS/MathKernel
The only solution, I believe, is for you to upgrade to OS X Lion. It allows simultaneous screen sharing sessions where each user can control the screen for their own account:
http://www.apple.com/macosx/whats-new/features.html#screensharing
I was wondering if anyone knew of a way to remotely debug the Linux kernel running under VMWare (and if so, if there's a way to do it in Windows since linux kind of scares me...). Both are x86. I know VMWare has support for this (I saw a post about remote debugging via gdb), but if there was a way to do it from Windows (i.e. Eclipse CDT or something) that'd be awesome.
Thanks!
-Robert
You're not going to debug the Linux kernel (particularly remotely) using anything but gdb with { kdb | kgdb } extensions in-kernel, unless you write your own debug hooks.
According to Linus, he would prefer if you do not use a kernel debugger, even on Linux. Good luck getting one to work from Windows :)
Granted, this posting is from several years ago. Maybe he has changed his mind since then???
There's a thread where someone got 95% of the way here: http://communities.vmware.com/thread/236251. The one part he's missing is that the source files can't be found, but CDT supports setting a source path different from the symbol file. A bit of messing around and it seems to be working (i.e. I can set breakpoints, see the entire address space, etc.)
I would recommend debugging one Linux VM from another linux VM, if you only have one machine running Windows available.
You're going to have enough difficulty just getting that working, without throwing in something that is as unsupported and untested as what you're currently asking for.
What is your favorite technique for launching a windbg user-mode remote debugging session?
Why is do you prefer this technique over other techniques? (pros/cons)
There are at least four different ways to do user-mode remote debug using windbg, as documented in the "Remote Debugging" section of the debugging tools for windows help file.
run app on target then attach to it from the host windbg
have the host windbg use remote.exe to launch the app on the target
have the "smart client" host windbg launch the app on the target via a process server that is running on the target
run a windbg instance on the target machine using the option "-server" to automatically start a server, then connect to the server from a 2nd machine.
Option 1 is my favourite because it is the simplest. I get to launch the app in the normal way without worry about getting WinDbg to set the right working directory, pass any command line arguments, etc.
Fortunately I've not run into any cases where this hasn't worked!
There is no "the best" solution. Each of the possibilities has advantages and disadvantages and it's good to understand all of them. It depends on several factors like:
where are the symbols located
which PC has access to the Internet to download the OS symbols
what amount of data may you copy to the server (clients often accept better if it's just a single Exe)
what's the bandwidth between client and server
do you need other commands that just CDB/WinDbg, e.g. access to CMD, then consider remote.exe
who's available on the server side, a debugging expert whom you can easily tell a lot of cryptic commands or a normal user who barely knows how to start a command prompt
are both sides in a private network, so you need a "man in the middle" server to be able to access each other (or port forwarding as an alternative, which IT guys don't want and it may take days to get it set up)
From those 4 options, don't forget that clients often want to see exactly what you do, so they require an RDP session, Teamviewer or similar. That's something they understand.
I tend to use option 4 (-server) because it is the only one that doesn't "pop" when you break into the kernel debugger long enough for the TCP connection to timeout. But this is more complex and not fully satisfying. So I'm looking for "best practices".