Re: [lmi] LLVM libc++

[Vadim Zeitlin]

On Thu, 6 Oct 2022 18:52:15 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 10/6/22 15:21, Vadim Zeitlin wrote:
GC> > On Thu, 6 Oct 2022 14:32:55 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
GC> > 
GC> > GC> On 10/6/22 13:35, Vadim Zeitlin wrote:
GC> > GC> > On Wed, 5 Oct 2022 21:47:11 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...]
GC> > GC> Should I merge your 'ci-libunwind' branch now,
GC> > GC> or do you want to make further changes to it?
GC> > 
GC> >  No, I think this should be merged -- please feel free to do it if you'd
GC> > like, or I could just push them myself, as you prefer.
GC> 
GC> Done.

 Thanks!

GC> Usually in the past I've used cherry-pick, but today I decided
GC> to do this instead:
GC>   $git merge xanadu/ci-libunwind
GC> An advantage is that the SHA1s match yours. I had thought this method
GC> would have the disadvantage of making git-log history nonlinear, but
GC> these views:
GC>   $git log -20 --graph --oneline --all --full-history
GC>   $git log -20 --graph --oneline --all --decorate
GC> look perfectly linear to me.

 This is because it's a special form of merge known as "fast forward
merge". It [only] happens when there have been no commits to master (or the
branch being merged to) since the topic branch (the one being merged) was
split from it. You can use "git merge --ff-only" if you want to make only
such merges and not any "real" ones.

GC> If you'd like to propose a replacement for lmi's 'unwind.?pp',
GC> I'd welcome that. I have no reason to prefer libunwind. I just
GC> want exception backtraces.

 I think relying on libunwind is a nuisance, so I'd like to get rid of it.
We probably still want to use libdw as getting source information without
it isn't simple, i.e. in wxWidgets I do it by running addr2line which is
much slower (and also doesn't work correctly right now, but I'm working on
fixing that).

 But it actually depends on what kind of information do you need to have in
the backtraces: if only function names are enough, then backtrace_symbols()
is all you need and is by far the simplest solution. If you do want the
file names and line numbers too, then either libdw or libbfd or libdwarf
are needed in practice (in theory it would be possible to do what these
libraries do in lmi's own code, but this doesn't seem like a good idea).

 So how important are the line numbers in the backtraces?
VZ

pgp6zhp1aydJj.pgp
Description: PGP signature