Re: [lmi] LLVM libc++

[Greg Chicares]

On 10/6/22 13:35, Vadim Zeitlin wrote:
> On Wed, 5 Oct 2022 21:47:11 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> And using a pragma does work. You could see that in the two small
> GC> commits
> 
>  Just FYI, I'm going to push 2 more changes needed to fix the CI builds
> after these changes, please see my ci-libunwind branch if you'd like to
> have a look at them, but they only affect .github/workflows/ci.yml and
> configure.ac respectively, so you're probably not very interested in them.

I meant to mention those two files, because I didn't feel fully confident
about modifying them myself. Should I merge your 'ci-libunwind' branch now,
or do you want to make further changes to it?

>  Also, this is not the most critical question, but I'd still like to ask:
> why are we actually using libunwind at all instead of using glibc
> backtrace_symbols() function as everybody else does? Have you already tried
> and found it unsatisfactory?

It was my (casual) impression that libunwind was generally preferred.
For example, a quick web search for "backtrace_symbols vs libunwind"
finds comments like these:

https://stackoverflow.com/questions/49247458/how-can-i-programmatically-obtain-reliable-backtraces-in-spite-of-optimization
| backtrace's algorith is extremely primitive
| A much better alternative is to use libunwind or libbacktrace

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

I never tried using backtrace_symbols() instead.

>  I'm asking this because LLVM libunwind really doesn't seem to be meant for
> the public consumption, it looks like a library used by LLVM internally
> that just happens to have ended up in Debian for some reason.

Here, again, I had a different impression: that the HP libunwind was bloated,
old, and not very actively maintained, so LLVM wrote this replacement.

> In addition
> to the already mentioned issue with its haphazardly installed headers, it
> also doesn't provide libunwind.pc file, unlike the old library, making it
> more difficult to check for it. It's not a huge deal, of course, but it's
> just not a good sign IMHO and it seems wiser not to depend on it unless we
> absolutely have to. Do we?

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