CN112948024B - 动态链接库的加载方法、装置、存储介质及电子设备 - Google Patents

Abstract

本公开提供一种动态链接库的加载方法、装置、存储介质及电子设备；涉及计算机技术领域。所述方法应用于第三方云引擎，所述第三方云引擎支持在第一操作系统中运行第二操作系统下的动态链接库，所述方法包括：确定所述动态链接库中的可加载段；根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。本公开可以将第二操作系统下的大部分动态链接库文件映射到第一操作系统中，与全部使用内存模拟动态链接库相比更加节省内存。

Description

动态链接库的加载方法、装置、存储介质及电子设备

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种动态链接库的加载方法、动态链接库的加载装置、计算机可读存储介质以及电子设备。

背景技术

动态链接库(Dynamic Link Library，DLL)是Windows操作系统中实现共享函数库的一种方式，使进程可以调用不属于其可执行代码的函数。其中，动态链接库文件是一种为DLL、EXE等格式的二进制文件，允许程序共享执行任务所需的代码和资源。在Linux操作系统中，动态链接库是ELF(Executable and Linkable Format，可执行可链接文件格式)格式的so(share object，共享动态链接库)库。

其中，Windows系统中的程序可以加载DLL格式的共享库来运行，而无法从EXE二进制文件中加载并且直接调用一个ELF格式的so库。因为ELF格式不属于Windows操作系统认可的二进制文件，所以无法通过Windows操作系统的二进制检查，导致Windows操作系统的正常加载库的路径无法使用。

目前，可以将so库的内容全部读取到内存中，以在Windows操作系统中直接运行ELF格式的二进制文件。但是，该方法占用了大量内存。因此，为了减少内存的占用，提出一种动态链接库的加载方法是非常必要的。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种动态链接库的加载方法、动态链接库的加载装置、计算机可读存储介质以及电子设备，以解决现有技术中在Windows操作系统中直接加载Linux操作系统下的动态链接库时占用内存大的问题。

根据本公开的第一方面，提供一种动态链接库的加载方法，所述方法应用于第三方云引擎，所述第三方云引擎支持在第一操作系统中运行第二操作系统下的动态链接库，所述方法包括：

确定所述动态链接库中的可加载段；

根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

在本公开的一种示例性实施例中，所述确定所述动态链接库中的可加载段，包括：

获取所述动态链接库中库文件的程序头表，并读取所述程序头表中的各个程序头；

根据每个所述程序头的属性参数确定所述动态链接库中的可加载段。

在本公开的一种示例性实施例中，所述程序头的属性参数至少包括偏移参数和长度参数；

所述根据每个所述程序头的属性参数确定所述动态链接库中的可加载段，包括：

根据所述偏移参数在所述库文件中确定偏移位置；

基于所述偏移位置，在所述库文件中确定与所述长度参数对应的数据段；

将所述数据段确定为所述动态链接库中的可加载段。

在本公开的一种示例性实施例中，所述第一操作系统的文件映射要求，包括：

以页面对齐的方式进行文件映射，所述页面的大小为64KB。

在本公开的一种示例性实施例中，所述将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处，包括：

将所述动态链接库中的所述第一个可加载段映射到所述第一操作系统中64KB对齐的内存地址处。

在本公开的一种示例性实施例中，所述方法还包括：

所述第一个可加载段从所述动态链接库文件的0偏移量开始映射。

在本公开的一种示例性实施例中，所述将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中，包括：

根据虚拟地址的映射要求，确定所述第二个可加载段与所述第一个可加载段的相对偏移量；

将所述第二个可加载段按照所述相对偏移量读取到与所述目标内存地址相邻的内存中。

在本公开的一种示例性实施例中，所述第一操作系统为Windows操作系统，所述第二操作系统为Linux操作系统。

在本公开的一种示例性实施例中，所述第三方云引擎为星云引擎。

根据本公开的第二方面，提供一种动态链接库的加载装置，包括：

数据确定模块，用于确定所述动态链接库中的可加载段；

文件映射模块，用于根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

内存模拟模块，用于将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的方法。

根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

