From: Mark Kettenis Subject: Re: clang: build llvm-symbolizer/llvm-addr2line To: Theo Buehler Cc: jonathan@d14n.org, tech@openbsd.org Date: Thu, 26 Jun 2025 00:35:20 +0200 > Date: Wed, 25 Jun 2025 23:28:58 +0200 > From: Theo Buehler > > On Wed, Jun 25, 2025 at 03:01:46PM +1000, Jonathan Matthew wrote: > > On at least arm64 (maybe mips64 too?), base binutils addr2line is not as > > useful as it'd ideally be. Trying to use the output from malloc leak > > checking, for instance: > > > > 0xa89a7491c 136032 24 5668 addr2line -e /usr/lib/libc.so.100.3 0x9791c > > 0x6394fea38 - - - addr2line -e dhcp6leased 0x1ea38 > > 0xaf9c85f58 - - - addr2line -e /usr/lib/libevent.so.4.1 0x16f58 > > > > the libc line produces 976 error messages about dwarf versions and then > > doesn't give a source location. Some addresses give a source file name > > but no line number. It works better with some other libraries, but being > > able to see what's going on in libc is pretty important. > > > > We could use llvm's drop in replacement instead. The diff below adds > > build infrastructure and manpages for llvm-symbolizer, which acts like > > addr2line when called as (llvm-)addr2line. I've tested it on amd64 and > > arm64 and it works as advertised there. > > > > thoughts? ok? > > I think it makes sense to include these tools. I prefer having working > things in base and the binutils mostly don't work on aarch64. objdump vs > llvm-objdump is another example. Once libLLVM is built, these utilities > don't take noticeably more build time and hardly any space (in addition > they're hardlinks of one another). > > ok tb I agree; ok kettenis@ And at some point we should think about dropping the binutils versions of these tools on clang archs. But I don't think we've reached that point yet.