tfiala added a comment. In https://reviews.llvm.org/D26093#582412, @tfiala wrote:
> In https://reviews.llvm.org/D26093#582395, @labath wrote: > > > I am a bit surprised that this fixes the problem. I would have expected > > that the problem would occur in case when we *do* restrict exports, > > > This matches my expectations. When I was using the flag the exported all > symbols indiscriminately from liblldb.so, it meant that the llvm symbols for > the copy inside liblldb.so were public and known. That public element allows > the dynamic linker to coalesce the data storage locations with the ones for > the llvm in lldb-mi. Hiding them (as per the normal case, when we only > export the 'lldb' public namespace) prevents the dynamic linker from doing > the coalesce. So, the global constructor initialization sequence for liblldb.so, which includes a copy of llvm with Debug.cpp and therefore runs the global constructor for adding 'debug' to the command line, does so, but against *shared* locations for the backing storage. And lldb-mi, which also contains a separate copy of the llvm code, also adds the constructor to the init sequence, using the shared data location that was coalesced by the dynamic linker. So two separate copies of the code, using the same coalesced storage, end up blowing up because both instances of the global constructor think they're the only one operating on that data. https://reviews.llvm.org/D26093 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
