3 ms·
Yes, gcc/libstdc++ have the same problem. That's where I saw it first and then I tried llvm/libunwind and saw the same thing.
by drmeister 7y ago
Yes, gcc/libstdc++ have the same problem. That's where I saw it first and then I tried llvm/libunwind and saw the same thing.
- monocasa 7y agoWhat's the actual lock on? The unwinding shouldn't involve shared mutable state (as someone who's been deep into the DWARF unwinding VM bytecode).
- drmeister 7y agoIn libgcc it's in Unwind_Find_FDE - we think it's a lock around walking the loaded dynamic libraries. I haven't personally dug much deeper into it but my folks here and the llvm engineers seem to be pretty certain that's the problem (this: https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-dw2-fde.c#L1049 https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-...). Right now we are rearranging our compiler so we throw fewer exceptions because you don't have to optimize things that you don't do :-).
- viraptor 7y agoLooks to me like it only tries to protect the building of the shared / sorted "seen_objects". You don't want two threads rebuilding it at the same time. Although there must be a way to work around this. Maybe something like optimistically walk through the seen list, then grab the lock to update and walk again without a lock? You should be able to safely walk a linked list forwards even with another thread inserting into it, right?
- gpderetta 7y agoThere is some work libc size to make the lock optional and enabling it only at the first dlopen. Edit: last time I investigated the issue ended up here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
- brandmeyer 7y agoI think that this is a lock around dlopen(). dlopen changes the list of mapped objects (and therefore, the mapping from instruction pointer to unwind information).