Подтвердить что ты не робот

gdb 8.2 не может распознать исполняемый файл на macOS Mojave 10.14

Я получаю gdb с помощью brew install gdb.

Содержимое исходного файла:

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

Вот исполняемый файл с именем "demo": https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw

Я компилирую исходный файл следующим образом:

c++ -g -o demo demo.cpp

И запустите gdb

gdb ./demo

Но это не сработает. Он не может распознать исполняемый файл.

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

Я использую file demo, его выход - demo: Mach-O 64-bit executable x86_64

Я использую file./demo, его выход ./demo: Mach-O 64-bit executable x86_64

Тип c++ -v, выход:

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

run ./demo, его вывод представляет собой show configuration типа 55 в gdb, она показывает:

 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)

Кто может мне помочь? Большое спасибо !!!

4b9b3361

ОТВЕТЫ

Ответ 1

Проблема в том, что clang-1000.11.45.2 распространяемый с помощью Apple LLVM version 10.0.0 добавляет новую команду загрузки в исполняемые файлы o-mach с именем 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
...

Из источника яблока:

/*
 * 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.
 */

Таким образом, в настоящее время bfd (программа, используемая gdb для управления исполняемыми bfd) не может интерпретировать эту команду и возвращает ошибку.

Временное решение, которое я нашел, напрямую редактирует источники bfd с помощью gdb. Я тестировал только gdb-8.0.1.

Сначала загрузите источники gdb-8.0.1 из зеркал. Затем добавьте в gdb-8.0.1/bfd/mach-oc следующий код в строке 4649:

case BFD_MACH_O_LC_BUILD_VERSION:
break;

И, наконец, добавьте int gdb-8.0.1/include/mach-o/loader.h:

  BFD_MACH_O_LC_BUILD_VERSION = 0x32

на строке 189 (не забудьте добавить a , в конце строки 188 после BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).

После этих инструкций вы можете следовать классической компиляции gdb как указано в 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

Не забудьте подписать gdb как объясните здесь. Если вы по-прежнему получаете ошибку (os/kern) failure (0x5), просто запустите sudo gdb.

Это временное решение, ожидающее, когда команда GNU решит проблему непосредственно на репо.

РЕДАКТИРОВАТЬ

Обновлен Binutils-gdb, эти изменения теперь реализованы в commit fc7b364.

Надеюсь, это будет полезно.

Ответ 2

Решение @lilrom работало для меня на mojave 10.14.1 - потребовалось некоторое время для установки binutils-gdb.git - и пришлось отредактировать несколько строк форматирования в функции print_insn_powerpc в ppc-dis.c, после чего все было установлено и выполнялось гладко. Настроил его с помощью gcc 8.2.0.

Ответ 4

Переход на GDB 8.3. Также см. Выпуск 23728, binutils терпят неудачу в macOS 10.14 (Mojave) из-за unimpl в трекер Bugutils.

Из отчета об ошибке:

Я нашел корень проблемы. binutils не обрабатывает команду загрузки 0x32 LC_BUILD_VERSION (а не 0x31 LC_NOTE, фактически). Они определены в последних версиях LLVM: см. Https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77

Глядя на вывод objdump -private-headers, есть одна явная разница:

@@ -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 реализован в binutils, а LC_BUILD_VERSION - нет. Это, по-видимому, ново в Мохаве.

Ответ 5

Обновите версию GDB 8.3. Также см. Выпуск 23728, binutils терпят неудачу в macOS 10.14 (Mojave) из-за unimpl в трекер Bugutils.

Из отчета об ошибке:

Я нашел корень проблемы. binutils не обрабатывает команду загрузки 0x32 LC_BUILD_VERSION (а не 0x31 LC_NOTE, фактически). Они определены в последних версиях LLVM: см. Https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77

Глядя на вывод objdump -private-headers, есть одна явная разница:

@@ -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 реализован в binutils, а LC_BUILD_VERSION - нет. Это, по-видимому, ново в Мохаве.

Ответ 6

Я пропустил эту проблему в Mojave, прореживая приложение. GDB не понимает универсальные двоичные файлы. Поэтому, если file myapp сообщает вам, что myapp является универсальным двоичным кодом, попробуйте следующее:

lipo -thin x86_64 -output myapp-x86_64 myapp

А потом

gdb myapp-x86_64