web-dev-qa-db-de.com

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

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\n",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 !!!

27
food far

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.

9
Lilrom

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

2
timotheecour

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.

1
jww

Ich habe eine gute Lösung für mich von Stack Overflow und ich weiß nicht, warum es funktioniert ..__ Hier ist der Link .

Ich bin neu bei macOS und mache folgendes:

  1. Codieren Sie gdb 8.0.1 in High Sierra
  2. Aktualisieren Sie auf Mojave
  3. gdb 8.0.1 ist mit BFD: /Users/xxx/Codes/demo: unknown load command 0x32 gestorben
  4. Wechseln Sie zu gdb 8.2.1 und stoßen Sie auf den Schlüsselbundfehler Unknown Error -2,147,414,007.

    Lösen Sie dieses Problem, indem Sie das Zertifikat in Login abrufen, dann exportieren und in System importieren (Löschen Sie es aus dem Login, wenn der Import nicht möglich ist).

  5. Schließlich funktioniert es wegen irgendwelcher Fehler immer noch nicht und es kommt mit ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8)), laut wie man Codesign rückgängig macht , es ist noch etwas Falsches und die Antwort sagt mir brew reinstall gdb, aber es funktioniert immer noch nicht nannte es gestern einen Tag.
  6. Endlich stoße ich auf diesen Link , ich bin glücklich, jetzt kann ich debuggen!

Hoffe meine Lösung kann helfen.

0
Karl Han

gdb 8.2 von Homebrew installiert ist nicht kompatibel mit Mac Mojave. Ich habe ein Upgrade auf 8.2.1. Das Problem sollte behoben sein.

0
Pin

Ich habe gdb bei Mojave von:

a) das neueste gdb-Quellarchiv (zum Zeitpunkt des Schreibens, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz ) erhalten , fügt es eine Möglichkeit hinzu, ausführbare Dateien auf dem Mac zu erkennen.

b) bauen Sie gdb auf. Ich habe Fehler beim Variablen-Shadowing in darwin-nat.c bekommen, also habe ich die Datei bearbeitet und neu erstellt.

c) Befolgen Sie die Schritte in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html

Voila.

(Quelle: GDB auf Mac/Mojave: Programm während des Startvorgangs mit Signal beendet?, Unbekanntes Signal )

0
Joubert Nel