[Lldb-commits] [PATCH] D26093: Limit LLDB_EXPORT_ALL_SYMBOLS to additionally export only the lldb_private namespace symbols

[Todd Fiala via lldb-commits]

tfiala added a comment.

>> Could you elaborate on this?
> 
> Sure, I'll see if I can reproduce the lack of backtrace symbol lookup that I was experiencing without exporting those symbols back in roughly Oct/Nov 2015.  We've been using this flag ever since to address it.
> 
>> I've been debugging lldb without this switch and everything seems to work fine
> 
> That definitely was not my experience when I added the flag.  I am seeing if the old scenario holds true on 16.04 x86_64 with the current LLDB codebase.  It is possible that the issue we saw manifest has been addressed.)  I will make a best effort attempt this weekend, but it may be more like Monday when I will have dedicated time to repro it.  If it is no longer an issue, I'd consider this flag deprecated as its initial purpose is no longer valid.  If it is still an issue, it could be a config difference between stock Ubuntu and your setup (as we know is at least the case with kernel settings).
> 
>> (modulo problems evaluating fancy expressions, but I don't think that is related to this. Or is it?).
> 
> At the time the issue was symbol lookup - we were somewhere short-circuiting so that we didn't consider debug symbols properly.  While I didn't try it at the time as I wasn't aware of it, it is possible the issue may be related to needing the -fno-limit-debug-info flag.  When I get to reproducing the original issue, if it does surface, I will try adding that flag as a second step to see if that addresses it.
> 
> For expressions that need to evaluate any symbols we were failing to resolve, I could imagine that being at least one factor.  Not sure though without a specific case to look at.
> 
> More later when I have some results.

Here is an example of where symbolic lookup of backtraces from within liblldb.so utterly fail without using this flag.  In the example below, I'm using:
(lldb) log enable -S lldb process
(lldb) target create /bin/ls
(lldb) run

And here is my output:

  Process::SetPublicState (exited) -- unlocking run lock
  0  liblldb.so.40   0x00007fb6041f6cd0
  1  liblldb.so.40   0x00007fb600834e22
  2  liblldb.so.40   0x00007fb600834b3f
  3  liblldb.so.40   0x00007fb600a5f601
  4  liblldb.so.40   0x00007fb600a5f047
  5  liblldb.so.40   0x00007fb6007b897e
  6  libpthread.so.0 0x00007fb60841570a
  7  libc.so.6       0x00007fb5ffa2882d clone + 109
  8  libc.so.6       000000000000000000 clone + 6125632
  9  liblldb.so.40   0x00007fb6007e7a68
  10 liblldb.so.40   0x00007fb6007e7e96
  11 liblldb.so.40   0x00007fb6007b897e
  12 libpthread.so.0 0x00007fb60841570a
  13 libc.so.6       0x00007fb5ffa2882d clone + 109
  Process 31919 exited with status = 0 (0x00000000)
  Process::RunPrivateStateThread (arg = 0x1d05580, pid = 31919) thread exiting...
  0  liblldb.so.40   0x00007fb6041f6cd0
  1  liblldb.so.40   0x00007fb600834e22
  2  liblldb.so.40   0x00007fb600834b3f
  3  liblldb.so.40   0x00007fb600a5f601
  4  liblldb.so.40   0x00007fb600a5f047
  5  liblldb.so.40   0x00007fb6007b897e
  6  libpthread.so.0 0x00007fb60841570a
  7  libc.so.6       0x00007fb5ffa2882d clone + 109
  (lldb-superior) MonitorChildProcessThreadFunction (arg = 0x1d25390) thread exiting because pid received exit signal...
  0  liblldb.so.40   0x00007fb6041f6cd0
  1  liblldb.so.40   0x00007fb600834e22
  2  liblldb.so.40   0x00007fb600834b3f
  3  liblldb.so.40   0x00007fb60079fd23
  4  liblldb.so.40   0x00007fb6007b897e
  5  libpthread.so.0 0x00007fb60841570a
  6  libc.so.6       0x00007fb5ffa2882d clone + 109
  ...

The exact cmake line was:

  cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm

where the build tree is a sibling directory to the llvm source root directory.

I see very similar behavior when trying to set breakpoints and step into lldb's internals with this same lldb.  Those all change to expected behavior when I build and run with the -DLLDB_EXPORT_ALL_SYMBOLS:BOOL=YES setting.

Let me know if you get different behavior without with the same setup.  If so, we should try to find out what about your Ubuntu load out is different than a stock Ubuntu, since this clearly affects LLDB developers using Linux.


Repository:
  rL LLVM

https://reviews.llvm.org/D26093