I am an intermediate C programmer who is learning his way around. I recently learned using GDB (forced to actually) and also am doing some code using Ptrace.
I was browsing through some code on ptrace and came across "DEBUG INFO".
I want to know what this means and when should I include this in my code?
What are debug info files?
I couldnt find much from google and wiki related to this. There is no wiki for that tag too.
May be if you can point me to the right direction I can repay by writing one.
DEBUG_INFO you are referring to is probably just an option (and define) of linux kernel. Enabling it when configuring kernel tells compiler to include debug information in resulting binary. This debug information itself is just additional data, that allows debuggers (and other tools like strace, addr2line, gprof, ...) relate binary code it's executing to source it was compiled from (source lines, variable names, etc, etc). You can find more details on debug information in general starting at DWARF (popular debug data format).
check for what is a core dump .you might get some directions.
The whole credit goes to Peter for the answer.
Initially I went through "What is core dump"
Then I came across the following link which actually tells the difference between
Debug Build
Release build
which is: debug build includes debug information while a release built doesn't have these and is Optimized code.
Also this answer can help you get more information.
Related
While there were times that you want to know how kernel's specific code work, the best way is to write your test code by including specific header files, e.g., I want to know how kernel's kfifo working , the first I need is including <linux/kfifo.h>.
But this is not work for me, by only include <linux/kfifo.h>, we must tell GCC the header file search path, some predefined macro like __KERNEL__ and so on, is there any sample project did this before? or you can tell me how to debug these code without copy these code out and delete some useless feature.
The most straightforward approach to debugging kernel infrastructure code (basically, everything not including device drivers) is to compile a kernel for uml architecture (make config ARCH=um and the usual stuff after; make sure to retain the debug symbols in the build). Then you can use your favorite user space debugger to run and analyze the obtained uml kernel (as it is a normal linux executable).
http://lxr.linux.no/#linux+v3.12.1/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
By the way, the linked howto is badly out of date - you don't need to download and patch anything; UML is part of the kernel for many years now. But it will get you started, especially if you google around a bit for additional details.
When an application causes a serious segment-fault issue, which is hard to find or track. I can use a debug version and generate a core dump file when issue happens. And debug this app with core-dump file.
But how to track down exceptional bugs in application when released? There seems to be no core-dump file in release version. Although log is an option, it is useless when there is a hard to track bugs happens.
So my question is how to track down those hard to track bugs in release version? Any suggestions or technology out there available?
Following reference may help the discussion.
[1] Core dump in Linux
[2] generate a core dump in linux
[3] Solaris Core dump analysis
You can compile a release version with gcc -g -O2 ...
The lack of core dump is related to your user's setting of resource limits (unless the application is explicitly calling setrlimit or is setuid; then you should offer a way to avoid that call). You might teach your users how to get core dumps (with the appropriate bash ulimit builtin).
(and there is some obscure way to put the debugging information outside of the executable)
The distributions provide -dbg packages that provide debugging symbols for programs. They are built along with the binary packages and can provide your users the ability to generate meaningful backtraces from core dumps. If you build your packages using the same utilities, you can get these -dbg packages for your own software "nearly free".
I suggest to use a crash reporting system, in my experience we use google's break-pad project for our windows client program, of course you can write your own.
Google break-pad is an open-source multi-platform crash reporting system, it can make mini or full memory dump when exception or crash happen, then you can config it to upload the dump file and any additional files to a specific ftp server or http server, very help to find bug.
Here is the link:
Google Break-pad
Ask the "customer" for a description of what he or she did to make it crash, and try to replicate it yourself with your own version that has debug information.
The hard part is getting correct information from the customer. Often they will say they did nothing special or nothing different than before. If possible, go see the person having the problem, and ask them to do what they do to make the program crash, writing down every step.
I'm building a shared library in C, which other programs use. Sometimes, these other programs crash because of some error in my shared library. While reproducing these sort of bugs, it is very useful for me to know which functions of my library are being called, with what arguments and in what order. Of course I can add printf() calls to all my functions, or add breakpoints to all of them, but I figure there just has to be a better way to determine this.
Edit: since I'm doing this on OSX, dtrace and the related script dapptrace seem promising. However, after digging through some documentation I'm still a bit lost.
Say, my library is /path/to/libmystuff.so and I've got a program test which links to this library. Using dtrace, how would I bring up a list of all the function calls that reside in libmystuff.so?
You could use ltrace for that purpose if you work on a Linux system. The original poster shows, in the comments below, a solution that works on Mac OS X using dtrace.
I am assuming that you are working on Unix.
Use gdb for debugging purposes.
If your program has crashed.
you can use the core file generated for looking into the stack trace.
It will give all information that you have asked for.
for more information for checking the stacktrace using gdb with the core file see here.
You can also log the functions call on file system with all details like function name, arguments etc.
(Usually logging is help in Server-Clients application but I am not sure about your application).
This way You can trace all calls. You can also enable logging in debugging mode only. I hope this reply will be useful to you.
I have learned C and I would like to start to improve open source software. I would like to hack away one irritating bug in GTK+. To see the bug I need to use Gedit.
How can I download the sources of GTK+ and gedit and compile both of them so that I can see where the bug is? And I have never used any debugger in Linux so is there somewhere a tutorial for that?
You can get information about downloading and compiling of gedit here:
http://projects.gnome.org/gedit/developers.html
My Debugger of choice is GDB:
http://www.gnu.org/software/gdb/
GDB is a console application that may be hard to handle for a beginner. Try an IDE like Eclipse that provides a GUI to GDB.
Almost all Linux debuggers are front-ends for or adaptations of the gdb debugger. You should therefore learn how to use this first, preferably by starting on
small programs of your own construction, not giant FOSS codebases. The gdb manual,
available from here is actually a pretty good tutorial.
The information on building and installing GTK+ should be here:
http://www.gtk.org/development.html
The sources should be here:
http://www.gtk.org/download-linux.html
You can check out gdb:
http://www.gnu.org/software/gdb/ That's a pretty standard linux debugger. I would spend time with it on something simple first, or get an IDE that uses it. Learning gdb can be worth the time though.
gdb is a dinosaur which should long since have been made extinct. Debugging is one area where (gasp!) Windows beats Unix. Having got that off my chest, I advise you to start with the Data Display Debugger (DDD) graphical front end to gdb. Yes, the GUI is quaint, but you will be far more productive, quicker, than if you start with gdb.
Also don't overlook valgrind for finding and diagnosing memory errors. The KDE project actually mandates use of valgrind; I'm not sure about Gnome.
It is possible that you won't see the bug if you download the latest gedit and gtk+ sources. It might be fixed in the latest sources or the latest sources might be different enough to not trigger your bug.
What Linux distribution are you running?
First of all I'd suggest consulting your distribution's bug database to see if someone has filed a similar bug. If you don't find anything, I'd suggest using your distribution's tools to obtain the source that corresponds to the binary that you have installed on your sytem (e.g. apt-get source libgtk-2.0 on Debian or Ubuntu).
Also, your distribution might also make a debug package available (e.g. libgtk2.0-0-dbg on Debian) which will let you run a debugger on the binary that you already have without requiring the source. While this is no substitute for having the sources, it can be useful for running valgrind or making sense out of a core file.
I'm looking for a tool that, given a bit of C, will tell you what symbols (types, precompiler definitions, functions, etc) are used from a given header file. I'm doing a port of a large driver from Solaris to Windows and figuring out where things are coming from is getting to be difficult, so this would be a huge help. Any ideas?
Edit: Not an absolute requirement, but tools that work on Windows would be a plus.
Edit #2: To clarify what I'm trying to do, I have a codebase I'm trying to port, which brings in a large number of headers. What I'd like is a tool that, given foo.c, will tell me which symbols it uses from bar.h.
I like KScope, which copes with very large projects.
KScope http://img110.imageshack.us/img110/4605/99101zd3.png
I use on both Linux and Windows :
gvim + ctags + cscope.
Same environment will work on solaris as well, but this is of course force you to use vim as editor, i pretty sure that emacs can work with both ctags and cscope as well.
You might want give a try to vim, it's a bit hard at first, but soon you can't work another way. The most efficient editor (IMHO).
Comment replay:
Look into the cscope man:
...
Find functions called by this function:
Find functions calling this function:
...
I think it's exactly what are you looking for ... Please clarify if not.
Comment replay 2:
ok, now i understand you. The tools i suggested can help you understand code flow, and find there certain symbol is defined, but not what are you looking for.
Not what you asking for but since we are talking i have some experience with porting and drivers (feel free to ignore)
It seems like compiler is good enough for your task. You just starting with original file and let compiler find what missing part, it will be a lot of empty stubs and you will get you code compiled.
At least for beginning i suggest you to create a lot of stubs and modifying original code as less as possible, later on once you get it working you can optimize.
It's might be more complex depending on the type of driver your are porting (I'm assuming kernel driver), the Windows and Solaris subsystems are not so alike. We do have a driver working on both solaris and windows, but it was designed to be multi platform from the beginning.
emacs and etags.
And I leverage make to run the tag indexing for me---that way I can index a large project with one command. I've been thinking about building a master index and separate module indecies, but haven't gotten around to implementing this yet...
#Ilya: Would pistols at dawn be acceptable?
Try doxygen, it can produce graphs and/or HTML and highly customizable