干货 | 在动态库中如何调用外部函数?

大家好,我是一个动态链接库!

这个名字,相信你一定早就如雷贯耳了。

在计算机早期时代,由于内存资源紧张,我可是发挥了重大的作用!

不论是在 Windows 系统中,还是在 Unix 系列平台上,到处都能见到我的身影,因为我能为大家节省很多资源啊,资源就是人民币!

愉快的玩耍

比如:我的主人编写了这么一段简单的代码:

# 文件:lib.c

#include <stdio.h>

int func_in_lib(int k)
{
    printf("func_in_lib is called \n");
    return k + 1;
}

只要用如下命令来编译,我就诞生出来了 lib.so,也就是一个动态链接库:

$ gcc -m32 -fPIC --shared -o lib.so lib.c

这个时候,主人随便把我丢给谁,我都可以为他服务,只要他调用我肚子里的这个函数 func_in_lib 就可以了。

虽然目前你看到我提供的这个函数很简单,但是道理都是一样的,后面如果有机会,我就在这个函数里来计算机器人的运动轨迹,给你瞧一瞧!

例如:张三今天写了一段代码,需要调用我的这个函数。

张三这个人比较喜欢骚操作,明明他在编译可执行程序的时候,把我动态链接一下就可以了,就像下面这样:

$ gcc -m32 -o main main.c ./lib.so

但是张三偏偏不这么做,为了炫技,他选择使用 dlopen 动态加载的方式,来把我从硬盘上加载到进程中。

咱们来一起围观一下张三写的可执行程序代码:

# 文件:main.c

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

typedef int (*pfunc)(int);

int main(int argc, char *agv[])
{
    int a = 1;
    int b;

    // 打开动态库
    void *handle = dlopen("./lib.so", RTLD_NOW);
    if (handle)
    {
        // 查找动态库中的函数
        pfunc func = (pfunc) dlsym(handle, "func_in_lib");
        if (func)
        {
            b = func(a);
            printf("b = %d \n", b);
        }
        else
        {
            printf("dlsym failed! \n");
        }
        dlclose(handle);
    }
    else
    {
        printf("dlopen failed! \n");
    }
    
    return 0;
}

从代码中可以看到,张三预先知道我肚子里的这个函数名称是func_in_lib,所以他使用了系统函数 dlsym(handle, "func_in_lib");来找到这个函数在内存中的加载地址,然后就可以直接调用这个函数了。

张三编译得到可执行文件 main 之后,执行结果完全正确,很开心!

悲从中来

可是有一天,我遇到一件烦人的事情,我的主人说:你这个服务函数的计算过程太单调了,给你找点乐子,你在执行的时候啊,到其他一个外部模块里调用一个函数。

话刚说完,就丢给我一个函数名:void func_in_main(void);

也就是说,我需要在我的服务函数中,去调用其他模块里的函数,就像下面这样:

#include <stdio.h>

// 外部函数声明
void func_in_main(void);

int func_in_lib(int k)
{
    printf("func_in_lib is called \n");

    // 调用外部函数
    func_in_main();
    
    return k + 1;
}

那么这个函数在哪里呢?天哪,我怎么知道这个函数是什么鬼?怎么才能找到它藏在内存的那个角落(地址)里?

不管怎么样,主人修改了代码之后,还是很顺利的把我编译了出来:

$ gcc -m32 -fPIC --shared -o lib.so lib.c

编译指令完全没有变化。

因为我仅仅是一个动态链接库,这个时候即使我不知道 func_in_main 函数的地址,也是可以编译成功的。

只不过我要把这个家伙标记一下:谁要是想使用我,就必须告诉我这个家伙的地址在哪里!,否则就别怪我耍赖。

无辜的张三

我的主人对张三说:兄弟,我的这个动态链接库升级了,功能更强大哦,想不想试一下?

张三心想:我是使用 dlopen 的方式来动态加载动态库文件的,不需要对可执行程序重新编译或者链接,直接运行就完事了!

于是他二话不说,直接就把我拿过去,丢在他的可执行程序目录下,然后执行 main 程序。

可是这一次,他看到的结果却是:

dlopen failed!

为什么会加载失败呢?上次明明是正常执行的!张三一脸懵逼!

其实,这压根就不能怪我!以为我刚才就说了:谁要是想使用我,就必须告诉我 func_in_main 这个函数的地址在哪里!

可是在张三的这个进程里,我到处都找不到这个函数的地址。既然你没法满足我,那我就没法满足你!

锦囊1: 导出符号表

张三这下也没辙了,只要找我的主人算账:我的应用程序代码一丝一毫都没有动,怎么换了你给的新动态链接库就不行了呢?

主人慢条斯理的回答:疏忽了,疏忽了,忘记跟你说一件事情了:这个动态库啊,它需要你多做一件事情:在你的程序中提供一个名为 func_in_main 的函数,这样就可以了。

张三一想:这个好办,加一个函数就是了。

因为这个可执行程序只有一个 main.c 文件,于是他在其中新加了一个函数:

void func_in_main(void)
{
    printf("func_in_main \n");
}

然后就开始编译、执行,一顿操作猛如虎:

# gcc -m32 -o main main.c -ldl
# ./main
dlopen failed!

咦?怎么还是失败?!已经按照要求加了 func_in_main 这个函数了啊?!

这个傻X张三,对,你确实是在 main.c 中加了这个函数,但是你仅仅是加在你的可执行程序中的,但是我却压根就看不到这个函数啊!

