Linux program analysis tools: ldd and nm

Linux program analysis tools: ldd and nm

Ldd and nm are two very practical program analysis tools in Linux. Among them, ldd is used to analyze the dynamic link library that the program depends on when running, and nm is used to view the symbol table information in the specified program.

1 ldd

Format: ldd [options] file

Function: lists the shared libraries required to run a file.

Parameters:

-D. Execute the relocation and report all the missing functions.

-R migrates functions and objects and reports any missing functions or objects.

First, ldd is not an executable program, but a shell script. Ldd can display the dependency of executable modules by setting a series of environment variables, such as LD_TRACE_LOADED_OBJECTS, LD_WARN, LD_BIND_NOW, LD_LIBRARY_VERSION, and LD_VERBOSE. When the LD_TRACE_LOADED_OBJECTS environment variable is not empty, when any executable program is running, it only displays the dependency of the module, and the program is not actually executed. Or you can test it on the shell terminal as follows:

(1) export LD_TRACE_LOADED_OBJECTS = 1

(2) execute any program, such as ls, and check the running result of the program.

Ldd displays the dependency working principle of the executable module, its essence is achieved through the ld-linux.so (the loader of the elf dynamic library. We know that the ld-linux.so module will work prior to the executable module program and gain control, so when those environment variables above are set, the ld-linux.so selects the dependency that shows the executable module.

You can actually directly execute ld-linux.so modules such as:/lib/ld-linux.so.2 -- list program (which is equivalent to ldd program) ldd command usage method (from ldd -- help)

Select an application to be tested. The Code is as follows:

 

//@file tooltest.c//@brief resource sharing between parent-process and sub-process#include <stdio.h>#include <stdlib.h>#include <unistd.h>int global = 1; /*global variable, stored at data section*/int main(void){    pid_t pid;//to store pid value    int   stack = 1;//local variable, stored at stack    int  *heap;//pointer to a heap variable    heap = (int *)malloc(sizeof(int));    *heap = 2;//set the heap value to 2    pid = fork();//create a new process    if (pid < 0)    {        //error        perror("fail to fork");        exit(-1);    }    else if (pid == 0)    {        //sub-process, change values        global++;        stack++;        (*heap)++;        //print all values        printf("In sub-process, global: %d, stack: %d, heap: %d\n", global, stack, *heap);        exit(0);    }    else    {        //parent process        sleep(2);//sleep 2 secends to make sure the sub-process runs first        printf("In parent-process, global: %d, stack: %d, heap: %d\n", global, stack, *heap);    }    return 0;}

 

Then, we compile and run the ldd command:

xiaomanon@xiaomanon-machine:~/Documents/c_code$ ldd tooltest    linux-gate.so.1 =>  (0xb775b000)    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7595000)    /lib/ld-linux.so.2 (0xb775c000)

We can divide the output result of ldd into three columns:

■ Column 1: What database does the program depend on?

■ Column 2: name of the library provided by the system corresponding to the library required by the program

■ Column 3: Start address of dependent Library Loading

Through the above information, we can summarize the following usage:

(1) By comparing the first and second columns, we can know whether the dynamic link library required by the program is matched with the actual provided by the system.

(2) Through the third column, we can know the starting position of the symbols in the current dynamic link library in the process address space.

2 nm

Format: nm [options] file

Function: Lists All symbols in a file.

Parameters:

-C converts a symbol to a user-level name.

-S: when used in the. a file, that is, the static library, the output maps the symbol name to the index of the module or member name that defines the symbol.

-U: displays symbols not defined in file or undefined symbols.

-L display the line number of each symbol or define the definition of the symbol

The output result of running the nm command is as follows:

 

