gdb 8.2 kann keine ausführbare Datei unter macOS Mojave 10.14 erkennen

Question

Ich bekomme gdb von brew install gdb.

Der Inhalt der Quelldatei lautet:

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

Hier ist die ausführbare Datei "demo": https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw

Ich kompiliere die Quelldatei folgendermaßen:

c++ -g -o demo demo.cpp

Und gdb ausführen

gdb ./demo

Aber es kann nicht funktionieren. Die ausführbare Datei kann nicht erkannt werden.

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

Ich benutze file demo, sein Ausgang ist demo: Mach-O 64-bit executable x86_64

Ich benutze file ./demo, die Ausgabe ist ./demo: Mach-O 64-bit executable x86_64

Typ c++ -v, Ausgabe ist:

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

./demo ausführen, die Ausgabe ist 55 type show configuration in gdb, es zeigt:

 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)

Wer kann mir helfen ? Vielen Dank !!!

Lilrom · Answer

Das Problem ist, dass clang-1000.11.45.2, verteilt mit Apple LLVM version 10.0.0, einen neuen Ladebefehl zu den ausführbaren Dateien von o-mach namens LC_BUILD_VERSION hinzufügt.

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

Aus dem Apple 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. */

Derzeit kann bfd (Programm, das von gdb zum Bearbeiten von ausführbaren Dateien verwendet wird) diesen Befehl nicht interpretieren und gibt den Fehler zurück.

Die temporäre Lösung, die ich gefunden habe, ist die direkte Bearbeitung von bfd sources mit gdb. Ich habe nur mit gdb-8.0.1 getestet.

Laden Sie zunächst gdb-8.0.1-Quellen von mirrors herunter. Fügen Sie dann in gdb-8.0.1/bfd/mach-o.c den folgenden Code in Zeile 4649 hinzu:

case BFD_MACH_O_LC_BUILD_VERSION: break;

Fügen Sie schließlich int gdb-8.0.1/include/mach-o/loader.h hinzu:

 BFD_MACH_O_LC_BUILD_VERSION = 0x32

in Zeile 189 (vergessen Sie nicht, am Ende der Zeile 188 nach , einen BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30 hinzuzufügen).

Nach diesen Anweisungen können Sie einer klassischen gdb-Kompilierung folgen, wie in README angegeben:

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

Vergessen Sie nicht, gdb als erklären hier ..__ zu signieren. Wenn der Fehler (os/kern) (0x5) immer noch auftritt, führen Sie einfach Sudo gdb aus.

Dies ist eine temporäre Lösung, die darauf wartet, dass das GNU - Team das Problem direkt auf dem Repo löst.

EDIT

Binutils-gdb wurde aktualisiert, diese Änderungen wurden nun in commit fc7b364 implementiert.

Hoffe es wird hilfreich sein.

timotheecour · Answer

Ich habe eine temporäre Brew-Formel veröffentlicht, die scheinbar funktioniert, während ich auf die Aktualisierung der offiziellen Brew-Formel warte:

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

jww · Answer

Aktualisieren Sie auf GDB Version 8.3. Siehe auch Ausgabe 23728, binutils auf macOS 10.14 (Mojave) aufgrund von unimpl im Binutils Bug Tracker fehlgeschlagen.

Aus dem Fehlerbericht :

Ich habe die Wurzel des Problems gefunden. binutils behandelt das Laden nicht Befehl 0x32 LC_BUILD_VERSION (noch 0x31 LC_NOTE). Sie sind in den letzten LLVM-Versionen definiert: siehe https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77

Betrachtet man die Ausgabe von objdump -private-Headern, so ist dies eindeutig Unterschied:
@@ -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 ist in binutils implementiert, während LC_BUILD_VERSION ist nicht. Es ist anscheinend neu in Mojave.