Linux c 運行時獲取動態(tài)庫所在路徑的操作方法

更新時間：2025年06月09日 09:22:34 作者：apocelipes

運行時獲取動態(tài)庫地址除了dladdr和解析/proc/<pid>/maps還可以有一些別的做法,比如可以用nm獲取庫文件的符號表進行對比,但如果庫文件被strip處理過就不能這么用了,本文介紹的兩種方案是泛用性最高的,感興趣的朋友一起看看吧

準備

一般來說動態(tài)庫并不需要關心自己所在的文件系統(tǒng)上的路徑，但業(yè)務有那么多總有一兩個會有特殊需求。

現(xiàn)在給定一個動態(tài)庫里的函數(shù)A，需求是要知道這個函數(shù)A是哪個動態(tài)庫里的以及這個庫的存放路徑。

測試對象有兩個，第一個是標準庫的函數(shù)printf，另一個是我們自己寫的動態(tài)鏈接庫里的PrintRandomText函數(shù)。

自定義動態(tài)庫的名字叫libmycustom1.so，代碼和編譯生成的庫都存放在libmycustom1目錄下。代碼如下：

// lib.h
#pragma once
#include <unistd.h>
#include <sys/random.h>
void PrintRandomText(ssize_t length);
// lib.c
#include <stdio.h>
#include "lib.h"
void PrintRandomText(ssize_t length)
{
    unsigned char buff[64] = {0};
    length = (length + 1) / 2;
    if (length == 0) {
        return;
    }
    while (1) {
        ssize_t count = getrandom(buff, 64, 0);
        count = length > count ? count : length;
        for (ssize_t i = 0; i < count; ++i) {
            printf("%02X", buff[i]&0xff);
        }
        if (length <= count) {
            break;
        }
        length -= count;
    }
    printf("\n");
}

函數(shù)很簡單，從Linux的/dev/urandom隨機設備中讀取指定大小的數(shù)據(jù)然后打印輸出，編譯使用如下命令：

gcc -Wall -O2 -fPIC -shared lib.c -o libmycustom1.so

這樣我們就得到了libmycustom1/libmycustom1.so。下面可以介紹如何在運行時獲取動態(tài)庫的路徑了。

使用dladdr獲取動態(tài)庫路徑

第一種方法是使用dladdr這個函數(shù)。dladdr是libdl.so中的一個函數(shù)，用來獲取某個地址對應的動態(tài)庫信息，而libdl是Linux上專門用來處理動態(tài)鏈接庫的函數(shù)庫。

dladdr獲取的信息中恰巧有動態(tài)庫的實際存放路徑這一信息，我們可以加以利用：

#define _GNU_SOURCE // 這行不能少
#include <dlfcn.h>  // for dladdr
#include <stdio.h>
#include "libmycustom1/lib.h"
int main()
{
        Dl_info info1, info2;
        if (dladdr((void*)&printf, &info1) == 0) {
                fprintf(stderr, "cannot get printf's info\n");
                return 1;
        }
        if (dladdr((void*)&PrintRandomText, &info2) == 0) {
                fprintf(stderr, "cannot get PrintRandomText's info\n");
                return 1;
        }
        // 還需要檢查dli_fname字段是否是NULL，這里就省略了
        printf("lib contains printf: %s\n", info1.dli_fname);
        printf("lib contains PrintRandomText: %s\n", info2.dli_fname);
}

dladdr在出錯的時候會返回0，這時可以用dlerror來獲取具體的報錯，不過這里我為了簡單起見就省略了。

編譯運行需要下面的命令：

$ gcc a.c -L./libmycustom1 -lmycustom1 -ldl
$ export LD_LIBRARY_PATH=./libmycustom1
$ ./a.out
lib contains printf: /lib/x86_64-linux-gnu/libc.so.6
lib contains PrintRandomText: ./libmycustom1/libmycustom1.so

編譯時還需要鏈接libdl。

因為庫沒有放在默認的系統(tǒng)搜索路徑里，也沒有單獨設置ld.cache，因此我們需要設置環(huán)境變量LD_LIBRARY_PATH來告訴加載器我們的動態(tài)庫在哪里。