不信的话,你检查一下编译出来的可执行程序中,是否把 func_in_main这个符号导出来了?如果不导出来,我怎么能看到?

# 查看导出的符号表
$ objdump -e main -T | grep func_in_main
# 这里输出为空

既然输出为空,就说明没有导出来!这个就不用我教你了吧?

茴香豆的“茴”字,一共有四种写法。。。

哦,不,导出符号,一共有两种方式:

方式1:导出所有的符号

$ gcc -m32 -rdynamic -o main main.c -ldl

当然,下面这个指令也可以:

gcc -m32 -Wl,--export-dynamic -o main main.c -ldl

方式2:导出指定的符号

先定义一个文件,把需要导出的符号全部罗列出来:

文件:exported.txt

{
    extern "C"
    {
        func_in_main;
    };
};

然后,在编译选项中指定这个导出文件:

gcc -m32 -Wl,-dynamic-list=./exported.txt -o main main.c -ldl

使用以上两种方式的任意一种即可,编译之后,再使用 objdump 指令看一下导出符号:

$ objdump -e main -T | grep func_in_main
080485bb g    DF .text	00000019  Base        func_in_main

嗯,很好很好!张三赶紧按照这样的方式操作了一下,果真成功执行了函数!

$ ./main 
func_in_lib is called 
func_in_main 
b = 2

也就是说,在我的动态库文件中,正确的找到了外部其他模块中的函数地址,并且愉快的执行成功了!

锦囊2: 动态注册

虽然执行成功了,张三的心里隐隐约约的仍然有一丝不爽的感觉,每次编译都要导出符号,真麻烦,能不能优化一下?

于是他找到我的主人,表达了自己的不满。

主人一瞧,有个性!既然你不想提供,那我就满足你:

  1. 首先,在动态库中提供一个默认的函数实现(func_in_main_def);

  2. 然后,再提供一个专门的注册函数(register_func),如果外部模块想提供 func_in_main 这个函数,就调用注册函数注册进来;

此时,lib.c 最新的代码就变成这个样子了:

#include <stdio.h>

// 默认实现
void func_in_main_def(void)
{
    printf("the main is lazy, do NOT register me! \n");
}

// 定义外部函数指针
void (*func_in_main)() = func_in_main_def;

void register_func(void (*pf)())
{
    func_in_main = pf;
}

int func_in_lib(int k)
{
    printf("func_in_lib is called \n");

    if (func_in_main)
        func_in_main();

    return k + 1;
}

然后编译,全新的我再一次诞生了 lib.so

gcc -m32 -fPIC --shared -o lib.so lib.c

主人把我丢给张三的时候说:好了,满足你的需求,这一次你不用提供 func_in_main 这个函数了,当然也就不用再导出符号了。

不过,如果如果有一天,你改变了注意,又想提供这个函数了,那么你就要通过动态库中的 register_func 函数,把你的函数注册进来。

Have you got it?赶紧再去试一下!

这个时候,张三再次使用我的时候,就不需要导出他的 main.c 里的那个函数 func_in_main 了,实际上他可以把这个函数从代码中删掉!

编译、执行,张三再一次猛如虎的操作:

$ gcc -m32 -o main main.c -ldl
$ ./main
func_in_lib is called 
the main is lazy, do NOT register me! 
b = 2

嗯,结果看起来是正确的。

咦?怎么多了一行字:the main is lazy, do NOT register me!

难道是在质疑我的技术能力吗?好吧,既然如此,我也满足你,不就是注册一个函数嘛,简单:

// 文件: main.c

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

typedef int (*pfunc)(int);
typedef int (*pregister)(void (*)());

// 控制注册函数的宏定义
#define REG_FUNC

#ifdef REG_FUNC
void func_in_main(void)
{
    printf("func_in_main \n");
}
#endif

int main(int argc, char *agv[])
{
    int a = 1;
    int b;

    // 打开动态库
    void *handle = dlopen("./lib.so", RTLD_NOW);
    if (handle)
    {
#ifdef REG_FUNC
        // 查找动态库中的注册函数
        pregister register_func = (pregister) dlsym(handle, "register_func");
        if (register_func)
        {

            register_func(func_in_main);
        }
#endif

        // 查找动态库中的函数
        pfunc func = (pfunc) dlsym(handle, "func_in_lib");
        if (func)
        {
            b = func(a);
            printf("b = %d \n", b);
        }
        else
        {
            printf("dlsym failed! \n");
        }
        dlclose(handle);
    }
    else
    {
        printf("dlopen failed! \n");
    }
    
    return 0;
}

然后编译、执行:

$ gcc -m32 -o main main.c -ldl
$ ./main 
func_in_lib is called 
func_in_main 
b = 2

完美收官!

PS:很多平台级的代码,例如一些工控领域的运行时(Runtime)软件,大部分都是通过注册的方式,来把平台代码、用户代码进行连接、绑定的。

1.祝融号上火星! 祝融号如何与地球通信呢?

2.一名合格电子工程师,不能避开的“坑”

3.芯片短缺,如何快速上手并替换一款MCU

4.Segger Embedded Studio,试试这个新嵌入式编译器环境!

5.嵌入式项目中使用开源软件需要注意哪些问题??

6.特斯拉突然加速与刹车失灵的可能原因探讨!

免责声明:本文系网络转载,版权归原作者所有。如涉及作品版权问题,请与我们联系,我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。

  • 4
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML、图处理、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值