Section 7 load executable programs

Week 7 executable program loading by 20135217 Sun Xiaobo main content of this week:

1. How the executable program is obtained and the target file format of the executable program
2. Dynamic Library & Dynamic Link Library
3. Execution Process of sys_exec function called by the System

How can the format executable programs of preprocessing, compilation, linking, and target files be obtained?

Preprocessing: gcc-e-o hello. CPP hello. c-M32 // contains the include file. Macro replacement: gcc-x CPP-output-s hello. s-O hello. CPP-M32 // call CCL by GCC-s and compile it into assembly code: gcc-x Assembler-C hello. s-O hello. o; // The GCC-C calls the as to obtain the binary file, which cannot be chained to: gcc-O hello. o; gcc-O // call LD to form the target Executable File

/* Shared libraries are used for elf files. If static compilation is performed, all the dependent files are stored in the Program */static Compilation: gcc-O hello. static hello. o-M32-static

Target File Format: elf

The development process of executable file formats:

Elf: executable & connectable file format, which is a standard file format.

Abi: Binary interface of the application. The target file is already in binary-compatible format.

Three main target files in elf

• Relocated files: Save code and appropriate data to create an executable file or shared file together with other object files. It is mainly a. o file.
• Executable File: stores a program for execution, and points out how exec (ba_ OS) creates a program process image, how to load the file, and where to start execution.
• Shared File: the code and data are stored in the following two linker links. One is the link compiler, which can create other object files with other relocated and shared files; the other is the dynamic linker, which combines an executable file and other shared files to create a process image. It is mainly a. So file.

File Format

Object files participate in program join (create a file) and program execution (run a file)

View the ELF File Header

$ readelf -h hello

When a process image is created or added, the system theoretically copies a file segment to a virtual memory segment.

Static elf executable file and process address space

Entry Point address: the entry address is 0x8048x00 (not unique)

The reason is that the 32-bit x86 system has 4G process address space (the first 1G is used by the kernel; the later 3G user mode is accessible) when an elf executable file is to be loaded into the memory, the code segment and data segment are first loaded (from the 0x8048000 position by default ). When loading, all the preceding header information in ELF format is different in size. The actual program entry can be determined based on the header size. When you start a process that has just loaded executable files, you can start execution from this location.

Generally, static links place all code in the same code segment. A dynamically linked process has multiple code segments.

Execution Environment for executable programs, shared libraries, and dynamically linked executable programs

Command line parameters and shell environment. Generally, we execute the shell environment of a program. Our experiment is called directly using the execve system.

Shell itself does not limit the number of command line parameters. The number of command line parameters is limited by the command itself.

Int main (INT argc, char * argv []) int main (INT argc, char * argv [], char * envp []) // user input parameters 1, 2, and shell Environment Variables

Shell will call execve to pass the command line parameters and environment parameters to the main function of the executable program.

int execve(const char *filename,char *const argv[],char *const envp[]);

The exec * library function is an execve encapsulation routine.

# Include <stdio. h> # include <stdlib. h> # include <unistd. h> int main (INT argc, char * argv []) {int PID;/* fork another process */PID = fork (); // create a new sub-process if (PID <0) {/* error occurred */fprintf (stderr, "fork failed! "); // If fork fails, you cannot execute the new program exit (-1);} else if (pid = 0) // fork a sub-process {/* child process */execlp ("/bin/ls", "ls", null ); // load the program to be executed according to the parameters passed in through the command line} else {/* parent process * // * parent will wait for the child to complete */Wait (null ); printf ("child complete! "); // The parent process waits for the child process to load and exit (0 );}}

How do command line parameters and environment variables enter the stack of the new program?

When creating a new user State stack, the content of the command line and environment variable parameters is actually transmitted to the kernel processing function called by the system through a pointer, the function is copied to the executable program during New stack initialization. Function call parameters are passed before System Call parameters are passed.

Examples of Dynamic Link and dynamic link during loading application examples of shared library and dynamic load sharing library related sample code

Dynamic Links are divided into dynamic links and runtime dynamic links during executable program loading. The following Code demonstrates these two dynamic links.

• Shared Library

  /* Prepare. so file */shlibexample. H (1.3 kb)-interface of shared lib exampleshlibexample. C (1.2 kb)-Implement of shared lib example/* compiled into libshlibexample. so file */$ gcc-shared shlibexample. c-o libshlibexample. so-M32/* use the library file (the function can be called directly because the header file is already included) */sharedlibapi ();

