4

私は、検証テスト スクリプトがテスト対象のソフトウェアのビルド内でシンボル アドレスを見つける必要があるプロジェクトに取り組んでいます。これは、ブレークポイントの設定やメモリからの静的データの読み取りに使用される場合があります。私が求めているのは、シンボル名、メモリ内のベース アドレス、およびサイズを含むマップ ファイルを作成することです。私たちのビルドは、必要な情報を含む ELF ファイルを出力します。readelf、nm、および objdumpツールを使用して、必要なシンボル アドレスを取得しようとしています。

私が最初に試したところreadelf -s file.elf、いくつかのシンボル、特にアセンブラーで記述されたシンボルにアクセスしているように見えました。しかし、私が欲しかったシンボルの多くはそこにありませんでした。特に、Ada コード内で発生したものです。

以前readelf --debug-dump file.elfはすべてのデバッグ情報をダンプしていました。そこから、Ada コードにあったものを含め、すべてのシンボルが表示されます。ただし、形式はDWARF形式のようです。シンボリック情報をリストするように依頼したときに、これらのシンボルが readelf によって出力されない理由を知っている人はいますか? おそらく、私が見逃しているオプションがあるだけです。

カスタム DWARF パーサーを作成して情報を取得することもできますが、Binutils (nm、readelf、objdump) のいずれかを使用して情報を取得できる場合は、標準的なソリューションを使用したいと思います。

4

1 に答える 1

5

DWARF はデバッグ情報であり、元のソース コードの関係を反映しようとします。例として次のコードを取り上げます

static int one() {
  // something
  return 1;
}
int main(int ac, char **av) {
  return one();
}

を使用してコンパイルするとgcc -O3 -g、静的関数oneは にインライン化されmainます。したがって、 を使用するreadelf -sと、記号が表示されることはありませんone。ただし、 を使用すると、インライン化された関数であるreadelf --debug-dumpことがわかります。one

したがって、この例では、コンパイラは での最適化の使用を禁止していない-gため、実行可能ファイルを引き続きデバッグできます。その例では、関数が最適化およびインライン化されていても、gdb は DWARF 情報を使用して、インライン化された関数内の現在のコード ブロックから関数とソース/行を知ることができます。

上記は、コンパイラーの最適化のほんの一例です。readelf -sと DWARFの間でシンボル アドレスの不一致につながる理由はたくさんあります。

于 2015-06-19T01:10:26.987 に答える