Tips for studying code bases?

[halfmaddad]

Hi Everyone

I have tried very hard to study various code bases in the past but had limited success. I have used brute force and printed all the source code and tried to read through everything and had limited success.

I have used ctags and cflow.

cflow gives results like this:

main() <int main (int argc, char **argv) at cobc.c:3669>:
memset()
cobc_sig_handler() <void COB_A_NORETURN cobc_sig_handler (int sig)
at cobc.c:1478>:
raise()
kill()
getpid()
exit()
continues on....

It shows that raise, kill, getpid etc are callable from cobc_sig_handler but it can't tell which path of execution it will take. Is there another tool that would list only the functions actually called?

I thought that I could look at each function cflow listed(or another tool's result's) and then use ctags to view the argument definitions.

Does this sound like a logical way to study the code base ? If not could you recommend some other techniques ?

Thanks for reading

 

[halfmaddad]

Hi Jorgen

I would like to be able to modify the source

Thanks

 

[Jorgen Grahn]

Hi Jorgen

I would like to be able to modify the source

(Please quote some context.)

I assume you mean "I want/need to modify the program", perhaps because
it's your job.

I think I would
- Run the program, as much as possible.
- Run it under strace (or whatever your OS has), run it with profiling
enabled, run it with printf debugging added ... to get a feeling
for the runtime behavior.
- Write down the data structures and how they're connected (e.g. UML
class diagrams).
- Read, run, think, read again ...

And I would focus on the parts I needed to change. You cannot learn
every corner of the source code at oncel; that just wastes your
energy.

/Jorgen

 

[Stefan Ram]

I have used brute force and printed all the source code and
tried to read through everything and had limited success.

It is an excellent idea to learn by reading code instead of
reading books! Best way is to combine both.

Studying a program is best done the active way:

- Take the nethack source code and add new object types,
new types of monsters, new rules.

Once you have gotten better, you can go ahead and contribute
to an open-source project of your liking.

 

[halfmaddad]

Hi Rich, Hello Jorgen, Hi Stefan

Thanks very much for your feedback !

What so you think of this approach as well as the ones you have provided:

Run the code through cflow -r (so it lists all the functions that called that function)
create a ctag file of the c code
Load the cflow results and the c files in vim with ctag extension
click on the c flow results to find the function definitions.
add printf statements to all the functions
run the code to find the path of execution
using ctags again go back and look up the arguments definition with what appear to be the most important calls

Does this sound logical assuming the code base is 20K to 40K source lines of code?

 

[Jorgen Grahn]

Hi Rich, Hello Jorgen, Hi Stefan

Thanks very much for your feedback !

What so you think of this approach as well as the ones you have provided:

Run the code through cflow -r (so it lists all the functions that called that function)
create a ctag file of the c code

TAGS is good; it's the first thing I set up. Never used cflow -- I've
only seen one guy do it once. Perhaps it's good.

Load the cflow results and the c files in vim with ctag extension
click on the c flow results to find the function definitions.
add printf statements to all the functions

Not all of them, IMO -- do it when needed. If you want to see who
calls who how often, running gprof (or some other profiler) is a good
idea.

run the code to find the path of execution
using ctags again go back and look up the arguments definition with what appear to be the most important calls

Does this sound logical assuming the code base is 20K to 40K source lines of code?

Not too bad, but to repeat what I wrote earlier: I think it's a trap
to try to understand all at once.

I've maintained other people's weird code. I find after a year or two
there are big uncharted areas -- those that are either very stable or
not very important. But you will know some other parts very well!

/Jorgen

 

[halfmaddad]

Hi Jorgen

I didn't know about gprof, this looks really neat. The profiling information might also give hints about what functions are important to learn and to mark with printf statements.

Thanks again