xiaomanon@xiaomanon-machine:~/Documents/c_code$ nm tooltest0804a038 B __bss_start0804a038 b completed.65900804a02c D __data_start0804a02c W data_start08048450 t deregister_tm_clones080484c0 t __do_global_dtors_aux08049f0c t __do_global_dtors_aux_fini_array_entry0804a030 D __dso_handle08049f14 d _DYNAMIC0804a038 D _edata0804a03c B _end         U exit@@GLIBC_2.008048674 T _fini         U fork@@GLIBC_2.008048688 R _fp_hw080484e0 t frame_dummy08049f08 t __frame_dummy_init_array_entry080487e0 r __FRAME_END__0804a034 D global0804a000 d _GLOBAL_OFFSET_TABLE_         w __gmon_start__08048354 T _init08049f0c t __init_array_end08049f08 t __init_array_start0804868c R _IO_stdin_used         w _ITM_deregisterTMCloneTable         w _ITM_registerTMCloneTable08049f10 d __JCR_END__08049f10 d __JCR_LIST__         w _Jv_RegisterClasses08048670 T __libc_csu_fini08048600 T __libc_csu_init         U __libc_start_main@@GLIBC_2.00804850d T main         U malloc@@GLIBC_2.0         U perror@@GLIBC_2.0         U printf@@GLIBC_2.008048480 t register_tm_clones         U sleep@@GLIBC_2.008048410 T _start0804a038 D __TMC_END__08048440 T __x86.get_pc_thunk.bx

 

The above is all the symbols in the tooltest program. First, we will introduce the format of the output content above:

■ Column 1: the address of the current symbol.

■ Column 2: Type of the current symbol (for details about the type, refer to man nm on the manual page ).

■ Column 3: name of the current symbol.

Using nm mainly helps in the following aspects:

(1) determine whether a specified symbol exists in the specified program. The commonly used method is: nm-C program | grep symbol.

(2) solve the undefined reference error and multiple definition error during program compilation.

(3) view the address of a symbol and its approximate location in the process space (. bss,. data,. text segments, which can be determined by the type of the second column ).

Description of some symbol types

A: The value of this symbol is absolute and cannot be changed in the future link process. Such symbolic values often appear in the interrupt vector table. For example, symbols are used to represent the position of each interrupt vector function in the interrupt vector table.

B: The value of this symbol appears in the non-initialized data segment (. bss. For example, define Global static int test in a file. The test type is B and is located in the bss section. The value indicates the offset of the symbol in the bss segment. Generally, bss segments are allocated in RAM.

C: The symbol is common. Common symbol is an uninitialized data segment. This symbol is not included in a common section. It is allocated only during the link process. The value of the symbol indicates the number of bytes required by the symbol. For example, if the int test is defined in a c file and the symbol is referenced elsewhere, the type of the symbol is C. Otherwise, its type is B.

D: The symbol is located in the initialized data segment. Generally, it is allocated to. data section. For example, if the global int baud_table [5] = {9600,192 00, 38400,576 00, 115200} is defined, it is allocated to the initialization data segment.

G: The symbol is also located in the initialized data segment. It is mainly used for improving the access to small data objects by small objects.

I: This symbol is an indirect reference to another symbol.

N: This is a debugging symbol.

R: This symbol is located in the read-only data segment. For example, if the global const int test [] = {123,123} is defined, test is the symbol of a read-only data zone. Note that in cygwin, if gcc is used to directly compile the file into MZ format, test corresponds to _ test in the source file, and its symbolic type is D, that is, initializing the data segment. But if you use a cross-compilation tool like m6812-elf-gcc, the test in the source file corresponds to the test of the target file, that is, there is no underline added, and its symbolic type is R. Generally, it is located in the rodata section. It is worth noting that if a function defines const char * test = "abc", const char test_int = 3. No symbolic information is obtained when nm is used, but the string "abc" is allocated in read-only memory. test Is In The rodata section and the size is 4.

S: The symbol is located in a non-initialized data segment for small objects.

T: The symbol is located in the text section of the Code segment.

U: The symbol is undefined in the current file, that is, the definition of the symbol is in another file. For example, if the current file calls a function defined in another file, the called function is currently undefined, but the type of the function defined in the file is T. But for a global variable, in the file defining it, its symbolic type is C. In the file using it, its type is U.

V: this symbol is a weak object.

W: The symbol is a weak symbol that has not been specifically tagged as a weak object symbol.

-: This symbol is the stabs symbol in the. out format file.

? : This symbol type is not defined.

Introduction to Linux program analysis tools-ldd, nm

This article permanently updates the link address: