How do I know the * .c and * .h files that were used to create the binary?

Question

I am creating a project that creates several shared libraries and executables. All source files used to create these binaries are in the same / src directory. Therefore, it is not obvious which source files were used to create each of the binary files (there is a many-to-many relationship).

My goal is to write a script that will analyze the set of C files for each binary file and make sure that only the correct functions are called from them.

One option is to try to extract this information from the Makefile. But this does not work very well with the generated files and headers (due to the dependency on Includes).

Another option would be to simply look at call diagrams, but this will get complicated because many functions are called using function pointers.

Any other ideas?

Answer 1

First, you can compile your project using debugging information (gcc -g) and use objdump to get the source files.

 objdump -W <some_compiled_binary> 

The dwarf format should contain the information you are looking for.

  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) < c> DW_AT_producer : (indirect string, offset: 0x5f): GNU C 4.4.3 <10> DW_AT_language : 1 (ANSI C) <11> DW_AT_name : (indirect string, offset: 0x28): test_3.c <15> DW_AT_comp_dir : (indirect string, offset: 0x36): /home/auselen/trials <19> DW_AT_low_pc : 0x82f0 <1d> DW_AT_high_pc : 0x8408 <21> DW_AT_stmt_list : 0x0 

In this example, I compiled the object file from test_3, and it was located in the ... / tests directory. Then, of course, you need to write a script around this to collect the associated source file names.

Answer 2

Here's an idea you need to clarify based on your specific build. Create an assembly, write it using a script (e.g. script log.txt make clean all ). The last (or one of the last) steps should be the linking of object files. (Tip: find cc -o <your_binary_name> ). This line should link all .o files that must have the corresponding .c files in your tree. Then grep these .c files for all included header files.

If you have duplicate names in your .c files in your tree, we need to look at the full path in the linker line or work with the Makefile .

What Mahmoud suggests below should work. If you have a character image, strings <debug_image> | grep <full_path_of_src_directory> strings <debug_image> | grep <full_path_of_src_directory> should provide you with a list of C files.

Answer 3

First you need to separate the debugging symbols from the just compiled binary. check out this question on how to do this: How to generate a gcc debug symbol outside of the build target?

Then you can try to analyze this file yourself. I know how to do this for Visual Studio, but since you are using GCC, I cannot help you.

Answer 4

You can use the unix nm tool. It displays all the characters defined in the object. Therefore you need to:

• Run nm in your binary format and take all undefined characters
• Run ldd in your binary to capture a list of all its dynamic dependencies (.so files that your binary is associated with)
• Run nm in each .so file you found in step 2.

This will give you a complete list of dynamic characters that your binaries use.

Example:

 nm -C --dynamic /bin/ls ....skipping..... 00000000006186d0 A _edata 0000000000618c70 A _end U _exit 0000000000410e34 T _fini 0000000000401d88 T _init U _obstack_begin U _obstack_newchunk U _setjmp U abort U acl_extended_file U bindtextdomain U calloc U clock_gettime U closedir U dcgettext U dirfd 

All characters with capital "U" are used by the ls command.

Answer 5

If your goal is to parse the C source files, you can do this by setting up the GCC compiler. You can use MELT for this purpose (MELT is a high-level domain language for the GCC extension) - using your own analysis passages encoded in MELT inside GCC-, but you must first learn about the mid-level GCC internal representations (Gimple, Tree, .. .).

Setting up the GCC takes several days of operation (mainly because the internal parts of the GCC are quite complex in the details).

Feel free to ask me more about MELT.