在本公开示例实施方式所提供的动态链接库的加载方法中，通过确定所述动态链接库中的可加载段；根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。一方面，将第二操作系统下的大部分动态链接库文件映射到第一操作系统中，节省了内存的使用；另一方面，由于动态链接库在第一操作系统中占用的内存少，便于调用该动态链接库对程序进行调试，增加了程序的可调试性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1示出了可以应用本公开实施例的一种动态链接库的加载方法及装置的示例性系统架构的示意图；

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；

图3示意性示出了根据本公开的一个实施例的动态链接库的加载方法的流程图；

图4示意性示出了根据本公开的一个实施例的确定可加载段的流程图；

图5示意性示出了根据本公开的又一个实施例的确定可加载段的流程图；

图6示意性示出了根据本公开的一个实施例的内存模拟的流程图；

图7示意性示出了根据本公开的一个实施例的动态链接库的加载装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本公开实施例的一种动态链接库的加载方法及装置的示例性应用环境的系统架构的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

本公开实施例所提供的动态链接库的加载方法一般由服务器105执行，相应地，动态链接库的加载装置一般设置于服务器105中。但本领域技术人员容易理解的是，本公开实施例所提供的动态链接库的加载方法也可以由终端设备101、102、103执行，相应的，动态链接库的加载装置也可以设置于终端设备101、102、103中，本示例性实施例中对此不做特殊限定。

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元(CPU)201，其可以根据存储在只读存储器(ROM)202中的程序或者从存储部分208加载到随机访问存储器(RAM)203中的程序而执行各种适当的动作和处理。在RAM 203中，还存储有系统操作所需的各种程序和数据。CPU201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出(I/O)接口205也连接至总线204。

以下部件连接至I/O接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。

特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(CPU)201执行时，执行本申请的方法和装置中限定的各种功能。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3至图6所示的各个步骤等。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

以下对本公开实施例的技术方案进行详细阐述：

目前，可以实现在Windows操作系统中运行Linux系统下的二进制文件的方法有：

方法一：Cygwin是一个在Windows操作系统中运行的类UNIX模拟环境，可以学习UNIX操作系统或Linux操作系统的操作环境，也可以从UNIX操作系统到Windows操作系统进行应用程序的移植。Cygwin通过提供一个UNIX模拟DLL以及可以在Linux系统中找到的软件包，在Windows操作系统中可以提供良好的支持，也就是说，Cygwin在Windows系统中运行Linux系统下的二进制文件是将二进制文件编译成EXE、DLL等格式的文件后，在Windows操作系统中运行该二进制文件。

方法二：WSL(Windows Subsystem for Linux，Windows下的Linux子系统)是一个在Windows操作系统上可以运行原生Linux操作系统下的二进制可执行文件(ELF格式)的兼容层，本质上是通过在Linux虚拟机环境运行的完整Linux操作系统，属于虚拟化的做法。

可以看出，Windows操作系统中的程序可以加载DLL格式的共享库来运行，而无法从EXE二进制文件中加载并且直接调用一个ELF格式的so库。因为ELF格式不属于Windows操作系统认可的二进制文件，所以无法通过Windows操作系统的二进制检查，导致Windows操作系统的正常加载库的路径无法使用。为了在Windows操作系统中直接运行so库，可以将so库的内容全部读取到内存中。但是，该方法占用了大量内存。

基于上述一个或多个问题，本示例实施方式提供了一种动态链接库的加载方法，该方法可以应用于上述服务器105，也可以应用于上述终端设备101、102、103中的一个或多个，本示例性实施例中对此不做特殊限定。参考图3所示，该动态链接库的加载方法可以包括以下步骤S310至步骤S330：

步骤S310.确定所述动态链接库中的可加载段；

步骤S320.根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

步骤S330.将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

在本公开示例实施方式所提供的动态链接库的加载方法中，通过确定所述动态链接库中的可加载段；根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。一方面，将第二操作系统下的大部分动态链接库文件映射到第一操作系统中，节省了内存的使用；另一方面，由于动态链接库在第一操作系统中占用的内存少，便于调用该动态链接库对程序进行调试，增加了程序的可调试性。

下面，对于本示例实施方式的上述步骤进行更加详细的说明。

本公开中所述动态链接库的加载方法可以应用于第三方云引擎，该第三方云引擎可以支持在第一操作系统中运行第二操作系统下的动态链接库。一种示例实施方式中，第三方云引擎可以是星云引擎，第一操作系统可以是Windows操作系统，第二操作系统可以是Linux操作系统。

