zoukankan      html  css  js  c++  java

  • LINUX内核分析第七周学习总结——可执行程序的装载

    LINUX内核分析第七周学习总结——可执行程序的装载

    标签（空格分隔）： 20135321

    余佳源 原创作品转载请注明出处 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000

    一、预处理、编译、链接和目标文件的格式

    可执行文件的创建——预处理、编译和链接

    cd Code
    vi hello.c
    gcc -E -o hello.cpp hello.c -m32
    vi hello.cpp
    gcc -x cpp-output -S -o hello.s hello.cpp -m32
    vi hello.s
    gcc -x assembler -c hello.s -o hello.o -m32
    vi hello.o
    gcc -o hello hello.o -m32
    vi hello
    gcc -o hello.static hello.o -m32 -static
    ls -l
    -rwxrwxr-x 1 shiyanlou shiyanlou 7292 3u6708 23 09:39 hello
    -rw-rw-r-- 1 shiyanlou shiyanlou 64 3u6708 23 09:30 hello.c
    -rw-rw-r-- 1 shiyanlou shiyanlou 17302 3u6708 23 09:35 hello.cpp
    -rw-rw-r-- 1 shiyanlou shiyanlou 1020 3u6708 23 09:38 hello.o
    -rw-rw-r-- 1 shiyanlou shiyanlou 470 3u6708 23 09:35 hello.s
    -rwxrwxr-x 1 shiyanlou shiyanlou 733254 3u6708 23 09:41 hello.static

    ELF目标文件格式:

    shiyanlou:Code/ $ readelf -h hello

    • 查看该ELF文件依赖的共享库
    shiyanlou:sharelib/ $ ldd main                      [21:25:56]
    linux-gate.so.1 =>  (0xf774e000) # 这个是vdso - virtual DSO：dynamically shared object，并不存在这个共享库文件，它是内核的一部分，为了解决libc与新版本内核的系统调用不同步的问题，linux-gate.so.1里封装的系统调用与内核支持的系统调用完全匹配，因为它就是内核的一部分嘛。而libc里封装的系统调用与内核并不完全一致，因为它们各自都在版本更新。
    libshlibexample.so => /home/shiyanlou/LinuxKernel/sharelib/libshlibexample.so (0xf7749000)
    libdl.so.2 => /lib32/libdl.so.2 (0xf7734000)
    libc.so.6 => /lib32/libc.so.6 (0xf7588000)
    /lib/ld-linux.so.2 (0xf774f000)
shiyanlou:sharelib/ $ ldd /lib32/libc.so.6              [21:37:00]
    /lib/ld-linux.so.2 (0xf779e000)
    linux-gate.so.1 =>  (0xf779d000)
