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

Question

Я получаю 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, его вывод 55 type show configuration в ГБД, он показывает:

 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)

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

Answer 1

Я заставил GDB работать с Mojave следующим образом:

a) получить последнюю версию исходного архива GDB (на момент написания ftp: //sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz ) - помимо прочего, добавлена ​​обработка для распознавания исполняемых файлов на Mac.

b) сборка gdb.Я получил ошибки для теневого копирования переменных в darwin-nat.c, поэтому я отредактировал файл и перестроил.

c) выполните шаги в https://forward -in-code.blogspot.com / 2018/11 /mojave-vs-gdb.html

Вуаля.

(источник: GDB на Mac / Mojave: во время запуска программы прекращается с сигналом?, неизвестный сигнал )

Answer 2

GDB 8.2, установленный из Homebrew, не совместим с Mac mojave.У меня обновление до 8.2.1.Проблема должна быть решена.

Answer 3

У меня есть хорошее решение от переполнения стека, и я не знаю, почему оно работает.Вот ссылка .

Я новичок в macOS, и я делаю следующее:

1. Codesign GDB 8.0.1 в высокой Сьерра
2. Обновление до Мохаве
3. GDB 8.0.1 умер с BFD: /Users/xxx/Codes/demo: unknown load command 0x32
4. Перейдите на GDB 8.2.1 и столкнетесь с ошибкой Связки ключей Unknown Error -2,147,414,007.

   Решите это, получив сертификат в Login, затем экспортируйте его и импортируйте в System (удалите его из логина, если не удается импортировать).

5. Наконец, из-за каких-то ошибок он все еще не работает и поставляется с 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)), в соответствии с как отменить кодовый знак , что-то не так все еще существует, и ответ говорит мне brew reinstall gdb, но это все ещене работает, я вчера звонил.
6. Наконец-то я наткнулся на эту ссылку , Я СЧАСТЛИВ, теперь я могу отлаживать!

Надеюсь, моё решение может помочь.

Answer 4

Обновление до GDB версии 8.3.Также см. Проблема 23728, ошибка binutils в macOS 10.14 (Mojave) из-за unimpl в трекере ошибок Binutils.

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

Я нашел корень проблемы.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 нет.Это очевидно новый в Мохаве.

Answer 5

Я опубликовал временную формулу приготовления, которая, кажется, работает, ожидая обновления официальной формулы приготовления:

установка brew https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb

Answer 6

Проблема в том, что 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
...

Из источника apple :

/*
 * 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 источники предоставляют gdb.Я тестировал только с gdb-8.0.1.

Сначала загрузите gdb-8.0.1 источников с зеркал .Затем добавьте к gdb-8.0.1/bfd/mach-o.c следующий код в строке 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 (нене забудьте добавить , в конце строки 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 как объясните здесь .Если вы по-прежнему получаете сообщение об ошибке (0/5) (os / kern), просто запустите sudo gdb.

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

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

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

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

Answer 7

Я решил эту проблему в Мохаве, поредев в приложении.GDB не понимает универсальные двоичные файлы.Так что если file myapp говорит вам, что myapp является универсальным двоичным файлом, попробуйте это:

lipo -thin x86_64 -output myapp-x86_64 myapp

А затем

gdb myapp-x86_64