如何檢查共享庫中的哪些符號具有非位置無關代碼（PIC）？

Question

我正在嘗試使用debuild -i -us -uc -b構建一個.deb包，最后我看到：

Now running lintian...
warning: the authors of lintian do not recommend running it with root     privileges!
W: libluajit-5.1-2: hardening-no-relro usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
E: libluajit-5.1-2: shlib-with-non-pic-code usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
W: luajit: hardening-no-relro usr/bin/luajit-2.1.0-alpha
W: luajit: binary-without-manpage usr/bin/luajit-2.1.0-alpha
Finished running lintian.

我有一種預感，我未能定義“PIC代碼設置”，它必須位於每個外部函數的開頭：

The following code might appear in a PIC code setup sequence to compute
the distance from a function entry point to the TOC base:
addis 2,12,.TOC.-func@ha
addi 2,2,.TOC.-func@l

按照ABI第99頁的規定。

但是我找不到非PIC的符號。 或者可能是一些未使用-fPIC編譯的相關文件？

信息：

系統架構：ppc64le

編譯.so庫：gcc -shared -fPIC

Answer 1

要查找哪些符號使您的elf非PIC / PIE（位置scanelf代碼/可執行文件），請使用pax-utils包中的scanelf （在ubuntu上，使用sudo apt-get install pax-utils安裝它）：

$ scanelf -qT /usr/local/lib/libluajit-5.1.so.2.1.0 | head -n 3
  libluajit-5.1.so.2.1.0: buf_grow [0x7694] in (optimized out: previous lj_BC_MODVN) [0x7600]
  libluajit-5.1.so.2.1.0: buf_grow [0x769C] in (optimized out: previous lj_BC_MODVN) [0x7600]
  libluajit-5.1.so.2.1.0: buf_grow [0x76A0] in (optimized out: previous lj_BC_MODVN) [0x7600]
$ objdump -Sa /usr/local/lib/libluajit-5.1.so.2.1.0 | grep -A5 \ 7694:
    7694:       00 00 80 39     li      r12,0
    7698:       c6 07 8c 79     rldicr  r12,r12,32,31
    769c:       00 00 8c 65     oris    r12,r12,0
    76a0:       00 00 8c 61     ori     r12,r12,0
    76a4:       a6 03 89 7d     mtctr   r12
    76a8:       21 04 80 4e     bctrl

在我的情況下，絕對地址意味着加載到r12 ，但這對於動態庫是不可能的，因此鏈接器使用0作為該參數（我必須使用@GOT運算符，但這是我案例的特定解決方案）。

在luajit程序中，可以在鏈接時定義地址，它看起來像這樣：

    1003d0d4:   00 00 80 39     li      r12,0
    1003d0d8:   c6 07 8c 79     rldicr  r12,r12,32,31
    1003d0dc:   07 10 8c 65     oris    r12,r12,4103
    1003d0e0:   30 ca 8c 61     ori     r12,r12,51760
    1003d0e4:   a6 03 89 7d     mtctr   r12

完全不同吧？

在這個精彩的Gentoo wiki頁面上可以找到更詳細的解釋。

Answer 2

失敗的lintian檢查是這樣的：

        # Now that we're sure this is really a shared library, report on
        # non-PIC problems.
        if ($objdump->{$cur_file}->{TEXTREL}) {
            tag 'shlib-with-non-pic-code', $cur_file;
        }

因此，您可以通過查找包含TEXTREL動態部分（正在進入最終鏈接的路徑）的.o來找到有問題的文件。

為此，您可以使用readelf --dyanamic ，如下所示：

find . -name '*.o' |
while read obj
do
    if readelf --dynamic "$obj" | grep -q TEXTREL
    then
        echo "$obj contains a TEXTREL section"
    fi
done