Jak wygenerować symbol debugowania gcc poza celem kompilacji?

Wiem, że mogę wygenerować symbol debugowania za pomocą opcji -g. Jednak symbol jest osadzony w pliku docelowym. Czy gcc może wygenerować symbol debugowania poza wynikowym plikiem wykonywalnym / biblioteką? Podobnie jak plik .pdb kompilatora Windows VC ++.

Musisz użyć objcopy, aby oddzielić informacje debugowania :

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

Używam poniższego skryptu bash, aby rozdzielić informacje debugowania na pliki z rozszerzeniem .debug w katalogu .debug. W ten sposób mogę tarować biblioteki i pliki wykonywalne w jednym pliku tar, a katalogi .debug w innym. Jeśli chcę później dodać informacje debugowania, po prostu wyodrębniam plik tar debugowania i voila, mam symboliczne informacje debugowania.

To jest skrypt 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}"

Skompiluj z informacjami debugowania:

gcc -g -o main main.c

Oddziel informacje debugowania:

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

lub

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

Usuń informacje debugowania z pliku pochodzenia:

objcopy --strip-debug main

lub

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

debugowanie w trybie debuglink:

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

Możesz także użyć pliku exec i pliku symboli oddzielnie:

gdb -s main.debug -e main

lub

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

Dla szczegółów:

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

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

Sprawdź opcję „--only-keep-debug” polecenia strip .

Z linku:

Chodzi o to, że ta opcja zostanie użyta w połączeniu z --add-gnu-debuglink do utworzenia dwuczęściowego pliku wykonywalnego. Jeden to okrojony plik binarny, który zajmie mniej miejsca w pamięci RAM i dystrybucji, a drugi to plik informacji debugowania, który jest potrzebny tylko wtedy, gdy wymagane są możliwości debugowania.

UWAGA: Programy skompilowane z wysokimi poziomami optymalizacji (-O3, -O4) nie mogą generować wielu symboli debugowania dla zoptymalizowanych zmiennych, wbudowanych funkcji i rozwiniętych pętli, niezależnie od symboli osadzonych (-g) lub wyodrębnionych (objcopy) w Plik „.debug”.

Są alternatywne podejścia

1. Osadź dane wersjonowania (VCS, git, svn) w programie, aby uzyskać pliki wykonywalne zoptymalizowane pod kątem kompilatora (-O3, -O4).
2. Zbuduj drugą niezoptymalizowaną wersję pliku wykonywalnego.

Pierwsza opcja zapewnia środki do przebudowania kodu produkcyjnego z pełnym debugowaniem i symbolami w późniejszym terminie. Możliwość ponownego zbudowania oryginalnego kodu produkcyjnego bez optymalizacji jest ogromną pomocą przy debugowaniu. (UWAGA: przy założeniu, że testy przeprowadzono przy użyciu zoptymalizowanej wersji programu).

Twój system kompilacji może utworzyć plik .c załadowany z datą kompilacji, zatwierdzeniem i innymi szczegółami VCS. Oto przykład „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

Po skompilowaniu programu możesz zlokalizować oryginalne „zatwierdzenie” dla swojego kodu za pomocą polecenia: 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

Pozostaje tylko pobrać oryginalny kod, ponownie skompilować bez optymalizacji i rozpocząć debugowanie.

Żadna odpowiedź do tej pory nie wspomina eu-strip --strip-debug -f <out.debug> <input>.

• Jest to dostarczane przez elfutilspakiet.
• W rezultacie <input>plik został pozbawiony symboli debugowania, które są teraz w całości <out.debug>.