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

6.1 extended keyword for GNU C: attribute

GNU C adds an atttribute keyword to declare a special property of a function, variable, or type. What's the use of declaring this particular property? The main purpose is to guide the compiler to perform specific aspects of optimization or code review when compiling the program. For example, we can specify the data boundary alignment of a variable by using a property declaration.

The use of attribute is very simple. When we define a function, variable, or type, we simply add the following property declaration next to their name:

_ _ atttribute__ ((ATTRIBUTE))

It should be noted here: attribute is followed by two pairs of parentheses, can not be convenient to write only one pair, otherwise the compilation may not pass. The ATTRIBUTE in parentheses represents the attribute to be declared. Attribute now supports more than a dozen attributes:

Sectionalignedpackedformatweakaliasnoinlinealways_inline...

Among these properties, aligned and packed are used to explicitly specify the storage boundary alignment of a variable. In general, we define a variable, and the compiler assigns a size to the variable according to the default rule and an address according to the default boundary alignment. Using the atttribute attribute declaration is tantamount to telling the compiler to allocate storage space for this variable according to the boundary address we specified.

Char c2 _ attribute__ ((aligned (8)) = 4 setint global_val _ _ attribute__ ((section (".data")

Some properties may have their own parameters. For example, aligned (8) indicates that the variable is aligned by an 8-byte address, and the parameters are enclosed in parentheses. If the parameter of the attribute is a string, the parameter in parentheses should be enclosed in double quotation marks.

Of course, we can also add multiple attribute descriptions to a variable at the same time. In the definition, the attributes are separated by commas.

Char c2 _ attribute__ ((packed,aligned (4); char c2 _ attribute__ ((packed,aligned (4) = 4 char c2 = 4

In the above example, we add two property declarations to a variable, both of which are placed in two pairs of parentheses in atttribute (()), separated by commas. There is another detail here, that is, the attribute declaration should be next to the variable. There is no problem with the above three definitions, but the following definitions may not pass at compile time.

Char c2 = 4 _ attribute__ ((packed,aligned (4); 6.2 attribute declaration: section

In this tutorial, we will first talk about the property section. Use atttribute to declare a section attribute, the main purpose of which is to put a function or variable into a specified segment, section, when the program is compiled.

Before we explain this function, in order to take care of the students who don't know much about the process of computer compilation and linking, let's talk about the process of compiling and linking programs.

The process of compiling and linking a program

An executable object file, which is mainly composed of code segments, data segments, and BSS segments. The code segment mainly stores the executable instruction code generated by compilation, and the data segment and BSS segment are used to store global variables and uninitialized global variables. Code, data, and BSS segments make up the main parts of an executable file.

In addition to these three segments, there are other segments in the executable. In compiler technical terms, other section will be included, such as read-only segments, symbol tables, and so on. We can use the following readelf command to view the information about each section in an executable file.

$gcc-o a.out hello.c$ readelf-S a.out here are 31 section headers Starting at offset 0x1848:Section Headers: [Nr] Name Type Addr Off Size [0] NULL 00000000 000000 000000 [1] .interp PROGBITS 08048154 000154 000013 [2]. Note.ABI-tag NOTE 08048168 000168 000020 [3]. Note.gnu.build-i NOTE 08048188 000188 000024 [4 ] .gnu.hash GNU_HASH 080481ac 0001ac 000020 [5] .dynsym DYNSYM 080481cc 0001cc 000040 [6] .dynstr STRTAB 0804820c 00020c 000045 [7] .gnu.version VERSYM 08048252 000252 000008 [8] .gnu.version _ r VERNEED 0804825c 00025c 000020 [9] .rel.dyn REL 0804827c 00027c 000008 [10] .rel.plt REL 08048284 000284 000008 [11] .init PROGBITS 0804828c 00028c 000023 [13] .plt.got PROGBITS 080482d0 0002d0 000008 [14] .text PROGBITS 080482e0 0002e0 000172 [15] .fini PROGBITS 08048454 000454 000014 [16] .rodata PROGBITS 08048468 000468 000008 [17] .eh _ frame_hdr PROGBITS 08048470 000470 00002c [18] .eh _ frame PROGBITS 0804849c 00049c 0000c0 [19] .init _ array INIT_ARRAY 08049f08 000f08 000004 [20] .fini _ array FINI_ARRAY 08049f0c 000f0c 000004 [21] .jcr PROGBITS 08049f10 000f10 000004 [22] .dynamic DYNAMIC 08049f14 000f14 0000e8 [23] .got PROGBITS 08049ffc 000ffc 000004 [24] .got.plt PROGBITS 0804a000 001000 000010 [25] .data PROGBITS 0804a020 001020 00004c [26] .bss NOBITS 0804a06c 00106c 000004 [27] .comm ent PROGBITS 00000000 00106c 000034 [28] .shstrtab STRTAB 00000000 00173d 00010a [29] .symtab SYMTAB 00000000 0010a0 000470 [30] .strtab STRTAB 00000000 001510 00022d

In the Linux environment, use GCC to compile and generate an executable file a.out. Using the readelf command above, you can view the basic information of each section in this executable file, such as size, starting address, and so on. Among these section, .text section is what we often call a code segment, .data section is a data segment, and .bss section is a BSS segment.

We know that when a piece of source code is compiled into an executable file, functions and variables are placed in different sections. The general default rules are as follows.

Section composition

Code snippet (.text) function definition, program statement

Global variables initialized by data segment (.data), static local variables initialized

BSS segment (.bss) uninitialized global variables, uninitialized static local variables

For example, in the following program, we define a function, a global variable, and an uninitialized global variable.

/ / hello.cint global_val = 8 int uninit_val;void print_star (void) {printf ("*\ n");} int main (void) {print_star (); return 0;}

Next, we compile the program using GCC and look at the symbol table and section header table information of the generated executable a.out.

$gcc-o a.out hello.c$ readelf-s a.out$ readelf-S a.out symbol table information: Num: Value Size Type Bind Vis Ndx Name37: 00000000 0 FILE LOCAL DEFAULT ABS hello.c48: 0804a024 4 OBJECT GLOBAL DEFAULT 26 uninit_val51: 0804a014 0 NOTYPE WEAK DEFAULT 25 data_start52: 0804a020 0 NOTYPE GLOBAL DEFAULT 25 _ edata53: 080484b4 0 FUNC GLOBAL DEFAULT 15 _ fini54: 0804a01c 4 OBJECT GLOBAL DEFAULT 25 global_ Val55: 0804a014 0 NOTYPE GLOBAL DEFAULT 25 _ _ data_start61: 08048450 93 FUNC GLOBAL DEFAULT 14 _ _ libc_csu_init62: 0804a028 0 NOTYPE GLOBAL DEFAULT 26 _ end63: 08048310 0 FUNC GLOBAL DEFAULT 14 _ start64: 080484c8 4 OBJECT GLOBAL DEFAULT 16 _ fp_hw65: 0804840b 25 FUNC GLOBAL DEFAULT 14 print_star66: 0804a020 0 NOTYPE GLOBAL DEFAULT 26 _ _ bss_start67: 08048424 36 FUNC GLOBAL DEFAULT 14 main71: 080482a8 0 FUNC GLOBAL DEFAULT 11 _ initsection header information: Section Headers: [Nr] Name Type Addr Off Size [14] .text PROGBITS 08048310 000310 0001a2 [25] .data PROGBITS 0804a014 001014 00000c [26] .BSS NOBITS 0804a020 001020 000008 [27] .comment PROGBITS 00000000001020000034 [28] .shstrtab STRTAB 0000000000172200010a [29] .symtab SYMTAB 00000000001054 000480 [30] .strtab STRTAB 00000000 0014d4 00024e

Through the symbol table and section table section header table information, we can see that the function print_star is placed in the .text section in the executable file, that is, the code segment; the initialized global variable global_val is placed in the a.out .data section, that is, the data segment; and the uninitialized global variable uninit_val is placed in the. bss section, that is, the BSS section.

When compiling a program, the compiler compiles source files one by one into target files in terms of source files. In the process of compilation, the compiler will follow this default rule, put functions and variables in different section, and finally form an object file for each section. At the end of the compilation process, the linker then assembles and relocates the target files to generate an executable file.

How does the linker assemble each object file into an executable file? Very simple, the linker will first integrate the code segments of each object file into one large code segment; integrate the data segments in each object file into one large data segment; then merge the merged new code segments and data segments into a file; finally, after repositioning, it will generate an executable file that can be run.

Now there is another question: how does the linker discharge the order of each section in the process of assembling different section segments into an executable file? For example, code snippet, data segment, BSS segment, symbol table, etc., who put it first? Who put it in the back?

During the linking process, the linker assembles different section into an executable file according to the discharge order of each section specified in the link script. Generally in Ubuntu and other PC version of the system, the system will have a default link script, do not need to worry about programmers.

$ld-verbose

Using the above command, we can see the default link script that the linker uses when compiling the current program. In embedded systems, because it is cross-compiled, the software source code usually comes with a linked script. For example, under the root directory of the U-boot source code, you will see a u-boot.lds file, which is the link script to be used by the linker when compiling U-boot. In the Linux kernel, there is also a link script like vmlinux.lds.

Attribute section programming example

In GNU C, we can explicitly specify a function or variable through the section property of attribute, which is placed in the specified section at compile time. We know from the above program that uninitialized global variables are placed in .data section, that is, in the BSS section. Now we can put this uninitialized global variable into the data segment .data through the section property.

Int global_val = 8 return int uninit_val _ _ attribute__ ((section (".data")); int main (void) {return 0;}

Looking at the symbol table from the readelf command above, we can see that the uninitialized global variable uninit_val, declared by the attribute ((section (".data")) attribute, is placed by the compiler in the data segment .data section.

Analysis of mirror self-copy in the process of U-boot startup

With the section attribute, we can then try to analyze how U-boot loads its own code into RAM during startup.

Those who engage in embedded systems all know that the main purpose of UMub boot is to load the Linux kernel image into memory, pass boot parameters to the kernel, and then boot the Linux operating system.

U-boot is generally stored on Nor flash or NAND Flash. Whether booted from Nor Flash or Nand Flash, U-boot itself loads its own code into memory from Flash storage media during startup, then relocates and jumps to memory RAM to execute. This function is generally called "bootstrap". Doesn't it feel good? The process of U-boot relocation will not be carried out today. Interested students can take a look at my embedded video tutorial "C language embedded Linux Advanced programming" issue 3: program compilation, linking and running. Our main task today is to see how U-boot copies itself, or how it copies its own code from Flash to memory RAM.

One of the main questions in the process of copying its own code is, how does U-boot recognize its own code? How do you know where to copy the code? How do you know where to stop the copy? At this point we have to talk about a zero-length array in the U-boot source code.

Char _ _ image_copy_start [0] _ attribute__ ((section (". _ image_copy_start")); char _ image_copy_end [0] _ attribute__ ((section (". _ image_copy_end")

These two lines of code are defined in the arch/arm/lib/section.c file in U-boot-2016.09. In other versions, the path may be different or undefined. In order to analyze this feature, it is recommended that you download the U-boot source code of this version of U-boot-2016.09.

The purpose of these two lines of code is to define a zero-length array and tell the compiler to put it in the .imagecopystart and .image _ copy_end section, respectively.

When linking each target file, the linker assembles each section into an executable file according to the order of each section in the link script. U-boot 's link script u-boot.lds is under the root directory of the U-boot source code.

OUTPUT_FORMAT ("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH (arm) ENTRY (_ start) SECTIONS {. = 0x0000000000;. = ALIGN (4); .text: {* (. _ image_copy_start) * (.vectors) arch/arm/cpu/armv7/start.o (.text *) * (.text *)}. = ALIGN (4); .data: {* (.data *)}. = ALIGN (4); .image _ copy_end: {* (. _ image_copy_end)} .end: {* (. _ end)} _ image_binary_end =. = ALIGN (4096); .mmutable: {* (.mmutable)} .bss _ start _ rel_dyn_start (OVERLAY): {KEEP (* (. _ bss_start)); _ _ bss_base =.;} .bss _ bss_base (OVERLAY): {* (.bss *). = ALIGN (4); _ _ bss_limit =.;} .BSS _ end _ _ bss_limit (OVERLAY): {KEEP (* (. _ bss_end));}}

Through the link script, we can see that the two section, image_copy_start and image_copy_end, are placed in front of the code snippet .text and after the data segment .data, respectively, as the start and end address of the U-boot copy of its own code. In these two section, we put no other variables except for two zero-length arrays. From the previous study, we know that zero-length arrays do not take up storage space, so the two zero-length arrays defined above actually represent the start and end addresses of the U-boot images to copy their own images.

Char _ _ image_copy_start [0] _ attribute__ ((section (". _ image_copy_start")); char _ image_copy_end [0] _ attribute__ ((section (". _ image_copy_end")

No matter whether U-boot 's own image is stored on Nor Flash or Nand Flash, as long as we know these two addresses, we can directly call the relevant code copy.

Then in arch/arm/lib/relocate.S, ENTRY (relocate_code) assembly code mainly completes the function of code copy.

ENTRY (relocate_code) ldr R1, = _ _ image_copy_start / * R1

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.