gdb 8.2 no puede reconocer el archivo ejecutable en macOS Mojave 10.14

Question

Obtengo gdb por brew install gdb .

El contenido del archivo fuente es:

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

Aquí está el archivo ejecutable llamado ''demo'': https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw

Compilo el archivo fuente de esta manera:

c++ -g -o demo demo.cpp

Y ejecuta gdb

gdb ./demo

Pero, no puede funcionar. No se puede reconocer el archivo ejecutable.

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

Utilizo el file demo , su salida es demo: Mach-O 64-bit executable x86_64

Yo uso el file ./demo , su salida es ./demo: Mach-O 64-bit executable x86_64

Escriba c++ -v , la salida es:

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

ejecute ./demo , su salida es de tipo 55 show configuration en gdb, muestra:

 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én puede ayudarme ? Muchas gracias !!!

Answer 1

Actualizar a GDB versión 8.3. También vea el problema 23728, binutils falla en macOS 10.14 (Mojave) debido a unimpl en el rastreador de errores de Binutils.

Desde el informe de error :

He encontrado la raíz del problema. binutils no maneja el comando de carga 0x32 LC_BUILD_VERSION (ni 0x31 LC_NOTE, en realidad). Se definen en versiones recientes de LLVM: consulte https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77

En cuanto a la salida de objdump -private-headers hay una clara diferencia:

@@ -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 se implementa en binutils, mientras que LC_BUILD_VERSION no se implementa. Aparentemente es nuevo en Mojave.

Answer 2

El problema es que clang-1000.11.45.2 distribuido con Apple LLVM version 10.0.0 agrega un nuevo comando de carga a los ejecutables de O-Mach llamados 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 source la manzana:

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

Por lo tanto, actualmente bfd (programa utilizado por gdb para manipular ejecutables) no puede interpretar este comando y devuelve el error.

La solución temporal que encontré es editar directamente las fuentes bfd proporcionadas con gdb . Sólo he probado con gdb-8.0.1 .

Primero, descargue gdb-8.0.1 fuentes gdb-8.0.1 de los mirrors . Luego agregue a gdb-8.0.1/bfd/mach-oc el siguiente código en la línea 4649 :

case BFD_MACH_O_LC_BUILD_VERSION:
break;

Y finalmente agregue int gdb-8.0.1/include/mach-o/loader.h :

 BFD_MACH_O_LC_BUILD_VERSION = 0x32

en la línea 189 (no olvide agregar una , al final de la línea 188 después de BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30 ).

Después de estas instrucciones, puede seguir una compilación gdb clásica como se indica dentro de 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

No te olvides de firmar gdb como se explica here . Si aún recibe el error (os / kern) error (0x5), simplemente ejecute sudo gdb .

Esta es una solución temporal que espera a que el equipo de GNU solucione el problema directamente en el repositorio.

EDITAR

Binutils-gdb se ha actualizado, estos cambios ahora se implementan en el commit fc7b364 .

Espero que te sea de ayuda.

Answer 3

Publiqué una fórmula de preparación temporal que parece funcionar, mientras esperaba la actualización de la fórmula de preparación oficial:

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

Answer 4

Superé este problema en Mojave adelgazando la aplicación. GDB no entiende los binarios universales. Entonces, si el file myapp le dice que myapp es un binario universal, intente esto:

lipo -thin x86_64 -output myapp-x86_64 myapp

Y entonces

gdb myapp-x86_64

Answer 5

Tengo una buena solución para mí desde el desbordamiento de pila y no sé por qué funciona. Aquí está el link .

Soy nuevo en macOS, y hago lo siguiente:

1. Codesign gdb 8.0.1 en alta sierra
2. Actualizacion a Mojave
3. gdb 8.0.1 murió con BFD: /Users/xxx/Codes/demo: unknown load command 0x32
4. Cambie a gdb 8.2.1 y encuentre el error de Llavero Error Unknown Error -2,147,414,007 .

   Resuelva esto obteniendo el certificado en Login de Login luego expórtelo e impórtelo en el System (elimínelo de Inicio de sesión si no puede importar).

5. Finalmente, debido a algún tipo de errores, todavía no funciona y viene con 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)) 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)) 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)) , según cómo deshacer el codeign , todavía existe algo incorrecto y la respuesta me dice que brew reinstall gdb , pero aún no funciona, lo llamé ayer.
6. Finalmente llegué a link , YO SOY FELIZ, ¡ahora puedo depurar!

Espero que mi solución pueda ayudar.