[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.

In https://reviews.llvm.org/D26093#582825, @labath wrote:

> In https://reviews.llvm.org/D26093#582618, @tfiala wrote:
>
> > > If it unblocks something it might be ok, but it doesn't actually fix the problem.
> >
> > It allows debugging of lldb with lldb on Ubuntu.  This broke recently, and the CL here re-enables the ability to do that.
>
>
> 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.


Repository:
  rL LLVM

https://reviews.llvm.org/D26093