可以看到對于存放在標準路徑里的libc，dladdr給出了絕對路徑，對于我們自定義的庫，因為LD_LIBRARY_PATH設置成了相對路徑，所以給我們的結果也是相對路徑的。因此dladdr拿到的結果最好得先做一次相對路徑到絕對路徑的轉換再使用。

dladdr受到廣泛的支持，基本主要的Linux發(fā)行版上都能使用，因此實際中大家也都在用它，但它還是有幾個缺點：

函數(shù)指針轉void*在c/c++標準中都是不允許的，而且實際也有函數(shù)指針是胖指針的平臺存在，但至少這一行為在x86_64和arm的gcc/clang上都沒啥問題
dladdr只能正常獲取使用-fPIC編譯成位置不相關代碼的動態(tài)庫信息，這個信息也不一定準確。

綜上dladdr雖然能用，但不通用，而且可靠性也一般。

正如我在文章開頭就說了，這次討論的方案沒有可移植性，需要限定在具體的系統(tǒng)和硬件平臺上使用。

使用proc maps文件獲取動態(tài)庫路徑

如果我不想再額外鏈接一個庫，尤其是還得在文件開頭定義#define _GNU_SOURCE，那么就需要使用方案二了。

方案二很簡單也很直接，讀取進程的/proc/<pid>/maps，對比地址范圍就能找到函數(shù)所在的動態(tài)庫以及庫的路徑。

Linux加載動態(tài)鏈接庫是用的類似mmap的形式，庫實際只會被加載一次，然后被映射到每個需要這個庫的進程的地址空間里。

而/proc/<pid>/maps記載了進程的內(nèi)存地址空間里所有的mmap映射的文件，包括普通文件、共享庫和匿名映射。當然這個文件里還包含了vdso和代碼段等的內(nèi)存地址，總體上來說可以算作進程的內(nèi)存空間分布概覽。一個例子是：

55bce8e1c000-55bce8e1d000 r--p 00000000 08:20 3337                       /home/apocelipes/dladdrtest/a.out
55bce8e1d000-55bce8e1e000 r-xp 00001000 08:20 3337                       /home/apocelipes/dladdrtest/a.out
55bce8e1e000-55bce8e1f000 r--p 00002000 08:20 3337                       /home/apocelipes/dladdrtest/a.out
55bce8e1f000-55bce8e20000 r--p 00002000 08:20 3337                       /home/apocelipes/dladdrtest/a.out
55bce8e20000-55bce8e21000 rw-p 00003000 08:20 3337                       /home/apocelipes/dladdrtest/a.out
55bd039bf000-55bd039e0000 rw-p 00000000 00:00 0                          [heap]
7f7bffb36000-7f7bffb39000 rw-p 00000000 00:00 0
7f7bffb39000-7f7bffb61000 r--p 00000000 08:20 49817                      /usr/lib/x86_64-linux-gnu/libc.so.6
7f7bffb61000-7f7bffce9000 r-xp 00028000 08:20 49817                      /usr/lib/x86_64-linux-gnu/libc.so.6
7f7bffce9000-7f7bffd38000 r--p 001b0000 08:20 49817                      /usr/lib/x86_64-linux-gnu/libc.so.6
7f7bffd38000-7f7bffd3c000 r--p 001fe000 08:20 49817                      /usr/lib/x86_64-linux-gnu/libc.so.6
7f7bffd3c000-7f7bffd3e000 rw-p 00202000 08:20 49817                      /usr/lib/x86_64-linux-gnu/libc.so.6
7f7bffd3e000-7f7bffd4b000 rw-p 00000000 00:00 0
7f7bffd53000-7f7bffd54000 r--p 00000000 08:20 3397                       /home/apocelipes/dladdrtest/libmycustom1/libmycustom1.so
7f7bffd54000-7f7bffd55000 r-xp 00001000 08:20 3397                       /home/apocelipes/dladdrtest/libmycustom1/libmycustom1.so
7f7bffd55000-7f7bffd56000 r--p 00002000 08:20 3397                       /home/apocelipes/dladdrtest/libmycustom1/libmycustom1.so
7f7bffd56000-7f7bffd57000 r--p 00002000 08:20 3397                       /home/apocelipes/dladdrtest/libmycustom1/libmycustom1.so
7f7bffd57000-7f7bffd58000 rw-p 00003000 08:20 3397                       /home/apocelipes/dladdrtest/libmycustom1/libmycustom1.so
7f7bffd58000-7f7bffd5a000 rw-p 00000000 00:00 0
7f7bffd5a000-7f7bffd5b000 r--p 00000000 08:20 49814                      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7bffd5b000-7f7bffd86000 r-xp 00001000 08:20 49814                      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7bffd86000-7f7bffd90000 r--p 0002c000 08:20 49814                      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7bffd90000-7f7bffd92000 r--p 00036000 08:20 49814                      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7bffd92000-7f7bffd94000 rw-p 00038000 08:20 49814                      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7fff6ded9000-7fff6defb000 rw-p 00000000 00:00 0                          [stack]
7fff6dfaa000-7fff6dfae000 r--p 00000000 00:00 0                          [vvar]
7fff6dfae000-7fff6dfb0000 r-xp 00000000 00:00 0                          [vdso]

