What's the difference between gdbserver and remote gdb (i.e. over SSH)?
Why do they coexist? The Unix philosophy suggests the software should do one thing well, i.e. debug local programs.
It seems to me that gdb violates this principle by doing another thing in addition to that - interacting with gdbserver.
gdbserver is smaller than GDB and has fewer dependencies, so it can be run on a system which is resource constrained such that GDB itself can't be run. Or maybe GDB just can't be run for some other reason, e.g. the target platform doesn't have Python, and you want to use some of the Python features of GDB.
Next, but kind of related, the target platform might not be the same architecture as the host platform (on which GDB runs), maybe compiling GDB, Python, syntax-highlighting libraries, etc for a small target isn't what you want to do with your time, instead you can just compile gdbserver, and then run GDB on your local machine.
Finally, though gdbserver is useful in itself, it also serves as a useful mechanism to test GDB's remote serial protocol support. This protocol is documented in the GDB manual and allows software other than gdbserver to interact with GDB, for example OpenOCD, and QEMU, both support GDB's remote protocol, this allows GDB to debug baremetal targets on which neither GDB, nor gdbserver could ever run.
You are correct to observe that this basically means that GDB has two methods of debug, its native target support, and its remote target support. If we wanted to be ideologically pure then we could (in theory) remove the native target support from GDB, and just make use of the gdbserver in all cases, i.e. when you try to debug a program on the local machine, GDB would automatically start gdbserver, connect to it, and debug through that interface. I don't expect to see that change any time soon though.
Related
We've got this legacy Fortran code running on a board with an A9 processor, and I've noticed some funny behavior when using gdb. Threads continue to run when it is in all-stop mode, and it seems gdb crashes when you switch it to non-stop mode. It also can't do watchpoints on symbols in the Fortran code, not sure if that's due to the port or the binaries not belonging to the same toolchain. You can set a watchpoint on the address cast as a C type, however.
We've got toolchain binaries from CodeSourcery installed to the stage directory during the rootfs build, then as part of our application build Linaro binaries overwrite some of the libraries in the targetroot. The libraries that are overwritten are (some of?) the only ones needed by the application and the ones it is linked against (libstdc++, libgfortran, and libpthread).
Using either gdb from CodeSourcery or Linaro seems to function equivalently, though I didn't try setting hardware assisted watchpoints with the Linaro compiler. Neither seem to be configured to work outside the documented behavior, which unless I'm mistaken what I've observed runs counter to it.
So is this fine? I mean, it runs, but if gdb is at least slightly broken I don't know what other utilities would be. I'd like to see about making use of Eclipse+Photran and TCF Agent, and I was looking into where the CodeSourcery toolchain came from, which led me to Yocto. I've been trying some builds with Yocto at home, and I'm wondering if it's worth my time to bring in a VM with all of this set up to try run our application with the toolchain built into the rootfs from the ground up.
Probably too late to switch anything over but if I can just have a smoother environment under which to work then I can just toss the source back into our current solution when it's time to turn in a fix.
I'm a whiz with Visual C++, but Linux development is new to me. In Visual Studio, it's easy to trace into any code implemented by the C run time libraries. I just need to make sure the sources are installed and I can step right into any function I'd like -- malloc(), cout::operator<<(), whatever.
I'm trying to develop using Eclipse's C++ package. How can I step into C run time routines there? Since Linux is open-source, how do I step into operating system routines? Seems like it should e possible -- am I missing debug information, source code, or both? Something in my configuration?
I'm using Ubuntu 12.10 at the moment. I'm using g++. I believe I'm using the Eclipse build system as I never imported a makefile project; I just started with a simple "Hello World" project from the C++ project wizard in Eclipse.
After hacking at this a bit:
I've installed the libstdc++6-4.2-dbg package thinking it would be debug symbols for the libstdc library:
sudo apt-get install libstdc++6-4.2-dbg
I've also installed dpkg-dev, since the next step said I needed it:
sudo apt-get install dpkg-dev
I tried installing libc6 sources into a directory under my home:
apt-get source libc6
At this point, trying to step into printf() tells me that printf.c is missing. I can't step into malloc or strlen, which suggests that I don't understand how the C runtime libraries are factored in Linux. How are libc, glib, and libstdc++ different? Which packages do I need?
If I ask Eclipse to open the printf.c file I do have (at ~/eglibc-2.15/stdio-common/printf.c), it doesn't open the file (doesn't adjust the debugging window to show the source) and repaints the window that shows the error message about not being able to find the file. (Can't find a source file at "printf.c" Locate the file or edit the source lookup path to include its location.)
Whilst, as a Kernel developer on Linux, I do agree that using the individual tools separately will be a good thing to learn, and as such Basile's answer is usefuel.
However, the stepping into C runtime libraries should be equally possible with Eclipse. But just because the OS is open source doesn't mean that it supports you clambering around inside it willy nilly - in fact, you CAN NOT step into the OS itself from user-mode code. You nee KGDB (google it), and you definitely need a second computer to attach to the one being debugged, because when you step into the kernel, you will essentially lock up the machine, at the very least in the context you are stepping, but most likely also prevent other work from being done until you get back out from the kernel, so for example, if you step into open(), at some point the entire filesystem may well stop working altogether until you are back out of whatever lock you are holding. This wll certainly upset some software. Note that this is just an example of how things may work unexpectedly when debugging the kernel, not strictly "I've done this and it happened" - I have debugged kernels with debuggers several times, and you do have to be careful with what you do, and you certainly can not run the debugger on the same machine, as the machine STOPS when you are debugging.
Going back to the usermode, which you CAN debug via Eclipse, essentially all you need to do is install the source code for the runtime library you are interested in, and go... Same principle as on Windows with visual studio - except that nearly all software you ever run on a Linux system is available as source code. You may need to recompile some libraries with debugging symbols, and just like in Windows, you need to make sure the debugger knows how to find the source code. Everything else should be handled by the debugger in Eclipse. I spent about three years using Eclipse for both local and remote debugging, and in general, it works. There are quirks in places, but that's the case with almost any debugger.
Good luck.
First, you don't need Eclipse to develop software on Linux. You should better learn to do that with independent tools (command line) like emacs or gedit (as editor), git (version control), make (builder) which runs the gcc or g++ compiler (both gcc & g++ are part of GCC, the Gnu Compiler Collection).
really, you'll learn a lot more by not depending upon Eclipse; it may just hide you the real commands which are doing the job, and you should understand what they really are.
You want to pass the -g -Wall options to GCC. The -g option asks for debug information, and the -Wall options asks for almost all warnings. Improve your code till no warnings are given.
And the operating system is providing syscalls (which are operations provided by the kernel to applications; from the application's point of view, a syscall is atomic so you cannot step into it; however strace may show you all the syscalls done by some execution). If you wanted to step by step inside system libraries like libc you need the debugging variant of it (e.g. some libc6-dbg package). But there is usually no need to dive inside system libraries.
See http://advancedlinuxprogramming.com/
Then, you will use gdb to debug the binary program.
So, step by step instructions inside a terminal:
edit your source files with emacs or gedit
learn how to use GCC: for a single source C++ program compile it with g++ -Wall -g source.cc -o progbin and type ./progbin in your terminal to run it. Only when the program is debugged and satisfactory would you compile it with optimizations (by giving the -O or -O2 flag to gcc or g++)
Use gdb to debug a program (compiled with -g).
for a multi-file C++ program, consider learning how to use make
use a version control system like git
For beginners, I suggest to avoid Eclipse, because it just hides to you what is really happening underneath (Eclipse is simply running other tools like the above commands)
Software development under Linux requires a different mindset than under Windows: you really are using your own loose combination of independent tools, so better to learn a bit each of them.
NB. to step inside "system" functions like malloc (which is above syscalls like mmap) you need the debug variant of the libc package with aptitude install libc6-dbg, and you need to set LD_LIBRARY_PATH to /usr/lib/debug etc...
We are moving our development for C to C++, but all build servers run Linux and development happens on Windows machines. Our C editor does not do C++ very well so we are looking at alternatives.
The code itself lives on the build server connected by \\opt\code... type link in Windows.
We need SSH as that is the normal connection to the build servers. We would like an integrated solution for errors/warnings being able to opened in the editor. We do not care about running the code.
Are there any free editors that can execute builds over SSH?
Thanks.
NetBeans allows to build over ssh. We are using this from Linux development computers to linux build machines. I am not sure if this is possible from Windows to Linux. Here is a tutorial: Tutorial
This link suggest this should be possible using plink and any editor that can run plink as a compile and capture the resulting stdio and stderr output.
You can use Visual Slick Edit it has a scripting language which can be used to spawn commands. Btw, if your build is linux based I suggest you to edit on linux (there're various programmers editors there available for free).
In windows almost every editor worth being calling editor has the power to manage builds (often via make), so even VIM or Emacs can be productivity choices (yeah I'm not a big fans of IDEs, my actual editor is VIM with a good tons of vimscripts and yeah, I've got code navigation, error browsing and the speed of light while typing - and the same is possible with emacs).
Ultraedit is another editor able to Edit file over ftp (and maybe over SSH), but I doubt it can spawn a remote make and fetch results.
If you're not reliyng on builds, but just compiling, maybe is worth checking the Cygwin porject and see if you can arrange a compilation under Windows, then for the build manually resort to the Linux box, this would probably remove the compilation problem (every programmer will compile on his box, and only builds (compile+link) would be left on the linux box.
You might use X forwarding and run any linux IDE on the Linux side, while operating it via Windows machines. See http://www.math.umn.edu/systems_guide/putty_xwin32.html for an example.
Or even setup a VNC remote desktop connection.
I never tried this, but it looks like that using Code::Blocks and Xming you can do this.
Here is tutorial http://wiki.codeblocks.org/index.php?title=Using_Xming_for_remote_compilation
You could try using Dokan SSHFS to mount the code as a drive on each Windows machine. Then developers are free to use whatever IDE they choose.
it's simple i had this linux pc which i connect remote and i have this application that i run there and i want to debug it, but i just don't know how.
It's the simpler c++ app on the world, load some libraries, do some calculus, print some output and return,
It's just that, i just haven't any clue.
So any help would be appreciated. Thxs anyway
You can't use Xcode for this - just use gdb (which is what Xcode uses under the GUI anyway).
[You might be able to do it indirectly, if you build and debug the code on your Mac, but that assumes that you're not doing anything non-portable (i.e. Linux-specific) in the code, and there aren't any other platform-specific dependencies (e.g. third party libraries, etc). You would still need to do final test and debug on the Linux machine but at least you could potentially squash any logic bugs on the Mac first.]
I am trying to build gdb for armv6 architecture. I will be compiling this package on a Fedora Linux-Intel x86 box. I read the process of installing the gdb, like
Download the source pachage
run configure -host
make
But I got lost in the process because I was not able to make out what will be the host, target, needed for the configure script.
I need to basically be able to debug programs running on armv6 architecture board which runs linux kernel 2.6.21.5-cfs-v19. The gdb executable which I intend to obtain after compilation of the source also needs to be able to run on above mentioned configuration.
Now to get a working gdb executable for this configuration what steps should I follow?
We (www.rockbox.org) use the arm target for a whole batch of our currently working DAPS. The target we specify is usually arm-elf, rather than arm-linux.
Be careful with arm-linux vs. arm-elf, eg.
http://sources.redhat.com/ml/crossgcc/2005-11/msg00028.html
arm-elf is a standalone toolchain which does not require an underlying OS. So you can use
it to generate programs using newlib
arm-linux is a toolchain targetted to generate code for linux OS running on an ARM machine
We sometimes say arm-elf is for "bare metal".
Unfortunately there's another "bare metal" target arm-eabi and no one knows what the difference between these two exactly is.
BTW,
The gdb executable which i intend to obtain after compilation of the source,also needs to be able to run on above mentioned configuration.
Really? Running GDB on an ARM board may be quite slow.
I recommend you either of
Remote debugging of the ARM board from an x86 PC
Saving a memory core on the ARM board, transferring it to an x86 PC and then inspecting it there
Cf.
http://elinux.org/GDB
Cross-platform, multithreaded debugging (x86 to ARM) with gdb and gdbserver not recognizing threads
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/remote-debugging
target/host is usually the target tool chain you would be using (mostly arm-linux)