Shulou(Shulou.com)06/03 Report--

Today let's take a look at the assistive tools in development, so what is the development environment? In our impression, the development environment refers to the environment in which code is written. In fact, the development environment consists of three parts: the build environment, the debugging environment, and the test environment. The build environment refers to the code writing, program compilation and version control, etc.; the debugging environment refers to the set of auxiliary tools used to locate the problem; the test environment refers to the verification of whether the target program meets the explicit and invisible needs of the user. Explicit requirements refer to customer requirements, while implicit requirements refer to requirements that users do not have but must have. For example, an application can run on a win7 system, and it should also be able to run on a win10 system.

In embedded development, we generally spend only 20% of our time on coding and target construction throughout the project, and the remaining 80% of the time is suitable for testing, debugging, and bug fixes. So how can we improve the efficiency of development? If you want to do a good job, you must first sharpen its tools, and we can use some tools to improve the efficiency of development. GNU provides an auxiliary toolset (Binutils) for the GCC compiler at http://www.gnu.org/software/binutils/; some of these tools are described below

Tool name

Brief introduction of function

Add2line

Convert the code address to the corresponding program boot

Strip

Propose debugging information in executable programs

Ar

Package the target file into a static library

Nm

List the symbols and corresponding addresses in the target file

Objdump

View segment information and disassembly

Size

View the segment size in the target file

Strings

View strings in the target file

Let's introduce these tools one by one.

1. Addr2line: convert the copy to the corresponding file name and line number, which is often used to analyze and locate memory access errors. Let's give a sample code for analysis and illustration.

Func.c source code

# include int* glosspointertint main () {* g_pointer = (int) "D.T.Software"; return 0;}

Test.c source code

# include int g_global = 0tint g_test = 1bter int* gallepointerextern void func (); int main (int argc, char * argv []) {printf ("& g_global =% p\ n", & g_global); printf (& g_test =% p\ n ", & g_test); printf (" & g_pointer =% p\ n ", & g_pointer); printf (" g_pointer =% p\ n ", g_pointer) Printf (& func =% p\ n ", & func); printf (" & main =% p\ n ", & main); func (); return 0;}

Let's analyze this code first. We directly defined the pointer to the int type earlier, but did not refer to it as NULL. At this point, g_pointer has already pointed to the 0 address of memory, and manipulated the 0 address in the main function, which will certainly cause a segment error. Let's take a look at the results of the compilation.

We see that g_pointer is a null pointer, followed by a segment error. If this is a large project with hundreds of thousands of lines of code, I believe it will be very difficult for us to locate the problem. So how do we locate the problem at this time? Here comes the addr2line tool. The steps are as follows: 1, open the core dump option: ulimit-c unlimited;2, run the program, and produce the core file when the program crashes, and execute the test case that causes the program to crash; 3, read the core file and get the value of the IP register: dmesg core;4, use add2line to locate the code line: addr2line address-f-e test.out. As follows

We see that the core file has been generated at this time. Let's dmesg core to see what the value of the IP register is.

We see that the value of the IP register is 0x080484b8, and then we can use the addr2line tool to locate the problem directly.

2. Strip: used to eliminate the debugging information in the program file and reduce the size of the target program. Generally speaking, debugging information needs to be removed before the program is released, and too much debugging information may affect the execution efficiency of the program. Let's see how it works, strip test.out.

We see that after culling, its file size has been almost halved. Points for attention when using it: 1, almost all debugging tools rely on the debugging information in the target file, and the use of debugging information can quickly locate the problem; 2, use the-g option to generate debugging information when using gcc compiler, and consider whether to use strip to eliminate debugging information when releasing the program. Then if you want to use the core file to locate the problem, you can't, because the core file can only locate the debug version.

We can see that it can't locate the problem.

3. Ar: package the target file, ar crs libname.a x.oy.o; extract the target file, ar x libname.a. Come down and see how it works.

We can send third-party library files directly to others by using packaging and decompression commands. If we only have third-party library files and want to use one of the .o files, we can use the extract command to use one of the files.

4. Nm: used to list identifiers (variable name, function name) in the target file. The output result consists of three parts {address, segment and identifier}. Examples are as follows

The segment identification is described as follows

Let's look at the identifiers in the func.o and test.o files

We see that func is located in the code snippet in the func.o file, and its offset is 0. There is no link here, so all the relative addresses are displayed. G_pointer is an undefined identifier with a relative offset of 4. Let's take a look at the address after the link.

We see that the linked address is the absolute address.

5. Objdump: the disassembly target asks Ah Jin to view the mapping from assembly to source code. Objdump-d func.o or objdump-S func.o. View the details in the target file, objdump-h test.out.

The output of objdump-h is as follows

The output information is as follows

Let's take a look at the details of the linked test.out.

We see that its VMA is the same as LMA, that is, the virtual address is the same as the load address. When running the program, the first step is to allocate virtual memory for the executable file, then get the relative location through file off, and then load the target address to the virtual memory by copying the segment information. Finally, there is the execution of the program.

6. Size is used to get all the segment sizes in the target file, and size test.out;strings is used to get all the string constants in the target file. As follows

So what's the point of getting their sizes and strings? In embedded development, resources are often very limited, so we must strictly control the size of the target file to prevent unexpected errors beyond its limits; if we want to get some specific strings, we do not have to look at the code, we can see all the strings directly with strings, in order to improve development efficiency.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.