Bug ID 18769
Summary lldb fails to stack unwind gold linker exes that assert
Product lldb
Version unspecified
Hardware PC
OS Linux
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter tfiala@google.com
Classification Unclassified
I'm hitting an assertion in lldb-gdbserver. On Ubuntu 12.04 x86_64, using the
gold linker 'sudo apt-get install binutils-gold', with a cmake/ninja build, I
am not able to get a valid backtrace out of lldb for lldb-gdbserver when it
generates
Yeah - I hit “enter” by accident 
The next comment fills in the rest. Short version: gdb + gold linker + assert = backtrace, lldb + gold linker = assert = failure.
Not high priority, but will stop me from using the gold linker even though it gives me a 6-7% speed increase.
I'd start by seeing if lldb knows where the binaries are loaded in this session. e.g.
(lldb) im loo -a $pc
It doesn't look like lldb knows what Module you're in and doesn't have a function/symbol name either. There's probably no eh_frame unwind info and IIRC your system's libraries are all built -fomit-frame-pointer so a blind stack walk will fail.
I don't know how solid lldb's corefile support is on Linux. It may be that you're not able to find where all the solibs are loaded when doing core file debugging.
This is also a little disheartening,
* thread #1: tid = 0, 0x00007ffba3bb2425, name = 'lldb-gdbserver', stop reason = signal SIGABRT
frame #0: 0x00007ffba3bb2425
-> 0x7ffba3bb2425: addb %al, (%rax)
0x7ffba3bb2427: addb %al, (%rax)
0x7ffba3bb2429: addb %al, (%rax)
0x7ffba3bb242b: addb %al, (%rax)
this means that lldb is getting back 0x00's when it is trying to read memory out of the core file I expect.
this means that lldb is getting back 0x00’s when it is trying to read memory out of the core file I expect.
Yep, I remember that one from last Friday!
(lldb) im loo -a $pc
I’ll give that a shot, thanks Jason.