Program structure analysis and understanding

Recently, I reviewed the basic tools for embedded development and some basic structures of programs. I gradually got rid of the process of mechanical learning. In the process of learning, I realized that I still need to learn a lot. I remember that when I was studying DSP in college, the task was to complete the FFT transformation of 2048-point data. I remember that the program (C language) was completed very quickly, but the correct effect could not be achieved in the later stage. Finally, I found that there was a problem with the CMD (configuration) file. Through the teacher's explanation and my own learning, I learned the basic structure of the program, that is, the so-called code segment, data segment, etc., as well as specific memory management issues. These are the basic functions of the linker. From then on, I also knew some characteristics of the program.

 

1. Composition of target files

A binary file is made up of a series of segments, and of course there are some symbols, memory allocation, etc. The link text can actually give you a rough idea of ​​the program's composition. The same segments of each target file are combined to achieve the link of the executable program. Of course, the specific linking methods and principles are designed by the tool. For example, the linking order follows the input order, etc.

 

I remember that in the process of porting u-boot to TQ2440, I had modified the link text, that is, the u-boot.lds file. At that time, I added a function about nand flash operation. In order to ensure that the added function would not be placed before the startup code during the link process and cause problems with the chip startup, I deliberately modified the link order of the program to ensure that the link document was correctly linked.

1. [root@Gong-Computer u-boot-2010.06]# vi arch/arm/cpu/arm920t/u-boot.lds

2. . = ALIGN(4);

3. .text:

4. {

5. arch/arm/cpu/arm920t/start.o (.text)

6. board/samsung/smdk2440/lowlevel_init.o (.text)

7. board/samsung/smdk2440/nand_read.o (.text)

8. *(.text)

9. }

The basic contents of the binary file mainly include several segments. Of course, some other conditions are required. In the linking process, it seems that some C language running environment is also needed, which is mainly used to control the startup and shutdown of the program. These are all implemented by crt* (C RunTime) target files. These target files are not often seen in our program design. If you analyze the compilation process of u-boot, you will find that these target files do exist.

Link text makes file linking more convenient and practical. Therefore, it is very necessary to understand the most basic paragraphs of the target.

A few points to note:

1. Static variables, whether local or global, are in the data segment, unlike local variables in the stack. When the stack is popped, the contents are released, and the static variables will not change. However, local static variables can only be accessed by the function that defines the variable, and cannot be accessed by other functions.

2. If global variables and static variables are initialized to 0 or not initialized, the variable is allocated to .bss (uninitialized part). Only when global variables and static variables are initialized to non-zero values ​​will they be allocated to the .data segment.

3. If global variables and static variables are not initialized, they will generally default to 0. This is why these two numbers are still in the .bss section even if they are initialized to 0. Therefore, you need to pay attention to the values ​​of global variables and static variables when they are not initialized, but there is no such feature for local variables. If they are not initialized, a random value will appear.

The above conclusions can be manually tested through code.

2. Program structure in Linux

In Linux, each process has a 4G virtual space, of which the first 3G is the user space and the last 1G is the kernel space. The 4G space is independent of each process. However, the area allocation of these memory spaces is indeed the same, and the starting address of each area is also fixed. The structure of a Linux program is as follows:

Since the starting address of each segment is fixed, it is convenient to map the virtual address to the physical address, which facilitates the loading of the program, especially the implementation of shared libraries.

3. Stack and Heap

In fact, I had a big misunderstanding of these two concepts at the beginning. I didn't understand the relationship between them. I always understood the stack as a heap and a stack. In fact, the stack refers to the stack. Once you understand this, it's easy to understand the difference between the two. The stack can actually be considered a data structure with a typical first-in, last-out feature.

Generally speaking, the stack grows in reverse, that is, from high address to low address, but there are other growth modes, such as ARM has 4 different growth modes, so the growth direction of the stack can only be determined by the CPU, and the stacks of different CPUs may be different. The stack is mainly used to implement function calls.

The heap is generally located above the bass segment, and is mainly used to implement dynamic memory allocation and release. In C language, it is mainly implemented through malloc/free functions, and in C++, it is mainly implemented through new/delete. However, this block of memory is usually continuously allocated and released and meets the basic alignment form, which leads to memory fragmentation and reduces the access rate. At the same time, because of the problems of zero space application in this area and the pointer is still valid after release, the pointer is usually pointed to NULL after release.