Question

I am a newbie as far as open-source development is concerned. I have tried my hand at several projects but have always ended up getting frustrated due to the large code-base.

One particular problem I have always faced is the inability to determine which part of a large code-base handles a particular job. Say, if I want to know which part of code does the text rendering and layout in a Word Processor.

An advice often given by people is to step through the program using gdb.

So I tried opening a file on my word processor (which was compiled with debugging flags) and getting a backtrace but strangely, all I have obtained are a few ordinary function calls none of which relate to opening a file.

This was what I obtained on executing gdb /usr/local/bin/abiword

(gdb) bt
0  0xffffe424 in __kernel_vsyscall ()
1  0xb63b472b in poll () from /lib/libc.so.6
2  0xb66256eb in g_poll () from /usr/lib/libglib-2.0.so.0
3  0xb6616db6 in ?? () from /usr/lib/libglib-2.0.so.0
4  0xb66174bb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
5  0xb6d6668d in gtk_main () from /usr/lib/libgtk-3.so.0
6  0xb7c04a4d in AP_UnixApp::main (szAppName=0x8048970 "abiword", argc=1, 
    argv=0xbffff704) at ap_UnixApp.cpp:1332
7  0x080488a3 in main (argc=1, argv=0xbffff704)
    at ../src/wp/main/gtk/UnixMain.cpp:30

Please suggest how gdb can be used for such a purpose. Sorry if my question sounds too noobish but I am really at a loss of words for such a task, so google isn’t helping either. 😐

Answer 1

An advice often given by people is to step through the program using gdb.

This is the worst possible advice, when dealing with something as complicated as a word processor (WP for short).

What you want to do instead is run ldd on the binary, or look at /proc/<pid>/maps for a running WP, and see which shared libraries it uses.

Then read about these libraries. One of them likely has to do with text rendering. It very likely also comes with a set of examples.

Build that library, build the examples, modify them to do something else.

Now you are ready to answer questions like “how does this WP use that library” by setting GDB breakpoints on the library entry points, and examining which parts of the WP are calling into them, and with which parameters.

Repeat for other libraries, and you’ll eventually build a picture of how things fit together.

So I tried opening a file on my word processor (which was compiled with debugging flags) and getting a backtrace but strangely, all I have obtained are a few ordinary function calls none of which relate to opening a file.

In GDB, do this: catch syscall open. Now try opening a file, and you’ll find out exactly which part of the WP is responsible for that.

EDIT:

“catch syscall open” catches all the “open” system calls, which are a lot

Yes. But there shouldn’t be that many opens after the WP has started. So do the catch after you have WP on the screen, and just before doing the File->Open menu operation.

Is there a way to specify the name of the file along with catch syscall open?

Yes, you can make the catch conditional. The details of the condition are OS-specific. Looks like you are using i686-linux with VDSO. For that combination, the following should do the trick:

(gdb) catch syscall open
Catchpoint 1 (syscall 'open' [5])

(gdb) cond 1 ((char*)$ebx)[0] == '/' && ((char*)$ebx)[1] == 'h' \
           && ((char*)$ebx)[2] =='o' && ((char*)$ebx)[3] == 'm'

Above condition will make the catchpoint stop only when opening files that have "/hom" prefix.

You can add more letters in obvious way.

You could also try this:

(gdb) cond 1 0 == strcmp($ebx, "/home/nav/Doc1.doc")

but this will likely not work before you get to main, and may crash GDB (it crashed mine, which is a bug).