tfiala added a comment.
In https://reviews.llvm.org/D26093#583358, @labath wrote:
> The snippets you showed are pretty-much expected behavior. The backtrace that
> gets printed as a part of the log messages is coming from the backtrace(3)
> library, which has pretty limited backtracing capabilities -- it only looks
> at the symbols in the `.dynsym` section (because that's the only thing that
> is loaded into memory). I am pretty sure you would have problems backtracing
> if you compiled with -fomit-frame-pointer as well.
>
> I think you fix of just making sure that all symbols show up in the .dynsym
> section would be fine, were it not for that fact that we have an inconsistent
> linking policy, which means you get wildly different links depending on
> whether you export something or not. If we get that straight that this would
> just be a size optimization (that was the reason we introduced it), with no
> impact on the behavior, that we could even consider turning off by default (I
> personally have never used the -S option of logging, but I can see how it
> could be useful in some workflows). I'll get back to the link policy in a
> separate email.
>
> That said, you mentioned you also had some problems with setting breakpoints
> and stuff. Now, if this was true, that would be extremely worrying, but am
> not able to reproduce that on my side -- breakpoints everything else works
> fine. The reason for that is that lldb reads the .symtab section (if it is
> present, which it will be unless you strip the executable), and these linker
> options do not affect that section. If that is not the case, then we
> definitely need to figure that out (I suggest stepping through
> ObjectFileELF::GetSymtab() to get an initial idea of what is going on).
>
> FWIW, this is how a debug session looks like for me. The backtrace() output
> has addresses only, but lldb is able to symbolicate it with no problem:
>
> $ bin/lldb -- bin/lldb /bin/ls
> (lldb) target create "bin/lldb"
> Current executable set to 'bin/lldb' (x86_64).
> (lldb) settings set -- target.run-args "/bin/ls"
> (lldb) br set -n Log::VAPrintf
> Breakpoint 1: no locations (pending).
> WARNING: Unable to resolve breakpoint to any actual locations.
> (lldb) pr la
> Process 87438 launched:
> '/usr/local/google/home/labath/ll/build/dbg/bin/lldb' (x86_64)
> 1 location added to breakpoint 1
> Process 87438 stopped and restarted: thread 1 received signal: SIGCHLD
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) log enable -S lldb process
> (lldb) pr la
> Process 87438 stopped
> * thread #1: tid = 87438, 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s at least one of stdin/stdout/stderr was not
> set, evaluating default handling", args=0x00007fffffffc1a0) + 27 at
> Log.cpp:73, name = 'lldb', stop reason = breakpoint 1.1
> frame #0: 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s at least one of stdin/stdout/stderr was not
> set, evaluating default handling", args=0x00007fffffffc1a0) + 27 at Log.cpp:73
> 70 void Log::VAPrintf(const char *format, va_list args) {
> 71 // Make a copy of our stream shared pointer in case someone
> disables our
> 72 // log while we are logging and releases the stream
> -> 73 StreamSP stream_sp(m_stream_sp);
> 74 if (stream_sp) {
> 75 static uint32_t g_sequence_id = 0;
> 76 StreamString header;
> (lldb) c
> Process 87438 resuming
> ProcessLaunchInfo::FinalizeFileActions at least one of stdin/stdout/stderr
> was not set, evaluating default handling
> 0 liblldb.so.40 0x00007ffff4d5a36f
> 1 liblldb.so.40 0x00007ffff0d1d49f
> 2 liblldb.so.40 0x00007ffff0d1cfbb
> 3 liblldb.so.40 0x00007ffff0fff4c4
> 4 liblldb.so.40 0x00007ffff103ad63
> 5 liblldb.so.40 0x00007ffff15c4f9f
> 6 liblldb.so.40 0x00007ffff0e33fe0
> 7 liblldb.so.40 0x00007ffff0e20317
> 8 liblldb.so.40 0x00007ffff0e25c0d
> 9 liblldb.so.40 0x00007ffff0e265a7
> 10 liblldb.so.40 0x00007ffff0cf5a60
> 11 liblldb.so.40 0x00007ffff0cb5c3c
> 12 liblldb.so.40 0x00007ffff0e26fdf
> 13 liblldb.so.40 0x00007ffff09d8d21
> lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 129
> 14 lldb 0x0000000000407c15
> 15 lldb 0x0000000000408257
> 16 libc.so.6 0x00007fffeeeb8f45 __libc_start_main + 245
> 17 lldb 0x00000000004038d9
> Process 87438 stopped
> * thread #1: tid = 87438, 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s target stdin='%s', target stdout='%s',
> stderr='%s'", args=0x00007fffffffc1a0) + 27 at Log.cpp:73, name = 'lldb',
> stop reason = breakpoint 1.1
> frame #0: 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s target stdin='%s', target stdout='%s',
> stderr='%s'", args=0x00007fffffffc1a0) + 27 at Log.cpp:73
> 70 void Log::VAPrintf(const char *format, va_list args) {
> 71 // Make a copy of our stream shared pointer in case someone
> disables our
> 72 // log while we are logging and releases the stream
> -> 73 StreamSP stream_sp(m_stream_sp);
> 74 if (stream_sp) {
> 75 static uint32_t g_sequence_id = 0;
> 76 StreamString header;
> (lldb) bt
> * thread #1: tid = 87438, 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s target stdin='%s', target stdout='%s',
> stderr='%s'", args=0x00007fffffffc1a0) + 27 at Log.cpp:73, name = 'lldb',
> stop reason = breakpoint 1.1
> * frame #0: 0x00007ffff0d1cfeb
> liblldb.so.40`lldb_private::Log::VAPrintf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s target stdin='%s', target stdout='%s',
> stderr='%s'", args=0x00007fffffffc1a0) + 27 at Log.cpp:73
> frame #1: 0x00007ffff0d1cfbb
> liblldb.so.40`lldb_private::Log::Printf(this=0x000000000059a560,
> format="ProcessLaunchInfo::%s target stdin='%s', target stdout='%s',
> stderr='%s'") + 347 at Log.cpp:61
> frame #2: 0x00007ffff0fff970
> liblldb.so.40`lldb_private::ProcessLaunchInfo::FinalizeFileActions(this=0x00000000004a0170,
> target=0x000000000058bea0, default_to_use_pty=true) + 1376 at
> ProcessLaunchInfo.cpp:260
> frame #3: 0x00007ffff103ad63
> liblldb.so.40`lldb_private::Target::Launch(this=0x000000000058bea0,
> launch_info=0x00000000004a0170, stream=0x00007fffffffcaa8) + 1315 at
> Target.cpp:2835
> frame #4: 0x00007ffff15c4f9f
> liblldb.so.40`CommandObjectProcessLaunch::DoExecute(this=0x00000000004a0030,
> launch_args=0x00007fffffffcd68, result=0x00007fffffffd4d8) + 1647 at
> CommandObjectProcess.cpp:233
> frame #5: 0x00007ffff0e33fe0
> liblldb.so.40`lldb_private::CommandObjectParsed::Execute(this=0x00000000004a0030,
> args_string="", result=0x00007fffffffd4d8) + 1344 at CommandObject.cpp:1008
> frame #6: 0x00007ffff0e20317
> liblldb.so.40`lldb_private::CommandInterpreter::HandleCommand(this=0x0000000000482750,
> command_line="pr la", lazy_add_to_history=eLazyBoolCalculate,
> result=0x00007fffffffd4d8, override_context=0x0000000000000000,
> repeat_on_empty_command=true, no_context_switching=false) + 3527 at
> CommandInterpreter.cpp:1679
> frame #7: 0x00007ffff0e25c0d
> liblldb.so.40`lldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000000482750,
> io_handler=0x0000000000583190, line="pr la") + 301 at
> CommandInterpreter.cpp:2713
> frame #8: 0x00007ffff0e265a7 liblldb.so.40`non-virtual thunk to
> lldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000000482750,
> io_handler=0x0000000000583190, line="pr la") + 55 at
> CommandInterpreter.cpp:2689
> frame #9: 0x00007ffff0cf5a60
> liblldb.so.40`lldb_private::IOHandlerEditline::Run(this=0x0000000000583190) +
> 608 at IOHandler.cpp:552
> frame #10: 0x00007ffff0cb5c3c
> liblldb.so.40`lldb_private::Debugger::ExecuteIOHandlers(this=0x0000000000480e90)
> + 140 at Debugger.cpp:899
> frame #11: 0x00007ffff0e26fdf
> liblldb.so.40`lldb_private::CommandInterpreter::RunCommandInterpreter(this=0x0000000000482750,
> auto_handle_events=true, spawn_thread=false, options=0x00007fffffffd7d8) +
> 223 at CommandInterpreter.cpp:2910
> frame #12: 0x00007ffff09d8d21
> liblldb.so.40`lldb::SBDebugger::RunCommandInterpreter(this=0x00007fffffffdb48,
> auto_handle_events=true, spawn_thread=false) + 129 at SBDebugger.cpp:814
> frame #13: 0x0000000000407c15
> lldb`Driver::MainLoop(this=0x00007fffffffdb28) + 4341 at Driver.cpp:1156
> frame #14: 0x0000000000408257 lldb`main(argc=2,
> argv=0x00007fffffffdd28) + 471 at Driver.cpp:1254
> frame #15: 0x00007fffeeeb8f45
> libc.so.6`__libc_start_main(main=(lldb`main at Driver.cpp:1218), argc=2,
> argv=0x00007fffffffdd28, init=<unavailable>, fini=<unavailable>,
> rtld_fini=<unavailable>, stack_end=0x00007fffffffdd18) + 245 at
> libc-start.c:287
> frame #16: 0x00000000004038d9 lldb`_start + 41
>
Okay, thanks for the details on that.
At the time, both the log backtrace functionality (via backtrace(3) as you
mentioned) and the actual backtracing were suffering IIRC. I wouldn't be
surprised if the latter was fixed in the last year given the number of symbolic
lookup changes that took place. I may also be mistaken on that. I'll have to
go back and find the particulars. I may need to go back to the old version
(circa August-Oct 2015) to see what it looked like back then. It was pretty
much a show stopper for getting any debugging of lldb to work on Linux.
I'm glad to hear backtracing in general is working.
FWIW on macOS and related platforms, our atos and backtrace(3)-like
functionality do not require public symbols to work in the presence of debug
info. It is unfortunate, from a feature-parity perspective, that we require
exporting private symbols on Linux to get similar functionality on the macOS
platform side, at least as far as log stacktraces go. Now that I think of it,
I recall digging into that a bit back then, and musing that we might be able to
replace the backtrace(3) strategy for stacktraces with our own backtracing
logic.
Repository:
rL LLVM
https://reviews.llvm.org/D26093
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
