Linux Tools Development

Today we will start a topic on tools available for Linux software development environment.
When it comes to any application + middle-ware + device driver development, tools play very important role which saves time of development by making easy to develop and debug.



Source code editor(Vim, Emacs (OTP), Eclipse, Cscope and Ctags)
Compiler (the one and only GCC) [How to compile a compiler? :)]
Glibc (GNU C library) [Development and maintenance ]
Debugger(application and kernel (gdb and kgdb))
Crash analyzer (kernel crash analyzer and application crash analyzer )
Memory leak detectors [combination of backtrace() system call with memory leak detector like boehmgc and leaktracer]
Designing an application which can insert debugging information.


In our future post we will discuss the useful features of above tools and how to develop them.




We will have source code walk through of  tools (2, 3, 5 and 6).Information related to Tools mentioned in 2, 3 and 5,6,7 are very interesting and useful for a Linux Application and Driver developer.


Comments

Post a Comment

Popular posts from this blog

Getting backtrace during stack corruption

As we know , if program crashes and if it results in stack corruption, GDB will never give backtrace of the crashes.Even coredump does not help. Consider the below situation of stack corruption, Is it possible to make out anything useful from this for debugging?No Program received signal SIGSEGV , Segmentation fault . 0x00000002 in ?? () ( gdb ) bt #0 0x00000002 in ?? () #1 0x00000001 in ?? () #2 0xbffff284 in ?? () Backtrace stopped : previous frame inner to this frame ( corrupt stack ?) ( gdb ) Those bogus adresses (0x00000002 and the like) are actually PC values, not SP values. Now, when you get this kind of SEGV, with a bogus (very small) PC address, 99% of the time it's due to calling through a bogus function pointer. Note that virtual calls in C++ are implemented via function pointers, so any problem with a virtual call can manifest in the same way. An indirect call instruction just pushes the PC after the call onto the stack and then sets the PC
Read more

Analyzing Crash dumps in Linux using GDB

GDB is a common tool for debugging applications in Linux development environment. Before generating the core dump use -g compiler option for compiling the application for enabling debugging symbols. 1. set ulimit -c unlimited  in cmd to enable core dump. 2. Then run the application, after application crashes it generates code dump with core.pid file name. 3. Load the application in gdb ex: gdb <path to application> 4. In this step load the core dump by using core-file <path to core dump> command 5.Just use bt for getting the backtrace of the crash which will give you exact location where app has crashed. Use GDB instead of logging which will save your time for debugging !!!!
Read more

.b4s playlist parser WINAMP XML PlaylistFormat

More info on this file format is at http://filext.com/file-extension/B4S This can be parsed using following xml based parser application. /* .b4s parser Application */ /*Author:chandrashekar bs*/ /*email:buggs.cancerion@gmail.com/chandragoan@gmail.com*/ /* I have not added <> for including files because of in google blogs since <> are interprested as htnl syntaxes and content within thos are not appeared*/ #include iostream #include string.h #include libxml/parser.h #include libxml/xinclude.h #include libxml/tree.h #include libxml/xmlIO.h int main(int argc, char **argv) {     xmlDocPtr doc;     xmlNodePtr nodePtr;     xmlNodePtr rootnodePtr;     xmlChar *xmlbuff;     int loopcount1, loopcount2, loopcount3, loopcount4;         loopcount1=loopcount2=loopcount3=loopcount4=0;     if(argc !=2)     {         printf("Usage %s: Enter valid b4s playlist file",argv[1]);     }     char *filename = (char *)argv[1];     doc = xmlParseFile((c
Read more