其中，星云引擎也称为Nebula，是指可以用于搭载手机游戏应用程序(如MuMu手机游戏助手等)的服务器引擎。星云引擎上可以搭载多个应用程序，应用程序在星云引擎上运行时，每个应用程序对应一个模拟器实例，并对应一个数据路径作为该应用程序的文件系统。重要的是，星云引擎可以不使用虚拟化技术实现在Windows操作系统上运行Linux操作系统。

另外，星云引擎还可以支持只运行一个shell的最小化系统。其中，shell是用户和操作系统间的命令解释器，负责接受用户输入的命令，并将该命令翻译成操作系统可以理解的指令，相当于可以直接在Windows操作系统上运行ELF格式的二进制文件。在该情形下，星云引擎需要在ELF格式的二进制文件中直接链接一个so库。

在步骤S310中，确定所述动态链接库中的可加载段。

一种示例实施方式中，可以直接将so库文件映射到内存中，并执行其中的可执行代码。其中，由于ELF格式的二进制文件内部是分段的，在将so库文件映射到内存时，参考图4所示，可以根据步骤S410和步骤S420先确定动态链接库中的可加载段。

在步骤S410中，获取所述动态链接库中库文件的程序头表，并读取所述程序头表中的各个程序头。

ELF文件是一种用于二进制文件、可执行文件、目标代码、共享库和core转存的格式文件，也是Linux的主要可执行文件格式。ELF文件可以由ELF头(ELF Header)、程序头表和节头表三部分组成，其中，ELF头位于文件中的开始位置，可以用于描述文件的主要特性，以及定位文件的其他部分；程序头表可以用来列举所有有效的段，如代码段、数据段及其属性，且程序头是一个结构数组，每一个结构可以表示一个段，每个段保存着用于不同目的的数据，例如，有的段保存着机器指令，有的段保存着已经初始化的变量，有的段会作为进程映像的一部分被操作系统读入内存，有的段则只存在于文件中。另外，在可执行文件或者共享链接库中所有的节也可以分为不同的几个段；节头表可以包含对节的描述，如每个段的段名、段的长度、在文件中的偏移、读写权限及段的其它属性。对应的，ELF文件格式可以提供两种视图，分别是链接视图和执行视图，其中，链接视图是在链接时用到的视图，以节(section)为单位；执行视图是在执行时用到的视图，以段(segment)为单位。

本示例中，可以对ELF格式的so库文件进行解析，以获得so库文件中的程序头表，程序头表中可以包含至少一个程序头。通过依次读取该程序头表中的各个程序头，可以获取保存在程序头中的各个参数。其中，在so库文件中，每个程序头均有与其对应的段，而且，程序头中保存的参数可以表示与其对应的段中数据的属性、结构等信息。

在步骤S420中，根据每个所述程序头的属性参数确定所述动态链接库中的可加载段。

示例性的，可以判断每个程序头的属性参数是否可以表征为可加载属性。例如，属性参数在参数表中可以表示为p_type，判断p_type的属性是否为PT_LOAD，当p_type的属性为PT_LOAD时，说明该程序头表中的属性参数可以表征为可加载属性。对应的，就可以确定so库文件中与程序头对应的可加载段。

参考图5所示，也可以根据步骤S510至步骤S530确定动态链接库中的可加载段。

在步骤S510中，根据所述偏移参数在所述库文件中确定偏移位置。

一种示例实施方式中，每个程序头的属性参数可以至少包括偏移参数和长度参数。其中，偏移参数可以表示在so库文件中的偏移量，具体可以表示为p_offset；长度参数可以表示数据的长度，具体可以表示为p_filesz。可以根据该偏移参数，在该so库文件中确定偏移位置。

在步骤S520中，基于所述偏移位置，在所述库文件中确定与所述长度参数对应的数据段。

确定偏移位置以后，可以从该偏移位置开始，在该so库文件中确定与长度参数表示的数据长度相同的数据段。可以理解的是，该偏移位置可以为确定该数据段的起始位置。

在步骤S530中，将所述数据段确定为所述动态链接库中的可加载段。也就是可以将该数据段确定为与程序头对应的可加载段。