可以看到libc和我們自己的庫都被記載進文件里了。每行內(nèi)容是空格分開的，對于匿名映射不會有最后的路徑。第一列的就是內(nèi)存地址，以“-”連字符分隔，第一部分是內(nèi)存映射區(qū)域開始地址，第二部分是結束地址。

這和獲取函數(shù)對應的動態(tài)庫有什么關系呢？關系肯定是有的，在Linux上動態(tài)庫里的“函數(shù)”其實就是一段編譯好的代碼，加載進內(nèi)存后它也會占用一段內(nèi)存空間，調(diào)用動態(tài)庫函數(shù)的時候?qū)嶋H上是下面這樣的流程：

根據(jù)函數(shù)名稱跳轉到對應的符號表項目上
檢查函數(shù)是否被加載，有加載就跳過下面步驟直接到4
未加載時loader會去動態(tài)庫文件里讀取對應函數(shù)的代碼，存入內(nèi)存，然后把項目內(nèi)容用代碼在內(nèi)存里的起始地址覆蓋
程序跳轉到函數(shù)代碼所在的內(nèi)存地址上，開始一條條加載執(zhí)行這些代碼

加載進內(nèi)存的代碼權限是r-xp，代表內(nèi)存里的內(nèi)容可以被執(zhí)行。

現(xiàn)在出于安全考慮有些程序會使用編譯選項把這些工作提前到程序加載運行時就完成，但大致上是一樣的。被加載的函數(shù)的內(nèi)存會被記載進maps文件，所以我們只要讀取maps文件然后對比內(nèi)存地址范圍，就能知道函數(shù)對應的庫和路徑了。

因為我們只看函數(shù)地址，因此不用查的太細，只要地址在范圍內(nèi)就可以，無需查看權限。知道原理后就可以寫個腳本去解析了：

local function searchAddr(pid, addr)
    local file = io.open("/proc/" .. pid .. "/maps", "r")
    if not file then
        print("進程不存在: " .. pid)
        return
    end
    for line in file:lines() do
        local parts = {}
        for word in line:gmatch("%S+") do
            table.insert(parts, word)
        end
        if #parts > 5 then
            local addrParts = {}
            for addr in parts[1]:gmatch("[^%-]+") do
                table.insert(addrParts, addr)
            end
            if #addrParts == 2 then
                local startAddr = tonumber(addrParts[1], 16) or 0
                local endAddr = tonumber(addrParts[2], 16) or 0
                if startAddr <= addr and addr < endAddr then
                        print(parts[#parts])
                        break;
                end
            end
        end
    end
    file:close()
end
if #arg ~= 2 then
        print("no enough args")
        os.exit(1)
end
local addr = tonumber(arg[2]) or 0
if addr == 0 then
        print("addr can not be 0")
        os.exit(1)
end
searchAddr(arg[1], addr)

c語言處理字符串太折磨了，所以我用lua偷個懶，代碼就不解釋了因為很簡單，你可以讓ai代勞解讀一下。

進程退出后proc文件也就沒了，所以測試代碼也得改一下不要讓進程那么快退出：

#include <stdio.h>
#include "libmycustom1/lib.h"
int main()
{
    printf("pid %d\n", getpid());
    printf("printf address: %p\n", (void*)&printf);
    printf("PrintRandomText address: %p\n", (void*)&PrintRandomText);
    pause(); // 阻塞進程直到收到信號
}

運行結果：