[Lldb-commits] [PATCH] D26093: Limit LLDB_EXPORT_ALL_SYMBOLS to additionally export only the lldb_private namespace symbols
Todd Fiala via lldb-commits
lldb-commits at lists.llvm.org
Mon Oct 31 08:17:30 PDT 2016
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
More information about the lldb-commits
mailing list