# readelf -d 也可以看依赖的so文件
shiyanlou:sharelib/ $ readelf -d main                              [21:28:04]
Dynamic section at offset 0xf04 contains 26 entries:
 0x00000001 (NEEDED)                     共享库：[libshlibexample.so]
 0x00000001 (NEEDED)                     共享库：[libdl.so.2]
 0x00000001 (NEEDED)                     共享库：[libc.so.6]
 0x0000000c (INIT)                       0x80484f0
 0x0000000d (FINI)                       0x8048804
 0x00000019 (INIT_ARRAY)                 0x8049ef8

    1.可执行程序是怎么来的？

    预处理 => 编译 => 汇编 => 链接

    • 预处理：编译器将C源代码中包含的头文件编译进来和执行宏替换等工作。
      • gcc –E hello.c –o hello.i; gcc –E调用cpp 生成中间文件
    • 编译：gcc首先要检查代码的规范性、是否有语法错误等，以确定代码的实际要做的工作，在检查无误后，gcc把代码翻译成汇编语言。
      • gcc –S hello.i –o hello.s; gcc –S调用ccl 翻译成汇编文件
    • 汇编：把编译阶段生成的.s文件转成二进制目标代码.
      • gcc –c hello.s –o hello.o; gcc -c 调用as 翻译成可重定位目标文件
    • 链接:将编译输出.o文件链接成最终的可执行文件。
      • gcc hello.o –o hello ; gcc -o 调用ld** 创建可执行目标文件
    • 运行：若链接没有-o指明，则生成可执行文件默认为a.out

    PS:hello和hello.o都是ELF格式的文件
    .static文件将所有用到C库文件都放到某一可执行程序中，所以占用空间较多

    2.目标文件的格式ELF


    A.out（最古老） COFF PE（Windows）、ELF（Linux中）

    ELF分类

    • 可重定位文件：保存着代码和适当的数据，用来和其他的object文件一起来创建一个可执行文件或者是一个共享文件。
    • 可执行文件：保存着一个用来执行的程序；该文件指出了exec(BA_OS)如何来创建程序进程映象。
    • 共享文件：主要是.so文件，保存着代码和合适的数据，用来被下面的两个链接器链接。
      • 第一个是连接编辑器，可以和其他的可重定位和共享object文件来创建其他的object。
      • 第二个是动态链接器，联合一个可执行文件和其他的共享object文件来创建一个进程映象。
    • object文件参与程序的链接（创建）和执行。

    ELF格式

    左边是ELF格式，右边是执行时候的格式

    entry代表刚加载过新的可执行文件之后的程序的入口地址，头部后是代码和数据，进程的地址空间是4G，上面的1G是内核用，下面的3G是程序使用。默认的ELF头加载地址是0x8048000

    • 查看ELF文件的头部：readelf
    • 在文件开始保存了：
      • 路线图：描述该文件组织情况
      • 程序头表：告诉系统如何创建一个进程的内存映像
      • section头表：描述文件的section信息。（每个section在这个表中有一个入口，给出该section信息）

    3.静态链接的ELF可执行文件和进程的地址空间

    一个ELF可执行文件加载到内存：
    可执行文件加载到内存中开始执行的第一行代码，默认从0x8048000开始加载，由于头部大小不同，程序实际入口可能不同。
    一般静态链接将会把所有代码放在同一个代码段。

    二、可执行程序、共享库和动态链接

    1.装载可执行程序之前的工作

    命令行参数和shell环境，一般我们执行一个程序的Shell环境，我们的实验直接使用execve系统调用。

    • 列出/usr/bin下的目录信息
      • $ ls -l /usr/bin 列出/usr/bin下的目录信息，其实是执行了一个可执行参数ls
    • Shell本身不限制命令行参数的个数， 命令行参数的个数受限于命令自身
      • int main(int argc, char *argv[], char *envp[])愿意接收shell相关环境变量，envp是shell的环境变量
      • int main(int argc, char *argv[])愿意接收命令行参数
    • Shell会调用execve将命令行参数和环境参数传递给可执行程序的main函数
      • int execve(const char * filename,char * const argv[ ],char * const envp[ ])
    1. 命令行参数和shell环境变量的保存与传递
      --
      Shell会调用execve将命令行参数和环境参数传递给可执行程序的main函数
    int execve(const char * filename,char * const argv[ ],char * const envp[ ]);
    • 库函数exec*都是execve的封装例程
    • 命令行参数和环境串都放在用户态堆栈中
    • 初始化新程序堆栈时拷贝进去

    shell程序—>execv—>sys_execve,然后在初始化新程序堆栈时拷贝进去

    先函数调用参数传递，再系统调用参数传递。

    3.装载时动态链接和运行时动态链接应用举例

    1. 动态链接分为可执行程序装载时动态链接和运行时动态链接（大部分使用前者）

    2. 共享库的动态链接

    - 准备.so文件（在Linux下动态链接文件格式，在Windows中是.dll）

    #ifndef _SH_LIB_EXAMPLE_H_
#define _SH_LIB_EXAMPLE_H_

#define SUCCESS 0
#define FAILURE (-1)

#ifdef __cplusplus
extern "C" {
#endif
/*
* Shared Lib API Example
* input : none
* output    : none
* return    : SUCCESS(0)/FAILURE(-1)
*
*/
int SharedLibApi();//内容只有一个函数头定义


#ifdef __cplusplus
}
#endif
#endif /* _SH_LIB_EXAMPLE_H_ */
/*------------------------------------------------------*/

#include <stdio.h>
#include "shlibexample.h"

