Stacktrace в lldb с двоичным кодом, созданным clang на OS X

Когда-то я мог сделать следующее в OS X с установленными инструментами командной строки Xcode, как обычно делал в Linux:

vim foo.cpp
#... write some buggy code that segfaults
gcc -g foo.cpp
gdb a.out
(gdb) bt

И я бы увидел красивую символическую трассировку стека. В настоящее время gdb заменен на lldb, а gcc на clang. Если я просто построю с помощью clang++ и сделаю lldb a.out, у меня не будет символов.

Я попытался запустить dsymutil и получил файл типа Mach-O 64-bit dSYM companion file x86_64 и попытался загрузить его в lldb с target symbols add, но в трассировке стека все еще нет символов. Но я должен признать, что сдался на полпути к http://lldb.llvm.org/symbolication.html думая, что просто невозможно пройти через все эти обручи и циклы, чтобы получить трассировку стека с переворачиванием из двоичного файла, который я создаю сам.

Итак, мой вопрос сводится к следующему: как проще всего добиться того, что я сделал выше несколько лет назад с помощью gcc и gdb в командной строке современной системы OS X, используя стандартные инструменты Xcode?

Обратите внимание, что нельзя просто установить gcc и gdb с помощью порта или доморощенного и т. д. - мне нужно создать и получить трассировку стека из командной строки с использованием стандартных инструментов Xcode.


person Ae Yppek    schedule 21.10.2016    source источник
comment
Вы уверены, что сделали: clang -g -O0 foo.cpp, когда собирали свой двоичный файл? Если вы это сделали, шаги с lldb должны быть точно такими же, как и с gdb.   -  person Jim Ingham    schedule 21.10.2016


Ответы (1)


Проблема решена. Комментарий Джима заставил меня сделать полный простой пример foo.cpp с нуля, и он действительно работал именно так, как он описал, с красивой символической трассировкой стека.

Оказывается, я просто не внимательно прочитал вывод из lldb в первую очередь - несимволизированная трассировка стека была на самом деле не из моего сбоя, а из загрузчика библиотеки dyld, который не мог разрешить внешнюю зависимость.

Итак, ответ таков: lldb и clang работают именно так, как я и надеялся. Меня просто обманули выводом, как показано ниже:

dyld: Library not loaded: libbarlib.dylib
 Referenced from: fooexe
  Reason: image not found
Process 776 stopped
* thread #1: tid = 0xec52b9, 0x00007fff5fc01075 dyld`dyld_fatal_error + 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
    frame #0: 0x00007fff5fc01075 dyld`dyld_fatal_error + 1
dyld`dyld_fatal_error:
->  0x7fff5fc01075 <+1>: nop    

dyld`dyldbootstrap::start:
    0x7fff5fc01076 <+0>: pushq  %rbp
    0x7fff5fc01077 <+1>: movq   %rsp, %rbp
    0x7fff5fc0107a <+4>: pushq  %r15
(lldb) bt
* thread #1: tid = 0xec52b9, 0x00007fff5fc01075 dyld`dyld_fatal_error + 1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
  * frame #0: 0x00007fff5fc01075 dyld`dyld_fatal_error + 1
    frame #1: 0x00007fff5fc03f87 dyld`dyld::halt(char const*) + 77
    frame #2: 0x00007fff5fc05fda dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4174
    frame #3: 0x00007fff5fc01276 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 512
    frame #4: 0x00007fff5fc01036 dyld`_dyld_start + 54
person Ae Yppek    schedule 22.10.2016