ELF格式的so库文件在映射时，要求多个可加载段之间的偏移要固定的，而且，每个可加载段需要单独映射，不同的可加载段之间在内存中还可能会存在空洞。以在星云引擎中模拟运行Android应用程序为例，Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑。Android操作系统下可以是两个需要加载的LOAD类型的段，可以理解的是，文件中只有LOAD类型的段是需要被映射的，其可以表示可加载段。这两个可加载段在文件存储上是相对靠近的，但是，将其加载到内存时，需要尊重vaddr(virtual address，虚拟地址)的定义要求。其中，Vaddr可以用来表示ELF格式要求该可加载段在内存中的分布。

例如，当第一个LOAD段在文件中存在于0-1KB的位置，第二个LOAD段在文件中存在于1.2KB-3KB的位置时，由vaddr的映射要求决定了第一个LOAD段的vaddr可以是0，第二个LOAD段的vaddr是可以2KB。可以看出两个LOAD段的vaddr与其在文件中的偏移不一样，但是，编译时两个LOAD段之间的寻址索引是写死的，也就是说需要按照vaddr的要求加载才可以正确的执行指令。

可以理解的是，ELF格式的文件在映射时，要求该文件的第一个LOAD段加载到指定位置，第二个LOAD段序要分离的加载到另一个指定位置。本示例中，Windows操作系统也可以支持将ELF格式的文件拆分成两个LOAD段进行加载，该加载过程中需要满足两个限制条件：

1、文件映射时以64KB对齐；

2、当文件大小不能恰好填充64KB对齐的内存时，后面的空洞无法被访问和使用。

对于Linux操作系统下的so库链接，ELF格式的二进制文件的加载要求是后续的LOAD段需要按照虚拟地址决定的偏移量来映射，意味着后续的映射不一定是64KB对齐。其次，LOAD段映射的大小与文件中实际存在的大小不一样，例如，LOAD段的映射大小大于其在文件中实际存在的大小，因为后续的LOAD段中可以包含.bss段，.bss段是可以用来存放程序中未初始化的或者初始化为0的全局变量和静态变量的一块内存区域，因此，该段在文件中的占用大小是0，但是在内存中要求访问的时候内容为0。可以看出，该ELF要求与Windows下的第二条限制是冲突的。

so库文件可以在程序刚启动时由动态链接器映射入可执行程序的地址空间，也可以通过dl库中的dlopen(一种库函数，可以以指定模式打开对应的动态链接库)映射入可执行程序的地址空间中。其中底层实现都可以通过mmap来实现，mmap是一种内存映射文件的方法，可以用于将一个文件或者其它对象映射到内存的用户空间，实现文件磁盘地址和用户地址空间中一段虚拟地址的一一对映关系。需要说明的是，本公开中，不能直接将整个so库文件映射到内存中，而是需要专门定制链接来加载该so库文件。

在步骤S320中，根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处。

第一操作系统可以为Window操作系统，第二操作系统可以为Linux操作系统。操作系统可以使用虚拟内存为进程提供更大的空间，其中，页为最小的内存分配单位，并且不足一页的可以按一页算，加载程序数据时也可以从一页的起始地址开始，也就是进行对齐。同时，内存权限管理的粒度也是以页为单位，页内的内存是具有同样的权限等属性。示例性的，Window操作系统的文件映射要求可以是以页面对齐的方式进行文件映射，其中页面的大小可以为64KB。可以理解的是，Linux操作系统下so库文件中的LOAD段也可以是页对齐的，其页面的大小可以是4KB。

一种示例中，将so库文件中映射到Window操作系统时，可以将so库文件中的第一个LOAD段映射到Window操作系统中64KB对齐的内存地址处。此时，可以不遵循vaddr的映射要求，但是后续的LOAD段需要保证与第一个LOAD段虚拟地址的相对偏移。

同时，第一个可加载段可以从动态链接库中库文件的0偏移量开始映射，即第一个LOAD段从so库文件的0偏移量开始，以保证第一个LOAD段所在的文件偏移可以64KB对齐。

示例性的，so库文件的大小为1026KB，对应的，第一个LOAD段大小可以为1024KB，第二个LOAD段大小可以为2KB。可以从so库文件的0偏移量开始，将第一个LOAD段以64KB对齐的方式映射到Window操作系统中的映射内存中。由于映射后的文件只占用虚拟地址空间，并不占用实际的内存资源，因此在Windows操作系统侧进行so库的文件映射，可以减少Windows操作系统内存的占用。

