_dl_start
シンボルはld-linux-x86-64.so.2
(動的ローダー) にあり、そのシンボルはld -linux にプライベートです。つまり、プログラム内からそれを見つける唯一の方法は、GDB と同じことを行うことです。つまり、 のシンボル テーブルを読み取り、ld-linux
"_dl_start" 関数を (名前で) 検索します。(Martinが提案したように)直接リンクすることはできず、機能しません(すでに発見したように)。
ELF シンボル テーブルの読み取りはそれほど複雑ではありません。セクションを見つけ.symtab
て、エントリのテーブルとして読み取る必要があります。または(ここから開始) を使用します。.strtab
.symtab
Elf64_Sym
libelf
追加の複雑さは、ld-linux
取り除かれる可能性があることです (機能するためにシンボルテーブルは必要ありません)。それが除去された場合、GDB もプログラムも を見つけることができなくなります_dl_start
。
最後に、検索の試み_dl_start
が無意味である可能性があります。この関数は、プログラムの最初の命令が実行されるずっと前に呼び出されることに気付きます。あなたが をヒットするまでに、は長い間終了しており、二度と呼び出されることはありません。main
_dl_start
更新:
gdb が ld-linux で _dl_start のアドレスを取得する方法についてはまだ疑問に思っています (削除されています)。
が削除されている場合ld-linux
、GDB はそれを見つけることができません_dl_start
。あなたはGDBがそれを見つけるので、どちらか
- あなた
ld-linux
が実際にストリップされていない、または
- glibc 用の「個別の debuginfo」パッケージがインストールされています。
ld-linux
が本当に完全に削除されていることを確認するには、 and を実行nm /lib64/ld-linux-x86-64.so.2 | grep _dl_start
しreadelf -S /lib64/ld-linux-x86-64.so.2 | grep symtab
ます。どちらのコマンドも出力を生成しません。
GDB がシンボルをロードしている場所を確認するには、set print symbol-loading on
(実行可能ファイルを実行する前に) コマンドを使用できます。
_dl_start を呼び出して (スタックを準備し、補助ベクトルを調整した後)、既にメモリに格納されているプログラムの実行可能イメージ (ファイル表現) を作成したかったのです...
それがどのように機能するのかわかりません。は、呼び出される前に特定の状態 (たとえば、そのグローバル変数がゼロに設定されている) を想定しているため、補助ベクトルを調整しなくても、再度_dl_start
呼び出すとアサーションが失敗する可能性が非常に高くなります。そして、(明らかに)あなたの目標である自明ではない方法でauxベクトルを調整すると、アサートの可能性がさらに高くなります。