[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] LLVM libc++
From: |
Greg Chicares |
Subject: |
Re: [lmi] LLVM libc++ |
Date: |
Thu, 6 Oct 2022 18:52:15 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 |
On 10/6/22 15:21, Vadim Zeitlin wrote:
> 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> 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.
Done. Usually in the past I've used cherry-pick, but today I decided
to do this instead:
$git merge xanadu/ci-libunwind
An advantage is that the SHA1s match yours. I had thought this method
would have the disadvantage of making git-log history nonlinear, but
these views:
$git log -20 --graph --oneline --all --full-history
$git log -20 --graph --oneline --all --decorate
look perfectly linear to me.
> 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> 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.
[...]
> 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,
If you'd like to propose a replacement for lmi's 'unwind.?pp',
I'd welcome that. I have no reason to prefer libunwind. I just
want exception backtraces.
- Re: [lmi] LLVM libc++, (continued)
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/04
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/05
- Re: [lmi] LLVM libc++, Vadim Zeitlin, 2022/10/05
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/05
- Re: [lmi] LLVM libc++, Vadim Zeitlin, 2022/10/05
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/05
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/05
- Re: [lmi] LLVM libc++, Vadim Zeitlin, 2022/10/06
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/06
- Re: [lmi] LLVM libc++, Vadim Zeitlin, 2022/10/06
- Re: [lmi] LLVM libc++,
Greg Chicares <=
- Re: [lmi] LLVM libc++, Vadim Zeitlin, 2022/10/06
- Re: [lmi] LLVM libc++, Greg Chicares, 2022/10/06