当共享库已经映射到进程空间时,是否可以编写XS模块



这是我所知道的极限,请纠正这里的任何困惑。在这个问题中,我问为什么libm提供的功能还没有通过Perl接口向用户公开。现在我想知道它是怎么做的。

CPAN上有一个模块声称可以做到Math::Libm。这很好,但作为一个实现问题,当我使用它时,我发现libm不仅像Debian上任何运行的Perl解释器一样映射到进程中,

7f719246d000-7f719247c000 r--p 00000000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f719247c000-7f7192516000 r-xp 0000f000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f7192516000-7f71925af000 r--p 000a9000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f71925af000-7f71925b0000 r--p 00141000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f71925b0000-7f71925b1000 rw-p 00142000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so

但是Math::Libm也映射在另一个libm共享对象中

7fb649043000-7fb649044000 r--p 00000000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb649044000-7fb649049000 r-xp 00001000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb649049000-7fb64904a000 r--p 00006000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb64904a000-7fb64904b000 r--p 00006000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb64904b000-7fb64904c000 rw-p 00007000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so

这似乎是因为Autoloader加载了外部共享对象。

是否可以在不加载外部共享对象的情况下访问驻留进程中已经存在的符号?

是否可以在不加载外部共享对象的情况下访问驻留进程中已经存在的符号?

您需要加载XSLibm.so才能从Perl访问C库函数,但当在运行时使用dlopen()加载Libm.so时(请参见dl_load_file(((,动态加载程序将识别出Libm.so需要libm.so,但由于libm.so已经由动态链接器加载(当运行Perl本身时(,它不会被重新加载,但会返回一个现有的文件句柄,请参阅这个Q&A、 因此共享库CCD_ 11不会被加载两次。

脚注

†:但也可参见C::DynaLib和FFI::Platypus,了解不需要XS 的替代品

相关内容

  • 没有找到相关文章

最新更新