在步骤S330中，将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

由于后续LOAD段的加载与Windows操作系统的映射是冲突的，本示例中可以使用内存模拟来解决。参考图6所示，可以根据步骤S610和步骤S620进行内存模拟。

步骤S610.根据虚拟地址的映射要求，确定所述第二个可加载段与所述第一个可加载段的相对偏移量。

示例性的，so库文件中第一个LOAD段在文件中存在于0-1KB的位置，第二个LOAD段在文件中存在于1.2KB-3KB的位置。根据虚拟地址的映射的要求，第一个LOAD段的虚拟地址是0，第二个LOAD段的虚拟地址是2KB。其中，第一个LOAD段的偏移量为0，可以确定第二个LOAD段与第一个LOAD段的相对偏移量为2KB。

步骤S620.将所述第二个可加载段按照所述相对偏移量读取到与所述目标内存地址相邻的内存中。

为了满足ELF映射标准的偏移要求，可以将第二个可加载段按照相对偏移量读取到与目标内存地址相邻的内存中。可以理解的是，在Windows操作系统中链接运行so库文件时，可以将第二个可加载段按照相对偏移量拷贝到内存中。示例性的，可以实际映射so库文件的64KB对齐的文件部分，例如，当so库文件中第一个LOAD段是65KB时，只映射第一个LOAD段的64KB，后面的内存可以使用普通内存来模拟，也就是可以将剩余1KB的文件内容读取到普通内存中，且该1KB的文件所在的内存地址与64KB的文件所在的内存地址存在一个相对偏移量，如步骤S610中确定的大小为2KB的相对偏移量。因此，后续LOAD段的映射是通过普通内存模拟，即从文件中直接读取后续LOAD段的内容，对于.bss段的清零要求也可以是0内容的普通内存。

本示例中，so库文件的大部分内容位于第一个LOAD段，因此可以直接将大部分的文件映射到内存中。对于没有对齐的部分和后续在文件中占比不大的LOAD段可以使用普通内存模拟，以满足ELF映射标准的对齐要求。

本方法中，Linux操作系统中进程对应的内存空间就是Windows操作系统中对应的内存空间，二者共享的均为Windows层面的页表，进而可以将虚拟地址映射到物理地址。并且，实现了一个定制加载器，基于ELF格式中对可加载段的加载要求和偏移要求将so库加载到内存。与全部使用内存模拟(将文件内容读取到内存来模拟映射)的方法相比，可以减少对内存的占用，需要说明的是，减小的内存占用量相当于so库文件的大小。另外，在星云引擎中实现了在Windows侧直接映射大部分的so库文件，而不需要大量使用内存来模拟so库文件，因此，节省了内存使用。调用该动态链接库对程序进行调试时，可以有效减小应用程序的大小，从而节省了调试应用程序的加载及运行时间，也即增加了程序的可调试性。

在本公开示例实施方式所提供的动态链接库的加载方法中，通过确定所述动态链接库中的可加载段；根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。一方面，将第二操作系统下的大部分动态链接库文件映射到第一操作系统中，节省了内存的使用；另一方面，由于动态链接库在第一操作系统中占用的内存少，便于调用该动态链接库对程序进行调试，增加了程序的可调试性。

应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步的，本示例实施方式中，还提供了一种动态链接库的加载装置。该装置可以应用于一服务器或终端设备。参考图7所示，该动态链接库的加载装置700可以包括数据确定模块710、文件映射模块720以及内存模拟模块730，其中：

数据确定模块710，用于确定所述动态链接库中的可加载段；

文件映射模块720，用于根据所述第一操作系统的文件映射要求，将所述动态链接库文件中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

内存模拟模块730，用于将所述动态链接库文件中的第二个可加载段按对应的文件偏移量加载到与所述目标内存地址相邻的内存中。

在一种可选的实施方式中，数据确定模块710包括：

程序头读取单元，用于获取所述动态链接库中库文件的程序头表，并读取所述程序头表中的各个程序头；

可加载段确定单元，用于根据每个所述程序头的属性参数确定所述动态链接库中的可加载段。

在一种可选的实施方式中，所述程序头的属性参数至少包括偏移参数和长度参数，可加载段确定单元包括：

偏移位置确定子单元，用于根据所述偏移参数在所述库文件中确定偏移位置；