• Dynamic Link Loading

  Dllibexample. H (1.3 kb)-interface of dynamical loading lib exampledllibexample. C (1.3 kb)-Implement of dynamical loading lib example/* compiled into libdllibexample. so file */$ gcc-shared dllibexample. c-o libdllibexample. so-M32/* use library file */void * handle = dlopen ("libdllibexample. so ", rtld_now); // first load int (* func) (void); // declare a function pointer func = dlsym (handle," dynamicalloadinglibapi "); // find the function pointer func () based on the name; // call the declared function

Compile main. Note that only the-l (directory of the interface header file corresponding to the Library) and-l (library name, such as libshlibexample) of shlibexample are provided here. so remove lib and. does not provide information about dllibexample, but indicates-LDL.

$ GCC main. c-o main-L/path/to/Your/Dir-lshlibexample-LDL-M32 $ export LD_LIBRARY_PATH = $ PWD/* Add the current directory to the default path, otherwise, the main cannot find the dependent library file, and you can copy the library file to the default path. */

Analysis of key issues in loading executable programs

Execve and fork are both special system calls.

• Fork is returned twice. The first time it is returned to the parent process for further downward execution, and the second time it is returned to ret_from_fork and then returned to the user State normally.

• Execve runs in the kernel state. The program loaded in execve overwrites the currently executed program. When the system calls the returned program, it returns to the new executable program starting point.

Sys_execve kernel processing process:

For executable files in ELF format, FMT-> load _ binary (bprm); the execution should be load _ elf _ binary. Internally, the parsing part of the ELF file format needs to be read in conjunction with the ELF File Format standard.

How does the Linux Kernel support multiple executable file formats?

Static struct linux_binfmt elf_format // declare a global variable = {. module = this_module ,. load_binary = load_elf_binary, // automatically executed by the observer. load_shlib = load_elf_library ,. core_dump = elf_core_dump ,. min_coredump = elf_exec_pagesize,}; static int _ IIT init_elf_binfmt (void) {n register_binfmt (& elf_format); // register the variable into the kernel linked list, return 0 ;}

Where is the start point of the executable file? How can I run a new program when the execve system call returns to the user State?

Modify the EIP that int 0x80 is pushed into the kernel stack, and use the EIP value in the kernel stack as the starting point of the new program.

Internal processing of sys_execve

• System Call entry:

  return do_execve(getname(filename), argv, envp);

• Go to the do _ execve _ common function.

  Return do_execve_common (filename, argv, envp); file = do_open_exec (filename); // open the executable file to be loaded and load its file header. Bprm-> file = file; bprm-> filename = bprm-> interp = filename-> name; // a struct bprm is created, copy the environment variables and command line parameters to the struct;

• Exec_binprm:

  Ret = search_binary_handler (bprm); // find the handler for this executable file. key code: list_for_each_entry (FMT, & formats, LH ); retval = FMT-> load_binary (bprm); // in this loop, find the code that can parse the current executable file and load it out. // The load_elf_binary function is actually called.

• File Parsing modules

The core task is to map the file to the space of the process. For elf executable files, it is mapped to the address 0x8048000 by default.

Can an executable file requiring Dynamic Link first load the linker lD? (Load _ elf _ interp dynamic link library Dynamic Link file), the starting point of the dynamic linker. If it is a static link, you can directly assign values to the file address entry.

It is found that there are two possibilities at start_thread:

• If it is a static link, elf _ entry points to the header specified in the executable file, that is, the position corresponding to the main function, which is the starting point for new program execution;
• If you need to rely on dynamic links of other dynamic libraries, elf _ entry is the starting point of the dynamic linker. Assign the CPU control to the LD to load the dependent database and complete the dynamic link.

EXPERIMENT -- use GDB to trace and analyze execve system calls kernel processing function sys_execve

The previous operations are the same as those in the previous experiment. In addition to adding the exec function, the Code also compiles hello in makefile. c. Put init and hello in rootfs when generating the root file system. in this experiment, hello is an executable file loaded.

(1) exec function running result:

(2) set the breakpoint to sys_exec

(3) enter the function and find that the do_execve () function is called.

(4) continue to execute the breakpoint at load _ elf _ binary, at this time, call this function to parse the executable file format (the load _ elf _ binary function is inside Do _ execve _ Common. For the call relationship, refer to the above flowchart)

(5) continue to execute the breakpoint at start_thread.

Because it is a static link, elf _ entry points to the header specified in the executable file. Use the po new _ ip command to print the address it points to. The new _ IP is the address of the First Command returned to the user State.

(6) Check the hello elf header and find that it is consistent with the address pointed to by new _ IP.

(7) Continue the single-step execution. You can see a series of data loaded into the new executable program and construct a new code segment.

References

[Source of original work reprinted]

1. Linux Kernel Analysis MOOC course http://mooc.study.163.com/course/USTC-1000029000
2. Deep understanding of computer systems https://www.shiyanlou.com/courses/413

Section 7 load executable programs