labath added a comment. In https://reviews.llvm.org/D26093#582420, @tfiala wrote:
> The reason why it doesn't blow up in the hidden case is that liblldb.so has > already internally resolved the storage, doesn't involve dynamic resolution, > and has its own data location. Ditto for lldb-mi's copy. So they are > separate islands. > > There are two totally separate other issues here that I see, that I think are > best handled by other discrete changes: > > 1. Fix lldb-mi to not need a separate copy of llvm. lldb-mi has needed bits of llvm since forever, I think. But we have changed which parts exactly we pull, which may have triggered this problem. Fixing this is going to be hard. > 2. Fix lldb on Linux to not require private symbols to be exposed to get > access to them during debugging, when the debug info is available. > > Item 1 was recently introduced. Item 2 appears to be a flaw in Linux LLDB, > at least in the configurations we use. I plan to tackle #2 in the near > future. I take it that by "debugging" you mean "having symbols appear in backtrace(3)" output. That is a unfortunate, but I don't know what can we do about that. I am curious, could you explain what you have in mind? > I seem to recall #1 happened when some refactoring was taking place that > ended up requiring private details from llvm? It was the other way around. lldb-mi stopped using internal llvm API, and switched to the public ones. The issue is that we consider all llvm APIs to be private as far as liblldb is concerned. Feel free to check this in, if it unblocks you. I don't think it makes things any worse. I'll take a look next week if I can come up with something better, https://reviews.llvm.org/D26093 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