数据段确定子单元，用于基于所述偏移位置，在所述库文件中确定与所述长度参数对应的数据段；

可加载段确定子单元，用于将所述数据段确定为所述动态链接库中的可加载段。

在一种可选的实施方式中，文件映射模块720被配置为：用于以页面对齐的方式进行文件映射，所述页面的大小为64KB。

在一种可选的实施方式中，文件映射模块720还被配置为：用于将所述动态链接库文件中的所述第一个可加载段映射到所述第一操作系统中64KB对齐的内存地址处。

在一种可选的实施方式中，文件映射模块720还被配置为所述第一个可加载段从所述动态链接库文件的0偏移量开始映射。

在一种可选的实施方式中，内存模拟模块730包括：

偏移量确定模块，用于根据虚拟地址的映射要求，确定所述第二个可加载段与所述第一个可加载段的相对偏移量；

文件加载模块，用于将所述第二个可加载段按照所述相对偏移量加载到与所述目标内存地址相邻的内存中。

在一种可选的实施方式中，动态链接库的加载装置700被配置为所述第一操作系统为Windows操作系统，所述第二操作系统为Linux操作系统。

在一种可选的实施方式中，动态链接库的加载装置700被配置为所述第三方云引擎为星云引擎。

上述动态链接库的加载装置中各模块的具体细节已经在对应的动态链接库的加载方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种动态链接库的加载方法，其特征在于，所述方法应用于第三方云引擎，所述第三方云引擎支持在第一操作系统中运行第二操作系统下的动态链接库，所述方法包括：

获取所述动态链接库中库文件的程序头表，并读取所述程序头表中的各个程序头；

根据每个所述程序头的属性参数确定所述动态链接库中的可加载段；其中，所述程序头的属性参数至少包括偏移参数和长度参数；

所述根据每个所述程序头的属性参数确定所述动态链接库中的可加载段，包括：根据所述偏移参数在所述库文件中确定偏移位置；基于所述偏移位置，在所述库文件中确定与所述长度参数对应的数据段；将所述数据段确定为所述动态链接库中的可加载段；

根据所述第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

2.根据权利要求1所述的动态链接库的加载方法，其特征在于，所述第一操作系统的文件映射要求，包括：

以页面对齐的方式进行文件映射，所述页面的大小为64KB。

3.根据权利要求2所述的动态链接库的加载方法，其特征在于，所述将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处，包括：

将所述动态链接库中的所述第一个可加载段映射到所述第一操作系统中64KB对齐的内存地址处。

4.根据权利要求3所述的动态链接库的加载方法，其特征在于，所述方法还包括：

所述第一个可加载段从所述动态链接库中库文件的0偏移量开始映射。

5.根据权利要求1所述的动态链接库的加载方法，其特征在于，将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中，包括：

根据虚拟地址的映射要求，确定所述第二个可加载段与所述第一个可加载段的相对偏移量；

将所述第二个可加载段按照所述相对偏移量读取到与所述目标内存地址相邻的内存中。

6.根据权利要求1所述的动态链接库的加载方法，其特征在于，所述第一操作系统为Windows操作系统，所述第二操作系统为Linux操作系统。

7.根据权利要求1所述的动态链接库的加载方法，其特征在于，所述第三方云引擎为星云引擎。

8.一种动态链接库的加载装置，其特征在于，包括：

数据确定模块，用于获取所述动态链接库中库文件的程序头表，并读取所述程序头表中的各个程序头；根据每个所述程序头的属性参数确定所述动态链接库中的可加载段；其中，所述程序头的属性参数至少包括偏移参数和长度参数；所述根据每个所述程序头的属性参数确定所述动态链接库中的可加载段，包括：根据所述偏移参数在所述库文件中确定偏移位置；基于所述偏移位置，在所述库文件中确定与所述长度参数对应的数据段；将所述数据段确定为所述动态链接库中的可加载段；

文件映射模块，用于根据第一操作系统的文件映射要求，将所述动态链接库中的第一个可加载段映射到所述第一操作系统中的目标内存地址处；

内存模拟模块，用于将所述动态链接库中的第二个可加载段按对应的文件偏移量读取到与所述目标内存地址相邻的内存中。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7任一项所述方法。

10.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-7任一项所述的方法。

Images