int SharedLibApi()
{
    printf("This is a shared libary!
");
    return SUCCESS;
}/* _SH_LIB_EXAMPLE_C_ */
    • 编译成.so文件
      $ gcc -shared shlibexample.c -o libshlibexample.so -m32

    3. 动态加载库

    #ifndef _DL_LIB_EXAMPLE_H_
#define _DL_LIB_EXAMPLE_H_



#ifdef __cplusplus
extern "C" {
#endif
/*
 * Dynamical Loading Lib API Example
 * input    : none
 * output   : none
 * return   : SUCCESS(0)/FAILURE(-1)
 *
 */
int DynamicalLoadingLibApi();


#ifdef __cplusplus
}
#endif
#endif /* _DL_LIB_EXAMPLE_H_ */
/*------------------------------------------------------*/

#include <stdio.h>
#include "dllibexample.h"

#define SUCCESS 0
#define FAILURE (-1)

/*
 * Dynamical Loading Lib API Example
 * input    : none
 * output   : none
 * return   : SUCCESS(0)/FAILURE(-1)
 *
 */
int DynamicalLoadingLibApi()
{
    printf("This is a Dynamical Loading libary!
");
    return SUCCESS;
}

    4. main.c

    #include <stdio.h>
#include "shlibexample.h" //只include了共享库
#include <dlfcn.h>
/*
 * Main program
 * input    : none
 * output   : none
 * return   : SUCCESS(0)/FAILURE(-1)
 *
 */
int main()
{
    printf("This is a Main program!
");
    /* Use Shared Lib */
    printf("Calling SharedLibApi() function of libshlibexample.so!
");
    SharedLibApi();//可以直接调用，因为include了这个库的接口
    /* Use Dynamical Loading Lib */
    void * handle = dlopen("libdllibexample.so",RTLD_NOW);//先打开动态加载库
    if(handle == NULL)
    {
        printf("Open Lib libdllibexample.so Error:%s
",dlerror());
        return   FAILURE;
    }
    int (*func)(void);
    char * error;
    func = dlsym(handle,"DynamicalLoadingLibApi");
    if((error = dlerror()) != NULL)
    {
        printf("DynamicalLoadingLibApi not found:%s
",error);
        return   FAILURE;
    }    
    printf("Calling DynamicalLoadingLibApi() function of libdllibexample.so!
");
    func();  
    dlclose(handle);//与dlopen函数配合，用于卸载链接库       
    return SUCCESS;
}

    　dlsym函数与上面的dlopen函数配合使用，通过dlopen函数返回的动态库句柄（由dlopen打开动态链接库后返回的指针handle）以及对应的符号返回符号对应的指针。

    5.编译main.c

    $ gcc main.c -o main -L/path/to/your/dir -lshlibexample -ldl -m32
    $ export LD_LIBRARY_PATH=$PWD #将当前目录加入默认路径，否则main找不到依赖的库文件，当然也可以将库文件copy到默认路径下。
    $ ./main
    This is a Main program!
    Calling SharedLibApi() function of libshlibexample.so!
    This is a shared libary!
    Calling DynamicalLoadingLibApi() function of libdllibexample.so!
    This is a Dynamical Loading libary!

    这里只提供shlibexample的-L（库对应的接口头文件所在目录）和-l（库名，如libshlibexample.so去掉lib和.so的部分），并没有提供dllibexample的相关信息，只是指明了-ldl。

    三、可执行程序的装载

    1.可执行程序的装载相关关键问题分析

    • execve与fork是比较特殊的系统调用
      • execve用它加载的可执行文件把当前的进程覆盖掉，返回之后就不是原来的程序而是新的可执行程序起点；
      • fork函数的返回点ret_from_fork是用户态起点
    • sys_execve内核处理过程
      • do_execve -> do_execve_common -> exec_binprm
      • 最后，根据文件头部信息寻找对应的文件格式处理模块
    • search_binary_handler符合寻找文件格式对应的解析模块,根据文件头部信息寻找对应的文件格式处理模块
    list_for_each_entry(fmt, &formats, lh) {
if (!try_module_get(fmt->module))
continue;
read_unlock(&binfmt_lock);
bprm->recursion_depth++;
retval = fmt->load_binary(bprm);    //用来解析elf文件的执行到位置。
read_lock(&binfmt_lock);
    • 对于ELF格式的可执行文件fmt->load_binary(bprm);执行的应该是load_elf_binary，其内部是和ELF文件格式解析的部分，需要和ELF文件格式标准结合起来阅读。
    • Linux内核是如何支持多种不同的可执行文件格式的？
    /* 全局变量elf_format，把函数指针load_elf_binary**赋值**给了.load_binary */
static struct linux_binfmt elf_format = {
.module     = THIS_MODULE,
.load_binary    = load_elf_binary,
.load_shlib = load_elf_library,
.core_dump  = elf_core_dump,
.min_coredump   = ELF_EXEC_PAGESIZE,
};

/* 把变量elf_format**注册**进了format链表里，就可以在链表里对应elf模式中找到对应模块 */
 static int __init init_elf_binfmt(void)
{
register_binfmt(&elf_format);
return 0;
}

    elf_format 和 init_elf_binfmt，这里就相当于观察者模式中的观察者，elf_format是观察者，1369开始的那段代码是被观察者，当elf文件出现的时候，就会自动执行load_elf_binary。

    2.sys_execve的内部处理过程

    装载和启动一个可执行程序依次调用以下函数：

    sys_execve() -> do_execve() -> do_execve_common() -> exec_binprm() -> search_binary_handler() -> load_elf_binary() -> start_thread()

    解析：

    打开file文件，找到文件头部，把命令行参数和环境变量copy到结构体中

寻找打开的可执行文件处理函数

寻找能够解析当前可执行文件的模块，load_ binary加载这个模块，它实际调用的是binfmt_ elf.c

需要动态链接的可执行文件先加载连接器ld；否则直接把ELF文件entry地址赋值给entry

start_ thread(regs, elf_ entry, bprm->p)将CPU控制权交给ld来加载依赖库并完成动态链接。对于静态链接的文件elf_entry是新程序执行的起点
    • 最后，根据文件头部信息寻找对应的文件格式处理模块

    1369 list_for_each_entry(fmt, &formats, lh) {//在链表中寻找可以处理这种格式（比如ELF）的模块
    1370 if (!try_module_get(fmt->module))
    1371 continue;
    1372 read_unlock(&binfmt_lock);
    1373 bprm->recursion_depth++;
    1374 retval = fmt->load_binary(bprm);//对于ELF格式的可执行文件fmt->load_binary(bprm);执行的应该是load_elf_binary其内部是和ELF文件格式解析的部分需要和ELF文件格式标准结合起来阅读
    1375 read_lock(&binfmt_lock);

    3.Linux内核是如何支持多种不同的可执行文件格式的？

    static struct linux_binfmt elf_format//声明一个全局变量 = {
.module     = THIS_MODULE,
.load_binary    = load_elf_binary,//观察者自动执行
.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);//把变量注册进内核链表,在链表里查找文件的格式
    return 0;
}

    4.庄周梦蝶

    庄周（调用execve的可执行程序）入睡（调用execve陷入内核），醒来（系统调用execve返回用户态）发现自己是蝴蝶（被execve加载的可执行程序）

    比喻解析：

    庄周——调用execve的可执行程序
    入睡——调用execve陷入内核
    醒来——系统调用execve返回用户态
    发现自己是蝴蝶——被execve加载的可执行程序

    load_elf_binary调用start_thread函数。修改int 0x80压入内核堆栈的EIP

    5.动态链接

    • 可执行程序需要依赖动态链接库，而这个动态链接库可能会依赖其他的库，这样形成了一个关系图——动态链接库会生成依赖树。
    • 依赖动态链接器进行加载库并进行解析（这就是一个图的遍历），装载所有需要的动态链接库；之后ld将CPU的控制权交给可执行程序
    • 动态链接的过程主要是动态链接器在起作用，而不是内核完成的。

    四、实践部分

    1.环境搭建

    rm menu -rf
git clone https://github.com/megnning/menu.git
cd menu
ls
mv test_exec.c test.c
vi test.c   //可以看到增加了一个exec的程序，只比fork程序多了一个execlp
vi Makefile // 查看Makefile的更改，加入了hello
make rootfs

    makefile的修改

    依照实验视频补充了cp hello ../rootfs以及cp init ../rootfs

    执行exec后，出现了hello world，这其实是加载了一个新的程序hello。

    test.c文件，更新命令部分

    2.使用gdb跟踪

    qemu-system-x86_64 -kernel ../linux-3.18.6/arch/x86/boot/bzImage -initrd ../rootfs.img -s -S
gdb
file ../linux-3.18.6/vmlinux
target remote:1234

b sys_execve    //可以先停在sys_execve然后再设置其他断点
b load_elf_binary
b start_thread

    gdb调试，设置断点到sys_exec,进入函数内部发现调用了do_execve()函数

    gdb调试过程中，执行到start_ thread,查看new_ ip的内容,new_ ip到底是指向哪里的？

    可以看到一个地址：0x80495ba

    readelf -h hello
找到hello这个可执行程序的入口地址。
这是一个静态编译的可执行文件。

    五、小结

    • 新的可执行程序通过修改内核堆栈eip作为新程序的起点，从new_ip开始执行后start_thread把返回到用户态的位置从int 0x80的下一条指令变成新加载的可执行文件的入口位置。

    • 动态链接的过程中，内核做了什么：1.ldd test 2.可执行程序需要依赖动态链接库，而这个动态链接库可能会依赖其他的库，这样形成了一个关系图； 3.interpreter：需要依赖动态链接器进行加载这些库并进行解析（这就是一个图的遍历），装载所有需要的动态链接库；之后ld将CPU的控制权交给可执行程序 4.所以，动态链接的过程主要是动态链接器在起作用，而不是内核

    • 当进程调用一种exec函数时，该进程执行的程序完全替换为新程序，而新程序则从其main函数开始执行。

    • exec只是用一个全新的程序替换了当前进程的正文、数据、堆和栈段。

    • 两种加载的方法：1.静态库：直接执行可执行程序的入口 2.动态库：由ld来动态链接这个程序，然后再把控制权移交给可执行程序的入口。
  • 相关阅读:
    MongoDB Query 常用方法
    plsql中文乱码问题（显示问号）
    xtype的使用
    LinQ：list基础操作
    VMware Fusion自动切换分辨率
    C#截取字符串的方法小结
    HTML 编码
    AMQP(Advanced Message Queuing Protocol)
    rabibtMQ安装及集群配置linux
    今天是个开始
  • 原文地址：https://www.cnblogs.com/brotherlittlefish/p/5372822.html
Copyright © 2011-2022 走看看