gdb 8.2 ne reconnaît pas le fichier exécutable sur macOS Mojave 10.14

Question

Je reçois gdb par brew install gdb.

Le contenu du fichier source est:

#include <cstdio> int main(){ int a = 10; for(int i = 0; i< 10; i++){ a += i; } printf("%d
",a); return 0; }

Voici le fichier exécutable nommé 'démo': https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw

Je compile le fichier source comme ceci:

c++ -g -o demo demo.cpp

Et lancez gdb

gdb ./demo

Mais ça ne peut pas marcher. Il ne peut pas reconnaître le fichier exécutable.

GNU gdb (GDB) 8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-Apple-darwin18.0.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos Word" to search for commands related to "Word"... BFD: /Users/xxx/Codes/demo: unknown load command 0x32 BFD: /Users/xxx/Codes/demo: unknown load command 0x32 "/Users/xxx/Codes/demo": not in executable format: file format not recognized

J'utilise file demo, sa sortie est demo: Mach-O 64-bit executable x86_64

J'utilise file ./demo, sa sortie est ./demo: Mach-O 64-bit executable x86_64

Tapez c++ -v, la sortie est:

Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-Apple-darwin18.0.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin

lancez ./demo, sa sortie est 55 tapez show configuration dans gdb, il affiche:

 This GDB was configured as follows: configure --Host=x86_64-Apple-darwin18.0.0 --target=x86_64-Apple-darwin18.0.0 --with-auto-load-dir=:${prefix}/share/auto-load --with-auto-load-safe-path=:${prefix}/share/auto-load --with-expat --with-gdb-datadir=/usr/local/Cellar/gdb/8.2/share/gdb (relocatable) --with-jit-reader-dir=/usr/local/Cellar/gdb/8.2/lib/gdb (relocatable) --without-libunwind-ia64 --without-lzma --without-babeltrace --without-intel-pt --disable-libmcheck --without-mpfr --with-python=/System/Library/Frameworks/Python.framework/Versions/2.7 --without-guile --with-separate-debug-dir=/usr/local/Cellar/gdb/8.2/lib/debug (relocatable)

Qui peut m'aider ? Merci beaucoup !!!

Lilrom · Answer

Le problème est que clang-1000.11.45.2 distribué avec Apple LLVM version 10.0.0 ajoute une nouvelle commande de chargement aux exécutables o-mach nommés LC_BUILD_VERSION.

$ otool -l test.o ... Load command 1 cmd LC_BUILD_VERSION cmdsize 24 platform macos sdk n/a minos 10.14 ntools 0 ...

De la pomme source :

/* * The build_version_command contains the min OS version on which this * binary was built to run for its platform. The list of known platforms and * tool values following it. */

Donc, actuellement, bfd (programme utilisé par gdb pour manipuler les exécutables) n'est pas en mesure d'interpréter cette commande et renvoie l'erreur.

La solution temporaire que j'ai trouvée est de modifier directement les sources bfd avec gdb. Je n'ai testé qu'avec gdb-8.0.1.

Commencez par télécharger les sources gdb-8.0.1 à partir de mirrors . Ajoutez ensuite à gdb-8.0.1/bfd/mach-o.c le code suivant à la ligne 4649:

case BFD_MACH_O_LC_BUILD_VERSION: break;

Et enfin, ajoutez int gdb-8.0.1/include/mach-o/loader.h:

 BFD_MACH_O_LC_BUILD_VERSION = 0x32

à la ligne 189 (n'oubliez pas d'ajouter un , à la fin de la ligne 188 après BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).

Après ces instructions, vous pouvez suivre une compilation gdb classique comme indiqué à l’intérieur du README:

run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install

N'oubliez pas de signer gdb comme expliqué ici . Si vous obtenez toujours l'erreur (os/kern) échec (0x5), exécutez simplement Sudo gdb.

C'est une solution temporaire qui attend que l'équipe GNU résolve le problème directement sur le référentiel.

MODIFIER

Binutils-gdb a été mis à jour, ces modifications sont maintenant implémentées dans commit fc7b364 .

J'espère que ça vous sera utile.

timotheecour · Answer

J'ai publié une formule d'infusion temporaire qui semble fonctionner, en attendant la mise à jour de la préparation d'infusion officielle:

brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb

jww · Answer

Mise à niveau vers GDB version 8.3. Voir également Numéro 23728, binutils échoue sous macOS 10.14 (Mojave) en raison de la commande unimpl du gestionnaire de bogues de Binutils.

Depuis le rapport de bogue :

J'ai trouvé la racine du problème. binutils ne gère pas la charge commande 0x32 LC_BUILD_VERSION (ni 0x31 LC_NOTE, en fait). Elles sont défini dans les versions récentes de LLVM: voir https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77

En regardant la sortie de objdump -private-headers, il y en a une claire différence:
@@ -56,16 +56,18 @@ attributes NO_TOC STRIP_STATIC_SYMS LIVE reserved1 0 reserved2 0 Load command 1 - cmd LC_VERSION_MIN_MACOSX - cmdsize 16 - version 10.13 - sdk n/a + cmd LC_BUILD_VERSION + cmdsize 24 + platform macos + sdk n/a + minos 10.14 + ntools 0 Load command 2 cmd LC_SYMTAB cmdsize 24 
LC_VERSION_MIN_MACOSX est implémenté dans binutils, alors que LC_BUILD_VERSION n'est pas. C'est apparemment nouveau à Mojave.