lmi
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]