ビルドターゲットの外でgccデバッグシンボルを生成する方法は?


176

-gオプションを使用してデバッグシンボルを生成できることを知っています。ただし、シンボルはターゲットファイルに埋め込まれます。gccは結果の実行可能ファイル/ライブラリの外部でデバッグシンボルを生成できますか?Windowsの.pdbファイルと同じように、VC ++コンパイラーが行いました。

回答:


184

デバッグ情報分離するには、objcopyを使用する必要があります

objcopy --only-keep-debug "${tostripfile}" "${debugdir}/${debugfile}"
strip --strip-debug --strip-unneeded "${tostripfile}"
objcopy --add-gnu-debuglink="${debugdir}/${debugfile}" "${tostripfile}"

以下のbashスクリプトを使用して、デバッグ情報を.debugディレクトリの.debug拡張子を持つファイルに分離します。このようにして、ライブラリと実行可能ファイルを1つのtarファイルで.debugディレクトリを別のtarファイルでtarできます。後でデバッグ情報を追加する場合は、デバッグtarファイルを抽出して、シンボリックデバッグ情報を取得します。

これはbashスクリプトです:

#!/bin/bash

scriptdir=`dirname ${0}`
scriptdir=`(cd ${scriptdir}; pwd)`
scriptname=`basename ${0}`

set -e

function errorexit()
{
  errorcode=${1}
  shift
  echo $@
  exit ${errorcode}
}

function usage()
{
  echo "USAGE ${scriptname} <tostrip>"
}

tostripdir=`dirname "$1"`
tostripfile=`basename "$1"`


if [ -z ${tostripfile} ] ; then
  usage
  errorexit 0 "tostrip must be specified"
fi

cd "${tostripdir}"

debugdir=.debug
debugfile="${tostripfile}.debug"

if [ ! -d "${debugdir}" ] ; then
  echo "creating dir ${tostripdir}/${debugdir}"
  mkdir -p "${debugdir}"
fi
echo "stripping ${tostripfile}, putting debug info into ${debugfile}"
objcopy --only-keep-debug "${tostripfile}" "${debugdir}/${debugfile}"
strip --strip-debug --strip-unneeded "${tostripfile}"
objcopy --add-gnu-debuglink="${debugdir}/${debugfile}" "${tostripfile}"
chmod -x "${debugdir}/${debugfile}"

8
運用に問題があり、gdbでプロセスをアタッチする必要がある場合、デバッグシンボルファイルをGDBに提供できますか?そして、どのように、そうであれば?thnx
yves Baumes、2009年

3
@yves Baumes .debugファイルを含む.debugディレクトリを製品ボックスに追加するだけで、GDBがそれらを取得します。デバッグセッションの後で、それらを再度削除できます。
ローター

例については、@ Lance Richardson回答コメントを参照してください。
GuruM 2013

7
元のバイナリを復元することもできますか(たとえば、ストリップされたバイナリ+ .debugファイル=元のバイナリ)。
Paul Praet 2013年

1
--build-idリンカオプションの省略に問題がありますか?
jww 2018

110

デバッグ情報を使用してコンパイルします。

gcc -g -o main main.c

デバッグ情報を分離します。

objcopy --only-keep-debug main main.debug

または

cp main main.debug
strip --only-keep-debug main.debug

元のファイルからデバッグ情報を取り除く:

objcopy --strip-debug main

または

strip --strip-debug --strip-unneeded main

debuglinkモードによるデバッグ:

objcopy --add-gnu-debuglink main.debug main
gdb main

execファイルとシンボルファイルを別々に使用することもできます。

gdb -s main.debug -e main

または

gdb
(gdb) exec-file main
(gdb) symbol-file main.debug

詳細については:

(gdb) help exec-file
(gdb) help symbol-file

参照:
https : //sourceware.org/gdb/onlinedocs/gdb/Files.html#Files https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html


2
また、使用objcopy --add-gnu-debuglink main main.debugして、作成したデバッグファイルの名前とチェックサムを埋め込む必要があります。この場合、gdbはいくつかの配布に依存する場所でデバッグコード自体を見つけようとします。-sオプションはもう必要ありません。
Lothar

9

stripコマンドの「--only-keep-debug」オプションを確認してください。

リンクから:

このオプションは、2つの部分からなる実行可能ファイルを作成するために--add-gnu-debuglinkと組み合わせて使用​​されることを意図しています。1つはRAMとディストリビューションで占有するスペースが少ないストリップバイナリ、もう1つはデバッグ機能が必要な場合にのみ必要なデバッグ情報ファイルです。


1
はい、試しました:gcc -ggdb -o test test.c; cp test test.debug; strip --only-keep-debug test.debug; ストリップテスト; objcopy --add-gnu-debuglink = test.debug test; その後、テストをデバッグして
かまいません

8

注:高最適化レベル(-O3、-O4)でコンパイルされたプログラムは、最適化された変数、インライン関数、および展開されたループに対して多くのデバッグシンボルを生成できません。 「.debug」ファイル。

代替アプローチは

  1. コンパイラー最適化実行可能ファイル(-O3、-O4)のバージョン管理(VCS、git、svn)データをプログラムに埋め込みます。
  2. 実行可能ファイルの2番目の非最適化バージョンをビルドします。

最初のオプションは、後で完全なデバッグとシンボルを使用して製品コードを再構築する手段を提供します。最適化なしで元の製品コードを再構築できることは、デバッグに非常に役立ちます。(注:これは、テストがプログラムの最適化されたバージョンで行われたと想定しています)。

ビルドシステムは、コンパイル日、コミット、およびその他のVCS詳細がロードされた.cファイルを作成できます。以下は 'make + git'の例です。

program: program.o version.o 

program.o: program.cpp program.h 

build_version.o: build_version.c    

build_version.c: 
    @echo "const char *build1=\"VCS: Commit: $(shell git log -1 --pretty=%H)\";" > "$@"
    @echo "const char *build2=\"VCS: Date: $(shell git log -1 --pretty=%cd)\";" >> "$@"
    @echo "const char *build3=\"VCS: Author: $(shell git log -1 --pretty="%an %ae")\";" >> "$@"
    @echo "const char *build4=\"VCS: Branch: $(shell git symbolic-ref HEAD)\";" >> "$@"
    # TODO: Add compiler options and other build details

.TEMPORARY: build_version.c

プログラムがコンパイルされたら、次のコマンドを使用して、コードの元の「コミット」を見つけることができます。 strings -a my_program | grep VCS

VCS: PROGRAM_NAME=my_program
VCS: Commit=190aa9cace3b12e2b58b692f068d4f5cf22b0145
VCS: BRANCH=refs/heads/PRJ123_feature_desc
VCS: AUTHOR=Joe Developer  joe.developer@somewhere.com
VCS: COMMIT_DATE=2013-12-19

あとは、元のコードをチェックアウトし、最適化せずに再コンパイルして、デバッグを開始するだけです。


3
-O4さえ存在しません。
Hi-Angel

3
おっと、それは「suncc」日である可能性があり、「-O5」もオプションでした。ここでgcc4.4.7の-Oオプションへのリンクです:gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/...
J Jorgenson

3
これは、簡単に再現できない可能性があるコアダンプを解釈しようとするという一般的な問題には対応していません。この答えでアドバイスは健全である、しかしそれは質問には対応していません。
デビッドロドリゲス-2016年

4

これまでのところ回答はありませんeu-strip --strip-debug -f <out.debug> <input>

  • これはelfutilsパッケージで提供されます。
  • その結果、<input>ファイルからデバッグシンボルが削除され、すべてがに含まれるようになり<out.debug>ます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.