Re: [lmi] LLVM libc++

[Vadim Zeitlin]

On Thu, 6 Oct 2022 14:32:55 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 10/6/22 13:35, Vadim Zeitlin wrote:
GC> > On Wed, 5 Oct 2022 21:47:11 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
GC> > 
GC> > GC> And using a pragma does work. You could see that in the two small
GC> > GC> commits
GC> > 
GC> >  Just FYI, I'm going to push 2 more changes needed to fix the CI builds
GC> > after these changes, please see my ci-libunwind branch if you'd like to
GC> > have a look at them, but they only affect .github/workflows/ci.yml and
GC> > configure.ac respectively, so you're probably not very interested in them.
GC> 
GC> I meant to mention those two files, because I didn't feel fully confident
GC> about modifying them myself. Should I merge your 'ci-libunwind' branch now,
GC> or do you want to make further changes to it?

 No, I think this should be merged -- please feel free to do it if you'd
like, or I could just push them myself, as you prefer.

GC> >  Also, this is not the most critical question, but I'd still like to ask:
GC> > why are we actually using libunwind at all instead of using glibc
GC> > backtrace_symbols() function as everybody else does? Have you already 
tried
GC> > and found it unsatisfactory?
GC> 
GC> It was my (casual) impression that libunwind was generally preferred.
GC> For example, a quick web search for "backtrace_symbols vs libunwind"
GC> finds comments like these:
GC> 
GC> 
https://stackoverflow.com/questions/49247458/how-can-i-programmatically-obtain-reliable-backtraces-in-spite-of-optimization
GC> | backtrace's algorith is extremely primitive
GC> | A much better alternative is to use libunwind or libbacktrace

 They also say that the problem with backtrace() is that it requires using
-fno-omit-frame-pointer (which we already use) while libunwind works better
when using -funwind-tables (which we don't use).

GC> https://www.cnblogs.com/utopia007/p/11642581.html
GC> | I strongly prefer libunwind, as it's the most modern, widespread and 
portable

 I guess it is indeed most modern, but it also seems most (external)
developer-unfriendly and, after scanning LLVM discussions, I couldn't see
any hint of any plans to change this, i.e. my impression is that it's an
internal LLVM library and LLVM developers don't have any interest in making
it easy to use outside of LLVM.

GC> I never tried using backtrace_symbols() instead.

 FWIW this is what wxStackWalker uses under Unix and I'm not aware of any
particular issues with it (you can see it in action in wx "except" sample,
e.g. by triggering an assertion in it and looking at the backtrace in the
resulting dialog). It's also much simpler (even if not much shorter) than
the current code in unwind.cpp IMO.
 
GC> >  I'm asking this because LLVM libunwind really doesn't seem to be meant 
for
GC> > the public consumption, it looks like a library used by LLVM internally
GC> > that just happens to have ended up in Debian for some reason.
GC> 
GC> Here, again, I had a different impression: that the HP libunwind was 
bloated,
GC> old, and not very actively maintained, so LLVM wrote this replacement.

 This is possible, of course, I didn't look at the implementation. But do
we really care about it? It's not like we're going to need backtraces
millions of times per second...

GC> OTOH, I thought we had to use LLVM's libunwind in order to use its libc++,
GC> which is the only actual motivation here.

 backtrace_symbols() seems to work just fine with clang and libc++, at
least under Linux.

 BTW, what doesn't work in wxStackWalker is calling addr2line to get the
source location from the addresses, but this is a bug in wx, which doesn't
adjust the address correctly, and could probably be fixed simply enough.
But backtrace_symbols() does what it says, i.e. gives the names of the
functions containing the addresses in one simple call and so IMHO could be
a worthwhile replacement for the current contents of unwind.cpp.

 Please let me know if you think this would be worth pursuing,
VZ

pgpL38liG_HL7.pgp
Description: PGP signature